MCP vs A2A: Which Agent Protocol Do You Need?

Both protocols now live under the same roof, which settles the "which standard wins" debate that ran through 2025. The more useful question now is which layer of your system each one belongs to. Here is how I think about it when I design agent systems for clients.

Both protocols now sit in one foundation

The Linux Foundation launched the Agentic AI Foundation (AAIF) in December 2025, with Anthropic contributing MCP alongside Block's goose and OpenAI's AGENTS.md. In August 2026, the AAIF announced that A2A, originally created by Google, was joining as a hosted project, with more than 150 partner organisations behind it.

The practical effect: you are no longer betting on a vendor. Both are neutral, openly governed specifications. The specs stay separate, with their own maintainers and release cycles, because they solve different problems.

What MCP does

MCP standardises how an AI application talks to tools and context. You write an MCP server that exposes capabilities, such as "search the knowledge base", "create a ticket" or "read this customer's orders", and any MCP-capable client can use them. I walked through a full build in how to build an AI agent with MCP and Claude. Search is the MCP tool I build most often, and agentic RAG covers how an agent should use it.

The protocol changed a lot in 2026. The 2026-07-28 specification was the largest revision since launch, and the maintainers' roadmap published in August 2026 sets five priorities for what comes next:

• Agentic messaging primitives for long-running work, server-initiated events and streamed results.
• HTTP-native transport, so that, in the roadmap's words, "a remote MCP server is now no different from any other HTTP workload."
• Agent identity and enterprise security, built on existing standards "rather than pasted API keys and long-lived tokens."
• Improved primitives, including progressive discovery so large tool catalogues do not flood the model's context.
• Better SDK developer experience across languages.

Read that list and you can see MCP growing toward the boundary with A2A: long-running tasks and agent identity are agent-to-agent concerns too. That convergence is one reason I expect "MCP vs A2A" to stay a common search for a while yet.

What A2A does

A2A standardises how two agents talk to each other as peers. One agent can discover another, find out what it can do, send it a task, and receive progress and results, without either side exposing its internal tools, prompts or memory.

That last point is the important design difference. With MCP, the client agent sees the tools and decides how to call them. With A2A, the client agent delegates a goal and the remote agent decides how to achieve it. The remote agent is a black box with a contract.

MCP vs A2A side by side

A concrete way to decide

I ask three questions on every project.

Does the other side have its own reasoning?

If the thing your agent calls is deterministic, such as a database query, a CRM update or a search index, it is a tool. Expose it over MCP. If the other side needs to plan, call its own tools and make judgement calls, it is an agent, and A2A is the right contract.

Who owns the other side?

Inside one codebase, you rarely need A2A. When I built AgentOps, a multi-agent pipeline that turns a Slack request into a Confluence spec, Jira tickets, a GitHub pull request and a live Vercel preview, every agent was mine. The stages hand off through approved artifacts and human checkpoints, not a cross-vendor protocol. A2A starts to pay for itself when the other agent belongs to a different team, a partner or a SaaS vendor, and you cannot reach into its internals.

What must stay private?

If a partner will not expose its tools or data to your agent, but will accept a task and return a result, that is A2A's design point. It lets two organisations collaborate without sharing prompts, tool lists or memory.

How they fit together

In the systems I expect most companies to build in 2027 and 2028, both appear at different layers:

• Each agent uses MCP to reach its own tools and data.
• Agents that cross a team or company boundary talk over A2A.
• A human approval step sits in front of any action that changes money, contracts or customer records.

A realistic example: your procurement agent uses MCP to read your ERP and your contract repository. When it needs a quote, it sends an A2A task to a supplier's sales agent, which uses its own MCP servers to check stock and pricing. Neither company sees the other's tools. Your agent gets back a structured quote and routes it to a person for approval.

What I would build first

For most businesses I work with, the answer today is MCP first, A2A later:

• Start with MCP servers for your own systems. They are useful immediately to Claude, coding agents and any MCP client, and they force you to decide permissions and schemas properly. My design system MCP server is an example: it lets coding agents build on-brand UI from real components instead of guessing at styles.
• Design those servers with agent identity in mind. The MCP roadmap's move toward standard agent identity means "one shared API key for the bot" will age badly. Authenticate the user the agent acts for.
• Add A2A at the edges when a partner, vendor or another internal team exposes an agent you need to work with.
• Avoid building your own agent-to-agent protocol. In 2025 that was defensible. With A2A openly governed, a custom protocol is a maintenance cost with no upside.

Security notes for both

Protocols do not make agents safe; design does. The rules I apply:

• Separate read tools from write tools, and gate consequential writes behind human approval.
• Enforce permissions on the server, never in the prompt.
• Treat everything an external agent sends you as untrusted input, the same way you treat a web form.
• Log every tool call and every A2A task, with inputs and outputs, so any action can be replayed.

Work with me

If you want your internal systems reachable by AI agents, or you need agents that work across teams or vendors, I build both. See MCP server development and AI agent development, or book a scoping call to map which protocol belongs where in your stack.