A2A vs MCP 2026：JSON・Tools・Agent の役割分担

The protocol war myth: complementary, not either/or

Picking MCP or A2A as “the winner” is the most common 2026 agent architecture mistake. MCP standardizes passive capabilities: MCP servers expose tools, resources, prompts; the client discovers and calls—peers are APIs, databases, files, with no model loop of their own. A2A standardizes autonomous peers: remote agents have their own models, tools, memory, and task state; the orchestrator learns capabilities from an Agent Card without seeing internals.

A useful mnemonic: MCP is the agent’s hands (down to tools); A2A is conversation with coworkers (sideways delegation). Wrapping a whole remote agent as one MCP tool often collapses multi-turn reasoning into a single function call—when tasks run long, need clarification, or async callbacks, A2A task lifecycles fit better. Using A2A to hit a plain read-only REST API adds unnecessary negotiation overhead.

In July 2026 MCP shipped stateless 2026-07-28—remote servers behind ordinary HTTP load balancers. A2A reached v1.0 in early 2026 with signed Agent Cards and 150+ orgs in production. Both evolve under AAIF, not zero-sum. Need tool access first → MCP. Need multi-team, multi-vendor orchestration → add A2A. Most production systems end up as “orchestrator: MCP down, A2A sideways.”

MCP: agent down to tools and data

MCP defines discovery, JSON-RPC exchange, and results between client and server. Core JSON surfaces:

1. tools/list: server returns Tool objects with name, description, inputSchema (JSON Schema subset).
2. tools/call: client sends params.name + params.arguments; server executes and returns result.content.
3. resources/* and prompts/*: read-only context and templates, also JSON-RPC.
4. Since 2026-07-28 each request may carry protocol version in _meta; session state removed for horizontal scale.

MCP does not validate arguments for you—inputSchema is declarative; execution must JSON.parse + schema-validate. That is a different hop from model tool calling: parse model argument strings before assembling tools/call. See ourMCP と JSON SchemaandStateless MCP.

Stateless tools/call request example:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "searchInvoices",
    "arguments": {
      "startDate": "2026-01-01",
      "endDate": "2026-01-31",
      "status": "paid"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

A2A: agent sideways to agent

A2A standardizes discovery, delegation, and results between agents. Each agent publishes an Agent Card at a well-known URL (commonly /.well-known/agent-card.json)—JSON with name, skills, endpoint, auth, streaming. The orchestrator fetches cards, then JSON-RPC (HTTP + SSE) for message/send or task lifecycle—child agents can clarify, stream, or run hours before push notification.

Key difference from MCP: the A2A peer is an opaque agent, not a function table. Do not assume a 1:1 map to a single tools/list entry unless the remote skill is explicitly deterministic RPC. Tasks have id, status (submitted/working/completed/failed), artifacts, history; JSON payloads describe message parts (text, file, data), not fixed argument schemas.

Agent Card fragment (discovery JSON):

{
  "name": "Invoice Specialist Agent",
  "description": "Finds, validates, and summarizes invoices for finance workflows",
  "url": "https://agents.example.com/invoice",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "search-invoices",
      "name": "Search invoices",
      "description": "Query invoices by date range and status",
      "inputSchema": {
        "type": "object",
        "properties": {
          "startDate": { "type": "string", "format": "date" },
          "endDate": { "type": "string", "format": "date" },
          "status": { "type": "string", "enum": ["draft", "sent", "paid"] }
        },
        "required": ["startDate", "endDate"]
      }
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

When the orchestrator delegates to Invoice Specialist, message/send looks roughly like:

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "Summarize all paid invoices between 2026-01-01 and 2026-01-31"
        }
      ]
    },
    "metadata": {
      "correlationId": "orch-42"
    }
  }
}

Google ADK’s RemoteA2aAgent routes one remote agent per turn; parallel quotes across specialists use a2a-sdk directly. Salesforce, SAP, Atlassian, and 50+ launch partners adopted A2A in 2025–2026 for cross-org agent interop.

How JSON divides across three layers

Split JSON roles by hop—avoid “one schema everywhere”:

Three JSON file families in practice: schemas/tools/*.schema.json (MCP + model tools), schemas/agents/*.card.json (A2A discovery), schemas/output/*.schema.json (Structured Output). Bump tools schema when tool fields change; version Agent Cards when capabilities change—do not merge into one file.

Side-by-side debug: model tool arguments, MCP tools/call params.arguments, A2A task artifact JSON. Shape mismatches usually sit in the adapter—not “wrong protocol.” OurAI JSON エラーガイドfour-layer taxonomy applies to cross-protocol pipelines too.

2026 map: MCP vs A2A vs model tool calling

Coarse comparison (see each spec for details):

Selection: one agent, internal APIs and DB → MCP is enough; don’t force multi-agent A2A for fashion. Cross-BU, cross-SaaS, cross-cloud specialists → A2A client on the orchestrator; each specialist still uses MCP internally. Model tool calling is a third line—the orchestrator LLM still picks actions via functions/tools; argument JSON Schema should share origin with MCP inputSchema—see ourMCP JSON Schema 記事.

Combined architecture and JSONVue workflow

Minimal production topology:

1. Orchestrator agent (LLM + policy): tool calling decides MCP vs A2A delegation.
2. MCP layer: GitHub, Postgres, Slack tool servers; canonical schema generates inputSchema and OpenAI tools[].
3. A2A layer: invoice, compliance, pricing remote agents; cache Agent Cards at startup; parse artifact JSON after task completion.
4. Validation chain: every hop parse → JSON Schema → business rules; don’t blind-trust A2A artifacts or MCP results.

Debug checklist: ① valid Agent Card JSON, skills match docs; ② tools/list and model tools[] share schema origin; ③ correlate A2A task history and MCP tools/call logs with correlationId. In the browser:JSON 整形for parse;JSON Schema validatorfor arguments and Card inputSchema;JSON Diffmodel arguments vs MCP params.arguments.

Further reading: MCP and JSON Schema, Stateless MCP, AI Structured Output, Apple AI Agent and JSON.

FAQ

Summary and next steps

The 2026 “protocol war” is really layered division: MCP down (tools/JSON-RPC/inputSchema), A2A sideways (Agent Card/task/message), model tool calling for orchestrator LLM argument JSON. JSON Schema glues layers, but Structured Output, tool arguments, and agent artifacts deserve separate files.

Next: draw your agent topology—which hops use MCP vs A2A; paste tools/list and Agent Card JSON into JSONVue. Wire MCP tools first, add A2A specialists as needed—easier to debug than starting with many agents.