MCP vs A2A: agent-to-tool and agent-to-agent protocols

MCP connects an AI application to tools and data: the agent calls a function with typed arguments and gets a result back. A2A (Agent2Agent) connects one agent to another agent: a client agent sends a message, and a remote, independently operated agent works on it as a task with its own reasoning and tools. They sit at different layers, and the A2A project itself describes them as complementary.

As of October 2026, the A2A specification is at version 1.0 and MCP at revision 2026-07-28.

Who maintains each protocol

A2A was originally developed by Google and donated to the Linux Foundation, and is licensed under Apache 2.0. In August 2026 it was accepted as a Growth Stage project at the Agentic AI Foundation (AAIF), a Linux Foundation-directed foundation where MCP is also a project. A technical steering committee with members from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow runs it.

MCP was created by Anthropic as an open standard and is specified at modelcontextprotocol.io.

How MCP and A2A differ

MCP: one agent and its tools

A host like Claude Code or VS Code creates one MCP client per server; each client lists the server's tools and calls them. The architecture overview describes servers as programs that provide context, whether they run locally over stdio or remotely over Streamable HTTP. Revision 2026-07-28 is stateless at the protocol level, so every request carries the protocol version and client capabilities in _meta:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

The server validates the arguments and returns a result. It isn't limited to a single round trip: per the tools specification, a server can answer with input_required and an elicitation request, and the client retries with the user's answer. The Tasks extension adds durable handles for work that runs longer than one request. A server that needs state across calls returns an explicit handle the model passes back.

A2A: agents working with agents

A2A standardizes how agents that don't share code, memory or tools work together. The A2A homepage calls them "opaque agentic applications": the remote agent exposes what it can do, not how.

Discovery starts with an Agent Card, a JSON document describing the agent's identity, skills, endpoints and authentication. Section 8.2 of the specification gives https://{server_domain}/.well-known/agent-card.json as the well-known location. An abbreviated card:

{
  "name": "Parts Supplier Agent",
  "description": "Checks stock and places orders for vehicle parts.",
  "version": "1.0.0",
  "supportedInterfaces": [
    { "url": "https://parts.example.com/a2a/v1", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }
  ],
  "capabilities": { "streaming": true, "pushNotifications": false },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "stock-check",
      "name": "Stock check",
      "description": "Answers availability questions for a part number and vehicle.",
      "tags": ["parts", "availability"]
    }
  ]
}

The client agent sends a message with SendMessage (or POST /message:send in the HTTP+JSON binding). The remote agent may answer directly or create a task, which moves through states: submitted, working, possibly TASK_STATE_INPUT_REQUIRED or TASK_STATE_AUTH_REQUIRED, then completed, failed, canceled or rejected. The client can poll with GetTask, stream updates with SendStreamingMessage or SubscribeToTask, or register a webhook for push notifications. Results come back as Artifacts.

"Skills" in an Agent Card are A2A's own concept, a description of what the agent can do. They're unrelated to Agent Skills (SKILL.md files), which MCP vs Agent Skills covers.

Where the boundary falls

The A2A and MCP page frames the distinction by what the agent interacts with. Tools are "primitives with well-defined, structured inputs and outputs". Agents "reason, plan, and use multiple tools" and keep state across multi-turn exchanges. Its summary: "MCP is vertical. It deepens a single agent. A2A is horizontal. It connects agents across that boundary."

MCP also supports follow-up input and long-running work, so neither is a reason on its own to pick A2A. Choose A2A when the boundary is delegation to an independently operated agent that manages its own task, rather than duration alone. Signs of that:

• The other side belongs to another team or company and won't expose its tools, only an outcome.
• You want to hand over a goal ("find a replacement part and order it"), and the other side decides the steps.
• The other side runs its own model, tools and credentials, and you don't want to see or manage them.

If you can write the operation as a function with a JSON Schema and you're happy to own the call, it's a tool.

How they work together

The A2A docs use an auto repair shop as the example. A customer talks to a shop manager agent over A2A ("my car is making a rattling noise"), and the manager asks follow-up questions. The mechanic agent uses MCP tools such as scan_vehicle_for_error_codes and raise_platform to do the work. When a part is needed, the mechanic asks a supplier's agent over A2A whether it's in stock.

The same pattern in a software setting:

 Your orchestrator agent
   ├── MCP ──> GitHub, Sentry, internal database   (its own tools)
   └── A2A ──> Vendor's support agent               (another organization's agent)
                 └── MCP ──> the vendor's own tools  (hidden from you)

Each agent uses MCP for its own tools and A2A between agents. The A2A docs also note an overlap: an A2A server can expose some well-defined, stateless skills as MCP-style tools, but "A2A is about agents partnering on tasks; MCP is more about agents using capabilities."

When to use which

Use MCP when you want an agent to read or change data in a service and the operation fits a schema, or when you're connecting an AI app such as Claude Code, Cursor, Codex or claude.ai to services, since those clients speak MCP.

Use A2A when you're building agents that delegate to other agents, especially across team or company lines, and the remote side should keep its own tools and credentials.

Use both when an agent has its own tools and also hands parts of a goal to other agents.

Where access control fits

The protocols put trust in different places. With A2A, the Agent Card can declare authentication requirements for the agent and for individual skills (securityRequirements on each AgentSkill); the remote agent still controls its internal tool calls, and you don't see them. With MCP, each tool call passes through your client, so you can write rules per tool.

Those MCP rules can live in each client's settings, compared in the MCP allowlist guide, or in a gateway in front of the servers, such as Toolstile. A gateway doesn't change A2A traffic, and it can't make a remote agent's internal tool use visible to you. What an MCP gateway is explains what it does cover, and MCP security risks lists the threats that apply to tool calls whichever agent makes them.