MCP vs A2A: Which Agent Protocol Do You Need?

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.

What's new (October 24, 2026): The Agentic AI Foundation, which already stewarded MCP and lists A2A as one of its projects, added four more on October 22: Anthropic's Agent Skills, OpenAI's Open Responses, Hugging Face's OpenEnv and Alibaba's OpenSandbox. Both protocols in this guide are unchanged (MCP 2026-07-28, A2A 1.0).

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

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.

For the full basics (hosts, clients, transports and security), read what is MCP. If you want to build one, our step by step guide to building an MCP server in Python uses the current SDK.

When an agent has many MCP tools, some hosts now let it call them by writing a short script instead of one tool call at a time. See what Code Mode is.

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 multitenancy, 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 multiturn 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, multiturn 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 multiagent system inside one codebase? Use your framework's native subagent features. The A2A docs say it is not meant for an agent talking to its own subagents.
• 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.

From Ahzy Capital (our own products, labeled as such): Get the free AI Agent Cheat Sheet: 24 copy and paste AI agent setups for 8 types of small business, with prompts and workflows. We make and sell these, so they aren't independent picks.

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 A2A is now one of AAIF's hosted projects. As of October 22, 2026, AAIF hosts 10 projects, including AGENTS.md, goose, Agent Skills and Open Responses, per its announcement.

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 multiagent 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.