Agent interoperability protocols: MCP, A2A and the rest

An agent is only as useful as what it can reach: files, databases, other agents, the person at the screen, a checkout. Until late 2024 most of those connections were custom code, one integration at a time. Two years on there is a protocol for each of them, the two main ones share a foundation, and MCP rewrote its core in July 2026. This post maps the field as of October 2026: what each protocol connects, how the two main ones differ, where they are weak, and how to build with them. Every claim links to its source. I will update this page as the protocols move; the date above says when I last checked.

Why the protocols matter

When Anthropic released the Model Context Protocol (MCP) in November 2024, it described the problem plainly: every new data source needed its own custom implementation (Anthropic, 2024). The specification says MCP takes inspiration from the Language Server Protocol, which did the same job for programming languages and editors (MCP specification, 2026). Write a server once, and any compliant client can use it.

Google announced the Agent2Agent protocol (A2A) in April 2025 for a different connection: agents built by different vendors working with each other. Google described it as complementing MCP, not competing with it (Google, 2025).

Both have since moved to neutral governance. The Linux Foundation formed the Agentic AI Foundation (AAIF) in December 2025 with three founding projects: MCP from Anthropic, goose from Block and AGENTS.md from OpenAI. Its platinum members include AWS, Anthropic, Google, Microsoft and OpenAI (Linux Foundation, 2025). A2A, first donated to the Linux Foundation in June 2025 (Linux Foundation, 2025), joined AAIF as a hosted project in August 2026. AAIF now places MCP at the “agent to tool” layer and A2A at the “agent to agent” layer (AAIF, 2026).

Standards bodies have started work as well. In February 2026 NIST’s Center for AI Standards and Innovation launched an AI Agent Standards Initiative. Its three pillars are industry-led standards, community-led open-source protocols, and research on agent security and identity (NIST, 2026).

For anyone building agents, the practical point is simpler. A protocol decides what your agent can connect to without new code, what an attacker can reach through it, and how much rework the next revision will cost you.

A map of the landscape

The protocols sort cleanly by what sits at each end of the connection.

• Agent to tools and data: MCP, plus WebMCP for tools that a web page exposes to an agent in the browser.
• Agent to agent: A2A, and the Agent Network Protocol (ANP) for open networks built on decentralised identifiers.
• Agent to person: AG-UI for application front ends, MCP Apps for interactive UI inside a chat client, and the Agent Client Protocol for code editors.
• Agent to commerce: the Agent Payments Protocol (AP2), the Agentic Commerce Protocol and the Universal Commerce Protocol (UCP).
• Instructions for coding agents: AGENTS.md, which is a file convention, not a wire protocol (AGENTS.md).

One warning before the tables. “ACP” names three unrelated things: IBM’s Agent Communication Protocol (now part of A2A), Zed’s Agent Client Protocol, and the Agentic Commerce Protocol from Stripe, OpenAI and Meta. Check which one a document means.

Core protocols compared

Commerce protocols compared

MCP in detail

What it standardises

MCP uses JSON-RPC 2.0 messages between three roles. Hosts are the LLM applications, clients are the connectors inside a host, and servers provide context and capabilities. Servers offer three features: resources (context and data), prompts (templated messages and workflows) and tools (functions the model can execute). Clients can offer elicitation, which lets a server ask the user for more information (MCP specification, 2026).

Two transports are standard. With stdio, the client launches the server as a subprocess and exchanges newline-delimited messages over its standard streams. With Streamable HTTP, each message is an HTTP POST to a single endpoint, and replies arrive as JSON or as a request-scoped event stream (MCP transports, 2026).

Five revisions in two years

MCP versions are dates. Each revision has changed something that implementers had to follow.

The stateless rewrite

The July 2026 revision changed the protocol’s core. Its authors describe MCP moving “from a bidirectional stateful protocol into a request/response stateless protocol” (Soria Parra and Delimarsky, 2026). The changelog spells out what that means (MCP changelog, 2026):

• The initialize handshake and protocol-level sessions are gone. Every request carries its protocol version and client capabilities in _meta.
• A new server/discover call, which servers must implement, advertises supported versions and capabilities.
• Servers no longer send requests to clients. When a tool needs more input, the server returns a result of type input_required, and the client retries the original request with the answers. This pattern, Multi Round-Trip Requests, replaces server-initiated elicitation, sampling and roots requests.
• Servers that need state across calls mint their own handles and receive them back as ordinary tool arguments.
• Streamable HTTP requests must carry Mcp-Method and Mcp-Name headers, so gateways can route without parsing the body (Soria Parra and Delimarsky, 2026).
• List results carry ttlMs and cacheScope, so clients and shared intermediaries can cache them.
• Trace context for OpenTelemetry is documented as _meta keys.

The practical effect: any request can go to any server instance behind a round-robin load balancer (Soria Parra and Delimarsky, 2026). The cost is real. Stream resumability is gone, so a broken response stream loses the in-flight request and the client must re-issue it (MCP changelog, 2026). The announcement itself flags migration cost, especially for anyone who relied on session identifiers (Soria Parra and Delimarsky, 2026).

The same revision adopted a deprecation policy with a minimum twelve-month window. Roots, Sampling and Logging are deprecated, along with the old HTTP+SSE transport and Dynamic Client Registration (MCP changelog, 2026). Four Tier 1 SDKs (TypeScript, Python, Go and C#) support the revision, Rust in beta. The maintainers report close to half a billion monthly downloads across the Tier 1 SDKs (Soria Parra and Delimarsky, 2026).

Authorisation

Authorisation in MCP is optional. When it is used over HTTP, the server acts as an OAuth 2.1 resource server and must publish Protected Resource Metadata (RFC 9728) so clients can find its authorisation server. Clients must send a resource parameter (RFC 8707) that names the server, and servers must reject tokens issued for anyone else. Over stdio, implementations should not use this flow and should take credentials from the environment instead (MCP authorization, 2026).

Client registration has moved in steps. The November 2025 revision recommended Client ID Metadata Documents, where the client ID is an HTTPS URL pointing to the client’s metadata (MCP changelog, 2025; MCP client registration, 2026). The July 2026 revision deprecated Dynamic Client Registration and requires clients to validate the issuer (iss) in authorisation responses, per RFC 9207, when it is present (MCP changelog, 2026).

Extensions and the registry

Since July 2026, optional features live in extensions that client and server both opt into. Tasks for long-running work, MCP Apps and Enterprise Managed Authorization are the ones named in the release (Soria Parra and Delimarsky, 2026). MCP Apps, the first official extension, shipped in January 2026. A tool can point to a ui:// resource, and the host renders it in a sandboxed iframe that talks to the host over postMessage. Claude, Goose and VS Code Insiders supported it at launch, with ChatGPT following that week, and it standardises patterns from MCP-UI and OpenAI’s Apps SDK (MCP blog, 2026).

The official MCP Registry launched as a preview in September 2025, as a catalogue of publicly available servers that public and private sub-registries can build on (MCP blog, 2025). Its README still describes a frozen v0.1 API, with general availability to follow (MCP Registry).

A2A in detail

What it standardises

A2A is for agents that stay opaque to each other. The specification lists “opaque execution” as a principle: agents collaborate through declared capabilities and exchanged information without sharing internal plans or tool implementations (A2A specification). Its own comparison puts the line clearly. MCP connects an agent to tools and resources; A2A lets independent agents discover each other, manage shared tasks and delegate work. A remote agent reached over A2A may use MCP internally to do that work.

The core objects are these (A2A specification):

• Agent Card: a JSON document describing an agent’s identity, capabilities, skills and interaction requirements. Clients find it at /.well-known/agent-card.json, in registries or through direct configuration.
• Task: the unit of work, with eight lifecycle states plus an unspecified value. Two of them, input-required and auth-required, pause a task until the client supplies input or credentials.
• Message and Part: a turn in the conversation and the content it carries.
• Artifact: an output such as a document, image or structured data.

Long-running work is handled with streaming updates or push notifications, which the server delivers by HTTP POST to a webhook the client provides (A2A specification).

Version 1.0

A2A v1.0.0 was released on 12 March 2026 and v1.0.1, a bug-fix release, on 28 May 2026 (A2A releases). The project lists these changes from v0.3 (A2A, What’s New in v1.0):

• Three formally specified bindings, JSON-RPC, gRPC and HTTP+JSON, with equivalence guarantees.
• Agent Cards can be signed with JSON Web Signatures over a canonical form of the card (RFC 8785).
• A tenant field lets one endpoint serve many agents.
• A new operation lists tasks, scoped to the caller, with cursor-based pagination.
• The OAuth implicit and password flows are gone; the device code flow and a PKCE requirement flag are added.
• Clients send an A2A-Version header, and each interface in an Agent Card declares its own version.

Adoption

In April 2026 the Linux Foundation reported more than 150 supporting organisations, integration in Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore Runtime, and SDKs grown from a single Python implementation to five languages (Linux Foundation, 2026). These are the project’s own figures; there is no independent count of production deployments.

MCP and A2A side by side

Sources: MCP changelog, 2026, MCP authorization, 2026, A2A specification, A2A, What’s New in v1.0.

The rest of the field

Agent to agent beyond A2A

IBM’s Agent Communication Protocol was the other enterprise candidate. In August 2025 its maintainers announced that it was merging with A2A under the Linux Foundation (BeeAI, 2025), and the repository is now archived (BeeAI on GitHub).

ANP takes a different route. It aims to be “the HTTP of the Agentic Web era” and builds identity on W3C decentralised identifiers, including its own web-based did:wba method; a draft authorisation spec adds OAuth and verifiable credentials on top. Its authentication, identity, description and discovery specifications are released at v1.2; its meta-protocol, for agents to negotiate which interface to use, remains a draft (ANP). A 2025 survey suggested a phased path: MCP for tool access, then IBM’s ACP for structured messaging, A2A for collaborative tasks and ANP for decentralised marketplaces (Ehtesham et al., 2025). With ACP merged into A2A, that path now has three steps.

Agent to person

AG-UI is an event-based protocol between an agentic back end and a user-facing application. It describes itself as the general-purpose, bi-directional connection between front ends and agent back ends, built on HTTP and WebSockets. Its documentation places it beside MCP and A2A as a third layer, not a competitor (AG-UI).

The Agent Client Protocol does the same job for code editors. Zed released it in August 2025 under the Apache licence, with Google’s Gemini CLI as the first agent (Zed, 2025). Local agents run as subprocesses of the editor and speak JSON-RPC over stdio; the protocol reuses MCP’s JSON representations where possible (Agent Client Protocol).

WebMCP brings the tool idea into the browser. The draft defines a JavaScript API that lets a web application provide tools to AI agents. It is a Draft Community Group Report of the W3C Web Machine Learning Community Group, edited by people from Microsoft and Google, and it states that it is not a W3C Standard (WebMCP).

Agent to commerce

Payments need proof of what the user approved. AP2 answers with mandates: cryptographically signed records of the user’s instructions. An Intent Mandate captures the request and its limits; a Cart Mandate records the exact items and price the user approved (Google Cloud, 2025). The Agentic Commerce Protocol covers checkout sessions, carts and product feeds, delegated payment, delegated authentication and order webhooks (Stripe). UCP covers discovery through checkout and after, supports AP2, A2A and MCP, and has a draft specification for lodging (UCP).

My read: commerce is the one layer where competing protocols backed by large platforms are still running in parallel, and the overlap between them is substantial. UCP’s explicit support for AP2, A2A and MCP suggests the layers below are settling even where this one is not.

Methods and their trade-offs

Expose tools or delegate to an agent

The first design choice is what a caller should see. MCP exposes every tool, with its schema and description, so the calling model plans each step. A2A exposes a skill list and hides the rest, so the remote agent plans its own steps and the caller sees tasks and artifacts (A2A specification).

Exposing tools gives the caller control and makes each action visible to the host’s consent checks. It also puts the provider’s tool descriptions into the caller’s context, where they become part of the attack surface (see below). Delegating keeps the provider’s internals private and lets each side change its implementation freely. It also means the caller cannot see, and so cannot audit, what happened inside the task. The choice often follows ownership: tools for systems you control or trust, delegation across organisational boundaries.

Direct tool calls, code execution or tool retrieval

Tool definitions cost context. Anthropic’s engineering team observed that most clients load every tool definition up front and pass every intermediate result through the model. In their example, presenting MCP servers as code APIs that the agent calls from a sandbox cut token use from about 150,000 to 2,000, a 98.7% saving. They also note the price: the agent’s code needs a secure sandbox with resource limits and monitoring (Jones and Kelly, 2025).

Retrieval is the other route. RAG-MCP picks the relevant tools from an index before the model sees them, and reports cutting prompt tokens by over 50% while raising tool selection accuracy from 13.62% to 43.13% in its tests (Gan and Sun, 2025).

Local or remote servers

A local stdio server is simple and needs no OAuth flow: it reads credentials from the environment (MCP authorization, 2026). It also runs as a program on the user’s machine with the client’s privileges. The MCP security guidance lists malicious startup commands, malicious payloads and DNS rebinding against servers left on localhost, and requires clients that offer one-click local setup to show the exact command and get consent (MCP security best practices). A remote server that requires authorisation implements the full OAuth flow, and since July 2026 it can scale horizontally like any stateless HTTP service.

Stateful or stateless

A stateful protocol makes server-to-client requests and resumable streams easy. A stateless one makes load balancing, caching and gateways easy. MCP has now chosen the second (Soria Parra and Delimarsky, 2026), and A2A keeps state where it belongs to the work, in tasks (A2A specification). The complexity moves to the server: one that needs continuity now issues its own handles and must protect them. The MCP guidance says possession of a handle must never count as authentication, and handles should be random and bound to the authenticated user (MCP security best practices).

Identity and trust

The protocols use three models of identity. MCP and A2A build on OAuth and other established web schemes (MCP authorization, 2026; A2A specification). A2A adds signed Agent Cards, so a client can verify that a card came from the claimed provider and was not altered (A2A specification). ANP uses decentralised identifiers (ANP), and AP2 uses verifiable credentials to sign mandates (Google Cloud, 2025). OAuth fits enterprises that already run identity providers. Decentralised identifiers suit open networks with no shared authority, at the cost of a smaller ecosystem.

Security

A protocol that lets a model read untrusted text and act on it inherits prompt injection. MCP’s specification says so directly: tool descriptions and annotations should be treated as untrusted unless they come from a trusted server, hosts must get explicit consent before invoking any tool, and MCP cannot enforce these principles at the protocol level (MCP specification, 2026).

Simon Willison named the dangerous combination the “lethal trifecta”: access to private data, exposure to untrusted content, and the ability to communicate externally. He argues MCP makes it easy to assemble because users mix tools from different sources, and that no known defence prevents the resulting attacks 100% of the time (Willison, 2025).

Research supports the picture. A 2025 audit showed leading models could be coerced through MCP tools into malicious code execution, remote access control and credential theft (Radosevich and Halloran, 2025). A threat taxonomy covers four attacker types and 16 threat scenarios across a server’s lifecycle (Hou et al., 2025). A study of 1,899 open-source MCP servers found general vulnerabilities in 7.2% and MCP-specific tool poisoning in 5.5% (Hasan et al., 2025).

Open problems

Security is still the host’s job

The protocols specify consent and authorisation; they cannot make a model ignore instructions in data it reads. The MCP specification says so (MCP specification, 2026), and so does Willison’s analysis (Willison, 2025). My read: until models resist injection reliably, the safest design keeps at least one leg of the trifecta out of any single agent session.

Agents still struggle with real servers

A standard interface does not make a tool easy to use. On MCP-Universe, built on 11 real MCP servers across six domains, GPT-5 scored 43.72%, and an enterprise agent such as Cursor did no better than a standard ReAct loop (Luo et al., 2025). On MCPMark’s 127 tasks, the best model reached 52.56% pass@1 and 33.86% pass^4, with an average of 17.4 tool calls per task (Wu et al., 2025). MCP-Bench, with 28 live servers and 250 tools, reports persistent challenges across 20 models (Wang et al., 2025). These are 2025 results on 2025 models. What they show is a gap between connecting to a tool and using it well.

Context cost

Every connected tool spends context before the user’s request is read. Code execution and tool retrieval reduce that cost but add a sandbox or an index to run (Jones and Kelly, 2025; Gan and Sun, 2025). No protocol yet standardises which approach a client should take.

Discovery and trust

The protocols specify how to find a server or an agent, not whether to trust it. The MCP Registry holds self-reported information from server maintainers (MCP blog, 2025) and is still a preview (MCP Registry). Signed Agent Cards prove who published a card, not whether the agent behind it behaves (A2A specification). NIST’s initiative includes research on agent security and identity, and it has asked for public input on agent security and on agent identity and authorisation (NIST, 2026).

Coordination beyond tasks

The protocols move work between agents; they do not govern groups of agents. A gap analysis of MCP, A2A, ACP, ANP and ERC-8004 found voting and dissent preservation absent from all five, and deliberation absent or at most partial. The authors argue governance is a missing layer above these protocols, not a missing feature inside them (Kang and Diponegoro, 2026).

Churn

MCP has published five revisions since November 2024, and the latest removed the handshake that every earlier client relied on (MCP changelog, 2026). A2A v1.0 listed breaking changes across its schema, bindings and OAuth flows (A2A releases). Both projects now have explicit answers: MCP a twelve-month deprecation window, A2A per-interface versions that let an agent serve old and new clients at once (A2A, What’s New in v1.0). Speculation: the next year should be quieter for both cores, with most change moving into extensions.

How to choose and apply

Which protocol for which connection

• Your agent needs tools or data you control or trust: MCP. Prefer remote Streamable HTTP servers for shared services and stdio for personal, local tools.
• Your agent hands work to another team’s or vendor’s agent, which should keep its internals private: A2A.
• Agents across organisations with no shared identity provider: watch ANP, but expect a smaller ecosystem.
• Your agent streams progress and state to your own front end: AG-UI. To show interactive UI inside Claude, ChatGPT or another MCP host: MCP Apps.
• Your coding agent should run inside more than one editor: the Agent Client Protocol.
• Your agent pays for things: start from what your payment provider and merchants support (AP2, the Agentic Commerce Protocol or UCP), and check which of the three your counterparties actually implement.
• Your agent only calls one internal API you own: a direct function call may be enough. A protocol pays off when either side has more than one counterpart.

When you build an MCP server

1. Target revision 2026-07-28 with a Tier 1 SDK. Do not build on Roots, Sampling, Logging or HTTP+SSE (MCP changelog, 2026).
2. Keep the server stateless. If you need continuity, mint random handles bound to the authenticated user (MCP security best practices).
3. Over HTTP, implement Protected Resource Metadata, validate the token audience and never pass a client’s token downstream (MCP authorization, 2026; MCP security best practices).
4. Start with minimal scopes and request more through step-up challenges when a privileged tool is first used (MCP security best practices).
5. Return tools in a deterministic order so clients can cache them (MCP changelog, 2026).
6. Mark read-only and destructive tools with annotations (MCP changelog, 2025), knowing that clients should treat them as untrusted unless they trust your server (MCP specification, 2026).

When you build an MCP client or host

1. Get explicit user consent before invoking a tool, as the specification requires (MCP specification, 2026), and show the full tool description and arguments, not a shortened name (Invariant Labs, 2025).
2. Pin server versions and require re-approval when a tool description changes.
3. Run local servers in a sandbox with restricted file system and network access (MCP security best practices).
4. Validate every URL a server gives you: no shell to open it, no private IP ranges, https only outside loopback (MCP security best practices).
5. Load tool definitions on demand once you connect more than a few servers (Jones and Kelly, 2025).
6. Do not combine private data, untrusted content and an outbound channel in one session without a human check (Willison, 2025).

When you expose an agent over A2A

1. Publish an Agent Card at /.well-known/agent-card.json and sign it (A2A specification).
2. Declare skills precisely. The card is all a caller knows about your agent.
3. Use the input-required and auth-required states instead of failing a task that needs more from the user (A2A specification).
4. Prefer push notifications for work that runs longer than a client can hold a stream open.
5. Use authorisation code with PKCE or the device code flow; v1.0 removed the implicit and password flows (A2A, What’s New in v1.0).
6. Serve the old and new protocol versions side by side during a migration, as separate interfaces in the card (A2A, What’s New in v1.0).

Test what you connect

Protocol conformance is the floor. Evaluate your agent against the real servers it will use, with tasks that need many calls and with injected instructions in the data it reads. The MCP benchmarks above show that both matter (Luo et al., 2025; Wu et al., 2025). The companion post, How AI agents are evaluated, covers the methods.