MCP and A2A solve different problems, so most teams don't choose between them. MCP (Model Context Protocol) standardizes how one agent connects to tools, data and prompts. A2A (Agent2Agent) standardizes how independent agents, often built by different teams or vendors, discover each other, delegate tasks and return results. Use MCP when the thing you are calling is a tool. Use A2A when it is another agent that makes its own decisions.

That one-line rule covers most of the MCP vs A2A question. The rest of this guide explains what each protocol actually specifies as of October 2026, where the line between "tool" and "agent" gets blurry, and how to run both in one system.

MCP vs A2A at a glance

ItemMCPA2A
ConnectsAn agent (host) to tools, resources and promptsAn agent (client) to a remote, opaque agent
Unit of workA tool call that returns a resultA task with a lifecycle, messages and artifacts
Discoverytools/list, plus optional server/discoverAn Agent Card, usually at /.well-known/agent-card.json
Transportsstdio, Streamable HTTPJSON-RPC over HTTP with SSE streaming, gRPC, HTTP+JSON
Long-running workTasks extension, poll-basedBuilt in: task states, streaming, push notifications
Current version2026-07-281.0
StewardAgentic AI Foundation (Linux Foundation)Linux Foundation project, also listed by AAIF
Started byAnthropic (2024)Google (2025)

Read aloud, the key differences are these. MCP's unit is a single tool call, and the caller stays in charge. A2A's unit is a task that the remote agent owns, which may run for minutes or hours, pause to ask for input, and stream back partial results.

What MCP is

The Model Context Protocol lets an AI application, which MCP calls the host, connect to servers that expose three things: tools the model can call, resources it can read, and prompts the user can pick. A GitHub server might expose "create issue" as a tool. A docs server might expose pages as resources.

The 2026-07-28 revision changed MCP significantly. The protocol is now stateless. The connection handshake and protocol sessions were removed, and every request describes itself. Server-initiated requests such as sampling and elicitation were replaced by a pattern called Multi Round-Trip Requests: the server answers "input required" and the client retries with the answers attached. Roots, Sampling and Logging are deprecated, with a minimum twelve-month window before removal.

What MCP does not define is how the tool reaches its answer. A tool is a function with a schema. The calling agent decides when to use it and what to do with the result.

If you want to build one, our step-by-step guide to building an MCP server in Python uses the current SDK.

What A2A is

The Agent2Agent protocol is for talking to an agent you don't control and can't see inside. Its documentation calls these agents "opaque": they don't share internal memory, tools or prompts, only results.

An A2A interaction works like this:

  1. Discovery. The client fetches the remote agent's Agent Card, a JSON document describing its skills, supported interfaces and security schemes. The conventional location is /.well-known/agent-card.json.
  2. Send a message. The client calls SendMessage, or SendStreamingMessage to stream updates. The remote agent may answer directly or create a task.
  3. Task lifecycle. Tasks move through states such as working, input-required, auth-required, completed, failed, canceled and rejected. If the remote agent needs something, it moves the task to input-required and the client replies on the same task.
  4. Artifacts. Outputs come back as artifacts made of typed parts, such as text, files or structured data.
  5. Async updates. For long jobs, clients can subscribe to a task or register a push-notification webhook instead of holding a connection open.

A2A version 1.0 was the first stable release. It consolidated how an agent advertises interfaces (each interface now declares its own protocol binding and version), added multi-tenancy, and clarified signed Agent Cards. Official SDKs exist for Python, JavaScript, Java, .NET, Go and Rust; in Python, pip install a2a-sdk.

Google created A2A and donated it to the Linux Foundation. According to the project site, its Technical Steering Committee includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow. In April 2026, the Linux Foundation reported more than 150 supporting organizations.

Tool or agent? How to decide

The blurry case is a remote service that uses an LLM internally. Is a "research agent" a tool or a peer? Ask these questions.

  • Who owns the plan? If your agent decides each step and the remote side just executes, it's a tool, so use MCP. If you hand over a goal and the remote side plans its own steps, it's an agent, so use A2A.
  • How long does it run? Seconds suggests a tool call. Minutes to days, with pauses for approval, fits A2A's task lifecycle better.
  • Does it need to ask questions back? Both protocols can now request input mid-call. A2A's input-required state is designed for multi-turn back-and-forth, though, while MCP's version is for a quick confirmation or a missing parameter.
  • Is it across an organizational boundary? A2A was designed for agents run by different companies, with Agent Cards, declared security schemes and signed cards. MCP servers are more often internal integrations.
  • Do you need to see inside? MCP exposes tool schemas the model reads directly. A2A deliberately hides the remote agent's internals.

A simple rule of thumb: if you could replace it with a well-documented REST endpoint, it's a tool. If you'd otherwise email a colleague to get it done, it's an agent.

How MCP and A2A work together

The A2A project's own documentation describes the protocols as complementary, and a typical architecture uses both:

  • A user talks to a client agent, built with any framework.
  • The client agent uses MCP to reach its own tools: the company database, a ticketing system, a code repository.
  • When a job needs a specialist owned by another team or vendor (a travel-booking agent, a compliance-review agent), the client agent sends it a task over A2A.
  • That specialist uses its own MCP servers internally, which the client never sees.

Frameworks increasingly support both. Google's Agent Development Kit lists MCP tools and structured agent-to-agent delegation among its features. Microsoft's Agent Framework, the successor to AutoGen and Semantic Kernel, advertises interoperability through both A2A and MCP. The A2A Linux Foundation announcement names agents built on LangGraph or CrewAI working together over the protocol. Check each framework's current docs for the exact level of support, because adapters change quickly.

What about ACP and other protocols?

Two different protocols have used the ACP acronym, which causes confusion in "MCP vs A2A vs ACP" searches.

  • IBM's Agent Communication Protocol overlapped with A2A. The A2A documentation now lists it as incorporated into A2A, so new projects should use A2A.
  • The Agent Client Protocol (agentclientprotocol.com) connects code editors to coding agents, much as the Language Server Protocol connects editors to language servers. It reuses MCP's JSON types where possible. It isn't a competitor to either protocol; it covers the editor-to-agent link.

Pros and cons

MCP pros: Very wide host support across coding agents, IDEs and chat apps. Simple mental model. Fast to build with the official SDKs. The stateless core is easy to scale.

MCP cons: Not designed for delegating open-ended goals. Each tool description adds context to every request. The 2026-07-28 changes mean older servers and clients need migration work.

A2A pros: Purpose-built for long-running, multi-turn delegation between independent agents. Strong discovery and security story. Vendor-neutral governance with broad industry backing.

A2A cons: More moving parts than a tool call. Fewer off-the-shelf consumer hosts. Overkill when you control both sides and a tool would do.

Who should use which

  • Building an internal assistant or coding agent? Start with MCP. You may never need A2A.
  • Exposing your product to other companies' agents? Publish an MCP server for simple actions. Consider an A2A agent if customers want to delegate whole workflows.
  • Building a multi-agent system inside one codebase? Use your framework's native sub-agent features. The A2A docs say it is not meant for an agent talking to its own sub-agents.
  • Connecting agents across teams, clouds or vendors? That is A2A's core use case.

For instruction files that sit alongside your MCP setup in coding agents, see our AGENTS.md guide.

Related guides: see which MCP servers give agents web access in Tavily vs Exa vs Firecrawl, and compare the frameworks that use these protocols in LangGraph vs CrewAI vs OpenAI Agents SDK and the best TypeScript AI agent frameworks.

FAQ

Is A2A a replacement for MCP?

No. The A2A project says explicitly that it is not a replacement for MCP. MCP handles agent-to-tool communication and A2A handles agent-to-agent communication. Many systems use both.

Can an MCP server be an agent?

Technically, an MCP tool can call an LLM internally and behave like an agent. But MCP treats it as a tool: the caller decides when to call it and gets a result back. If you need the remote side to own a long-running task, ask follow-up questions and stream artifacts, A2A fits better.

Who controls MCP and A2A?

Neither is controlled by a single company. Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, in December 2025. Google donated A2A to the Linux Foundation, and the AAIF website now lists A2A among its projects too.

Is A2A production-ready?

A2A 1.0 is its first stable specification. The Linux Foundation reported production deployments and integration across Google, Microsoft and AWS platforms in April 2026. As with any protocol, check that your framework's A2A support targets version 1.0 rather than 0.3.

Do I need A2A for a multi-agent app?

Usually not if all agents live in one codebase. Frameworks like LangGraph or CrewAI coordinate their own agents natively. A2A becomes valuable when agents are deployed separately, built on different stacks, or owned by different organizations.