DM Explains · No. 050 · Architecture
The interfaces are arriving: how MCP and A2A are wiring up AI agents
Competing AI vendors are quietly agreeing on shared plumbing for tools and agents, but the agreement covers shape, not meaning — and that gap is where it breaks.
· 15 min read
Read me first
MCP and A2A genuinely do remove the need for bespoke wiring between AI applications, tools and other agents — but they standardise shape, not meaning, and that gap doesn't close as the spec matures; it just moves.
Illustrative: a household assistant (host) asks its MCP client to check Arjun's school timetable; a connector (server) exposes a calendar tool with 97 million monthly SDK downloads of code like it behind it; the client picks the right tool from its menu; a second, rival assistant's client connects to the same server over cross-vendor support; both run under Agentic AI Foundation governance; the booking step is handed via A2A, signed Agent Card and all, to a second agent; that agent's schema shows it accepts a time and a service type, but nothing in the shape tells it whether 'dentist' means a six-month checkup or an emergency — the slot gets booked, not trusted to be the right one.
A team builds three different AI assistants for the same household of tasks — one in a chat app, one in a coding tool, one in a scheduling bot — and wires each one, by hand, to the same calendar, the same database, the same search tool. The wiring works. Then one vendor changes an API shape, and all three integrations break separately, on different days, in different ways no one remembers writing down.
That's not a bug in any one team's engineering. It's the cost of a world where every pair of AI application and tool needs its own custom glue code. Multiply three assistants by five tools and the maintenance burden stops being linear.
Everyday picture. Instead of Amma learning a different way to talk to the electrician, the plumber and the school librarian each time, the house agrees on one common form everyone fills in to request help — anyone who speaks that form is understood by anyone else in the house. Dadi and Bruno's vet even start using the same kind of introduction card, so when she hands over Bruno's health record, the vet trusts it without a phone call to double-check.
Where the picture breaks. The form only captures what information is needed, not whether the electrician is the right person for a plumbing problem — the household still has to judge when a given helper's skill actually applies. And a trusted-looking introduction card from one office can quietly mean something different at another; the card format alone can't settle that.
Why it exists now
The problem is old: every integration between a model and an external tool used to be written from scratch, tied to one vendor's API, and liable to break the moment either side changed. What's new is that competing vendors have started agreeing on shared wiring rather than each defending their own.
In December 2025, Anthropic donated the Model Context Protocol (MCP) to the newly formed Agentic AI Foundation, a Linux Foundation directed fund co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg (The Interfaces Are Arriving — O'Reilly Radar, 2026). Six months earlier, Google had donated its Agent2Agent (A2A) protocol to the same foundation family. Neither protocol is owned by one company any more, which is precisely why rivals are willing to build on them.
MCP itself launched in November 2024 and has already gone through five dated protocol revisions, the current specification dated 28 July 2026. A2A reached version 1.0 in April 2026, with general availability inside Microsoft Copilot Studio, Azure AI Foundry and Amazon Bedrock AgentCore. The scale is no longer experimental: the December 2025 announcement cited more than 97 million monthly software development kit (SDK) downloads and over 10,000 active MCP servers.
None of this happened because a single vendor decided to be generous. It happened because the earlier approach — custom integrations multiplied by every pair of tool and application — was starting to cost more than any one company wanted to keep paying alone.
How it works
Illustrative: "check Arjun's school timetable and book a dentist slot" → 1 the assistant (host) parses the ask → 2 an MCP server exposes a calendar tool over JSON-RPC → 3 the timetable lookup runs, schema-shaped but meaning left to the model → 4 booking needs a different capability → 5 a signed Agent Card verifies the booking agent's identity → 6 that second agent books the slot via A2A → returned as booked, not verified as correct
Two boundaries are being standardised here, not one: an AI application reaching a tool, and an agent reaching another agent. They look similar on a diagram and they are not the same problem.
Hosts, clients, servers
One message format, not one wire per pair
What it is. MCP defines three roles: the host is the AI application a person actually uses; it runs clients that connect to servers, which expose tools, data and workflow templates.
Why it exists. Without a shared role split and message format, every host-tool pairing needs its own protocol, invented twice.
Where it breaks. A shared wire format says nothing about whether the tool on the other end does what its name suggests — the protocol carries the message, not the guarantee.
How that's handled. Treat MCP as plumbing, and keep judging individual servers on their actual behaviour, not their compliance with the spec.
In technical terms
In technical terms: MCP defines a client-server architecture in which hosts run clients that connect over JSON-RPC 2.0 to servers exposing tools, resources and prompts — a design explicitly inspired by the Language Server Protocol, which let any code editor talk to any programming-language tool (The Interfaces Are Arriving — O'Reilly Radar, 2026).
Tools, resources, prompts
Three primitives, one predictable menu
What it is. A server can offer three kinds of thing: callable tools, resources that hold context or data, and prompts describing templated workflows.
Why it exists. Giving a model a predictable menu — tool, resource, prompt — means any server, from any vendor, can be addressed the same way.
Where it breaks. The categories are structural, not semantic. Two tools can share a category and even a name and still act differently underneath.
How that's handled. Read the tool's actual description and test its behaviour; don't assume a shared category implies shared behaviour.
In technical terms
In technical terms: the three primitives are addressed through the same JSON-RPC interface regardless of implementation, which is what makes a server portable across hosts — but the schema says nothing about correctness.
Cross-vendor clients
Real infrastructure needs rivals, not one owner
What it is. MCP clients now ship as first-class features across competing AI products.
Why it exists. A protocol only becomes real infrastructure when competitors implement it independently, rather than one company dictating terms to everyone else.
Where it breaks. Breadth of adoption measures reach, not correctness — a server used by millions can still be wrong, slow or unsafe.
How that's handled. Watch adoption numbers as a sign the plumbing is stable, not as a certificate for any particular server.
In technical terms
In technical terms: first-class MCP client support spans ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code, with the maintainers' December 2025 figures citing over 97 million monthly SDK downloads and more than 10,000 active servers (The Interfaces Are Arriving — O'Reilly Radar, 2026).
Neutral governance
Rivals hand over the wiring, keep the rivalry
What it is. MCP and A2A are no longer controlled by the companies that created them; they sit under a vendor-neutral foundation.
Why it exists. Fierce competitors cooperate on the plumbing precisely because none of them wants to be the single point of control — or the single point of blame when it breaks.
Where it breaks. Neutral governance controls how the spec evolves, not what any individual vendor builds on top of it or how carefully they implement it.
How that's handled. Separate "is this protocol-compliant" from "is this trustworthy" when evaluating any tool or agent built on either standard.
In technical terms
In technical terms: in December 2025, Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation directed fund co-founded by Anthropic, Block and OpenAI with support from Google, Microsoft, AWS, Cloudflare and Bloomberg; Google had donated A2A to the same foundation family six months earlier (The Interfaces Are Arriving — O'Reilly Radar, 2026).
Agent-to-agent
The next boundary, agent talking to agent
What it is. A2A extends standardisation one layer up: not an application reaching a tool, but one agent reaching another agent built on a different vendor's stack.
Why it exists. Multi-agent systems need agents to discover each other, exchange goals and state, invoke actions and return results — across vendor lines, not just within one company's product family.
Where it breaks. A2A is younger and less proven in production than MCP, and a verified identity card says nothing about whether two agents mean the same thing by "confirmed" or "done".
How that's handled. Treat A2A deployments as newer ground than MCP ones; build in explicit checks for what each agent means by its own status words.
In technical terms
In technical terms: A2A reached v1.0 in April 2026 with signed Agent Cards for verifiable identity, SDKs in five languages, over 150 supporting organisations, and general availability in Microsoft Copilot Studio, Azure AI Foundry and Amazon Bedrock AgentCore (The Interfaces Are Arriving — O'Reilly Radar, 2026). Microsoft describes A2A as letting multi-agent apps exchange goals, manage state, invoke actions and return results securely and observably, while developers keep using familiar frameworks like LangChain (Empowering multi-agent apps with the open Agent2Agent (A2A) protocol — Microsoft, 2025).
Shape, not meaning
A schema can't tell you when a tool is right
What it is. The structural ceiling of both protocols: they describe the shape of a message, never its correct use.
Why it exists. A schema has to be formal and checkable, so it captures argument types and structure. Meaning — what the tool actually does, when it should be called — still lives in a free-form description a model has to interpret.
Where it breaks. Portability across hosts does not guarantee consistent behaviour across models and contexts. This is a limit of the approach, not a bug the next revision will fix.
How that's handled. Keep human and automated evaluation on actual tool and agent behaviour, independent of whether the interface is protocol-compliant.
In technical terms
In technical terms: a schema captures a tool's argument shape, but its meaning lives in a free-form natural-language description a model must interpret — the schema cannot say when a tool is appropriate or whether two similarly named tools are equivalent (The Interfaces Are Arriving — O'Reilly Radar, 2026).
Compared with what came before
| Custom integration | MCP / A2A | |
|---|---|---|
| Wiring per tool or agent | One bespoke integration per pair | One implementation, reused across hosts |
| Breakage on change | Breaks separately in every integration | Breaks once, at the server or agent |
| Trust in behaviour | Still has to be checked manually | Still has to be checked manually |
| Governance | Whoever built it | Neutral foundation (as of the protocols' current donations) |
| Maturity | Known, stable, slow to change | Actively revising (five MCP revisions; A2A at v1.0 as of April 2026) |
The honest reading of that table: the protocols remove duplicated wiring work, not duplicated judgement work. Every row about trust and correctness stays exactly where it was.
Where it breaks
Standardisation helps most when the failure mode is "we wrote this integration badly three times, differently." It does nothing for the failure mode "the tool does the wrong thing and we didn't notice," because that failure lives one layer below the protocol.
Not a semantics guarantee
A schema describes the shape of a tool's inputs and outputs. It does not describe when the tool is appropriate to call, how its effects interact with other tools in a chain, or whether two similarly named tools from different vendors actually behave the same way. Protocol compliance and correct behaviour are separate questions, and only one of them is checked by the spec.
A second, more practical risk is churn: MCP has already gone through five dated revisions in under two years, and A2A only reached v1.0 in April 2026, which the dossier describes as younger and less proven in production than MCP. Teams building directly against either spec without a thin adapter layer of their own risk migration breakage whenever the next revision lands.
A third is the trap of treating adoption numbers as a safety signal. Over 97 million monthly SDK downloads and more than 10,000 active servers say the plumbing is widely used, not that any particular server on that list is well-built, secure or honest about what it does.
Numbers to carry
| Figure | Value |
|---|---|
| MCP launch | November 2024 |
| MCP current spec revision | 28 July 2026 (5th dated revision) |
| MCP monthly SDK downloads | over 97 million (December 2025) |
| MCP active servers | over 10,000 (December 2025) |
| MCP cross-vendor clients | ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code |
| MCP donated to Agentic AI Foundation | December 2025 (by Anthropic) |
| A2A donated to foundation family | roughly six months before MCP's donation (by Google) |
| A2A version 1.0 | April 2026 |
| A2A supporting organisations | over 150 |
| A2A SDK languages | 5 |
| A2A general availability | Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore |
| NLIP standardised as ECMA-430 | December 2025, Ecma International (The Natural Language Interaction Protocol and Standard for AI Agents — arXiv, 2026) |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "MCP and A2A are the same thing with different names" | MCP standardises an application connecting to tools and data; A2A standardises one agent reaching another agent — adjacent but distinct boundaries. |
| "A shared protocol means the tools are safe" | The protocol standardises message shape; it carries no guarantee about a tool's actual behaviour or trustworthiness. |
| "This is the first attempt at agent standards" | NLIP (ECMA-430), standardised by Ecma International in December 2025, is a parallel, narrower effort for natural-language agent messaging, and other conventions like AGENTS.md and OpenTelemetry's generative-AI conventions are filling adjacent gaps. |
| "Once a protocol reaches v1.0, it stops changing" | MCP alone has had five dated revisions since November 2024; rapid revision is the norm here, not the exception. |
| "Vendor-neutral governance means vendors stop competing" | Anthropic, OpenAI, Google, Microsoft and AWS all support the same foundation while continuing to compete fiercely on models and products. |
Worked example
- Arjun asks the household's AI assistant to "check my school timetable and book a dentist slot." The assistant is the host.
- The host's MCP client sends a JSON-RPC request to a calendar server exposing a
get_timetabletool, following the shared message format MCP defines. - The calendar server returns the timetable as a resource; the host now has Arjun's free afternoon slots, without anyone having written custom code for this specific calendar provider.
- Booking the dentist needs a second capability the household's assistant doesn't have built in — so the host hands the task to a separate booking agent over A2A, presenting a signed Agent Card to establish who it is.
- The booking agent checks the shared free-slot information, confirms a time, and returns a result back across the A2A connection.
- Illustrative only: if this household ran three separate assistants for chat, scheduling and homework help, each wired by hand to the same calendar tool, a single calendar API change could mean three separate fixes instead of one — the arithmetic here is illustrative, not a measured figure from the dossier.
- What neither protocol checked, at any step: whether the booking agent's idea of "confirmed" matches the dentist's actual booking system. That judgement sits with whoever built and tested the agent, not with the wiring standard.
Should you use it?
Reach for MCP when an AI application needs to call many external tools or data sources and a bespoke integration per tool is no longer sustainable, or when the same integration should work from more than one host application. Reach for A2A when agents built on different vendor stacks genuinely need to discover each other and hand off work, not when a single team controls both ends already.
Skip both when the "tool" in question is really just one stable, well-understood API call your team already owns end to end — adopting a protocol adds revision churn (five MCP revisions already) for no real portability benefit. And neither protocol substitutes for evaluating a model's actual planning or reasoning ability; a standard interface does not make a model better at deciding when to use a tool.
The cheapest first experiment: stand up one MCP server for a single internal tool your team already maintains, and connect it from two different AI hosts you already use. If the second connection takes meaningfully less effort than the first integration did, the standard is pulling its weight.
Say it in the room
"Use MCP and A2A when you're tired of writing the same integration twice for different vendors; don't expect either one to tell you whether the tool on the other end is actually right for the job."
Lines to carry
- "A schema describes shape, never meaning."
- "Standard wiring doesn't standardise judgement."
- "Infrastructure is what rivals build independently."
- "The form gets you understood, not trusted to be right."
- "MCP is app-to-tool; A2A is agent-to-agent — adjacent, not the same."
- "Adoption numbers measure reach, not correctness."
FAQ
Is MCP the same as an API standard like REST or OpenAPI?
Not quite. Traditional API specifications describe a fixed service's endpoints for a known client written in advance. MCP is built for tools and data sources a model discovers and interprets at runtime, inside a conversation, rather than integrations wired in ahead of time by a developer who already knows exactly what's on the other end.
Does A2A replace frameworks like LangChain?
No. Microsoft's own description of A2A frames it as letting multi-agent applications exchange goals, state and results across vendor lines while developers keep using familiar frameworks underneath — it's the cross-vendor handshake layer, not a replacement for how any one team builds its agents.
Why would Anthropic, OpenAI and Google cooperate on this when they compete so hard elsewhere?
Because a shared interface only counts as real infrastructure if rivals implement it independently — one vendor controlling the wiring would make every other vendor reluctant to build on it. Handing both MCP and A2A to a neutral foundation removes that objection while leaving the actual competition on models, products and pricing untouched.
How mature is any of this, really?
Mixed. MCP has been through five dated revisions since launching in November 2024 and has serious adoption numbers behind it as of December 2025. A2A only reached version 1.0 in April 2026, which makes it meaningfully younger and less proven in production use than MCP, even though it already has cloud-platform general availability.
If two tools both use MCP, will they behave the same way?
Not necessarily. The protocol standardises the message format and the roles — host, client, server — and the three primitives of tool, resource and prompt. None of that touches what a given tool actually does when called, or whether its free-form description matches its real behaviour. That has to be checked separately, every time.
Glossary
- Model Context Protocol (MCP) — a standard, JSON-RPC-based way for an AI application to connect to external tools, data and prompt templates.
- Agent2Agent (A2A) — a standard protocol letting AI agents built by different vendors discover each other and exchange goals, state and results.
- JSON-RPC — a simple, lightweight message format used to make remote procedure calls encoded in JSON.
- Host, client, server (in MCP) — the host is the AI application; it runs clients that connect to servers, which expose tools, resources and prompts.
- Language Server Protocol (LSP) — an earlier standard letting any code editor talk to any programming-language tool through one shared interface, the model MCP is inspired by.
- Agentic AI Foundation — a Linux Foundation directed fund, co-founded by Anthropic, Block and OpenAI, that now governs protocols like MCP and A2A on a vendor-neutral basis.
- Agent Card — a signed document in A2A that verifiably identifies an agent, like a digital ID card.
- Schema — a formal description of the shape and types of data a tool or message expects, without describing its meaning or correct use.
- OpenTelemetry — an open standard for collecting traces and metrics from software systems, now being extended with conventions specific to generative AI.
- AGENTS.md — a file convention from OpenAI that gives coding agents repository-specific instructions.
- NLIP (ECMA-430) — the Natural Language Interaction Protocol, a lightweight message envelope for AI-agent interaction standardised by Ecma International.
- Directed fund — a governance structure within a foundation where founding members steer a specific project while it remains under neutral stewardship.
The three assistants wired by hand to the same calendar, database and search tool were never really missing wires — they were missing a shared socket. MCP and A2A supply that socket, cross-vendor and neutrally governed, with adoption numbers and cloud-platform availability to show the agreement is real rather than aspirational. But plugging something into a standard socket still doesn't tell the house whether it's the right appliance for the job. That judgement never moved off the model's plate, and no revision of either spec is going to put it there.
Sources
- The Interfaces Are Arriving — O'Reilly Radar, 2026
- Empowering multi-agent apps with the open Agent2Agent (A2A) protocol — Microsoft, 2025
- The Natural Language Interaction Protocol and Standard for AI Agents — arXiv, 2026