DM Explains · No. 034 · Models
Why AI tools can finally talk to each other without custom wiring
Two protocols — MCP for tools, A2A for agents — are turning bespoke integrations into shared plumbing, now handed to a neutral foundation.
· 13 min read
Read me first
Two protocols — MCP for tools, A2A for agents — genuinely do turn custom plumbing into shared plumbing, but only because rival companies agreed to hand control of them to nobody in particular.
A finance-agent booking a flight through a travel agent — it uses MCP to pull a traveller's spending limits from a budget tool, then uses A2A to hand the booking task to an independent travel-booking agent run by another company.
Meera wants to borrow Papa's toolbox for a loose hinge, Amma's sewing kit for a torn hem, and Dadi's recipe box for Sunday lunch. Every cupboard has its own odd handle, fitted by whoever built it, and nobody wrote down how any of them work. She has to learn each one separately before she can borrow anything, and if a cupboard gets a new lock, she has to relearn it.
AI systems have had exactly this problem. Every model that needed to call a tool, read a database, or hand work to another company's agent needed its own custom-built connector for that exact pairing. As the number of models and the number of tools both grew, the number of connectors grew faster than either — and each one broke independently when either side changed.
Everyday picture. Meera learns one standard door handle that opens Papa's toolbox, Amma's sewing kit and Dadi's recipe box without a separate lesson for each. Later she wants the neighbour's dog-walker to collect a parcel for her, so the two households agree a common note format and a signed ID card, so each side knows who is asking and what is being handed over.
Where the picture breaks. A shared handle and a signed note say nothing about whether the dog-walker can be trusted, whether they need paying, or what happens when a dozen different neighbourhoods each use a different kind of note. The protocols fix the shape of the interface; they do not settle who deserves access, or how disputes get resolved.
Why it exists now
The problem is old — wiring one system to another has always needed a connector — but AI made it acute. A single AI application might reasonably want to call a dozen tools, and companies now routinely build agents meant to call other companies' agents, not just their own tools. Writing a bespoke integration for every such pair does not scale: with N models and M tools or agents, that is up to N×M separate pieces of code, each maintained on its own.
What changed is that the two protocols addressing this — Anthropic's Model Context Protocol (MCP), launched November 2024, and Google's Agent2Agent (A2A) protocol — stopped being single-vendor projects. In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg (O'Reilly Radar, 2026). Google had already donated A2A to the same foundation family roughly six months earlier. A2A then reached version 1.0 in April 2026, with more than 150 supporting organisations and general availability inside Microsoft Copilot Studio, Azure AI Foundry and Amazon Bedrock AgentCore.
That is the unusual part: companies that compete hard on the underlying models are cooperating on the plumbing between them, because none of them wants to be the one left outside whichever standard wins.
How it works
The N×M problem
Every tool, every model, its own odd door handle
What it is. Before a shared protocol, connecting any AI model to any external tool meant writing a custom integration for that specific pairing.
Why it exists. Each tool exposes its own interface, each model expects its own calling convention, and nobody wrote a shared translator.
Where it breaks. With N models and M tools, that is up to N×M integrations, each maintained separately, each breaking independently when either side changes a detail.
How that's handled. The fix is architectural — a shared interface both sides agree to — not more careful custom code.
In technical terms
In technical terms: every additional model or tool multiplies integration work roughly linearly against the existing count on the other side, turning growth on either axis into compounding maintenance load.
MCP: agent to tool
One handle fits every tool in reach
What it is. The Model Context Protocol (MCP) lets an AI application call external tools, read data and use prompt templates through one standard interface, rather than a bespoke one per tool.
Why it exists. It replaces the custom-connector problem for the agent-to-tool boundary specifically — one application reaching into its own toolbox.
Where it breaks. MCP only covers an application reaching tools it has access to. It says nothing about one agent finding, or trusting, a completely separate agent run by another organisation.
How that's handled. That separate boundary — agent to agent — is what A2A was built for, which is the next moving part.
In technical terms
In technical terms: MCP defines three roles — the host (the AI application), the client (manages one connection) and the server (exposes tools, resources and prompts) — communicating over JSON-RPC messages, explicitly modelled on the Language Server Protocol, which let one editor feature work across many programming languages (O'Reilly Radar, 2026).
Illustrative: finance agent 1 calls budget tool via MCP JSON-RPC → 2 server exposes the limits resource → 3 returns a $1,200 cap → 4 discovers an independent travel-booking agent → 5 hands off the task with a signed Agent Card → 6 the other agent checks the cap and availability → books a $980 flight, result shared back
A2A: agent to agent
A signed note between two separate households
What it is. Agent2Agent (A2A) lets independent agents, built by different vendors, discover each other, verify identity and delegate tasks.
Why it exists. MCP solves the inside-one-application problem; once agents are run by different companies, something else has to let them find each other and prove who they are before handing over a task.
Where it breaks. A signed card proves identity, not trustworthiness in a dispute. Real cross-organisation delegation still needs payment, liability and security layers that A2A on its own does not define.
How that's handled. Enterprises pair A2A with their own trust, billing and audit layers on top; the protocol fixes discovery and task handoff, not the business relationship underneath.
In technical terms
In technical terms: each agent publishes a signed Agent Card proving identity and capability; by v1.0 in April 2026 this reached over 150 supporting organisations, SDKs in five languages, and general availability in Microsoft Copilot Studio, Azure AI Foundry and Amazon Bedrock AgentCore (A2A Protocol).
Neutral governance
One noticeboard, not each family's own
What it is. Rival companies donated their protocols to a shared, neutral foundation rather than keeping control of them.
Why it exists. A standard controlled by one vendor invites distrust from everyone else; a neutral home makes wide adoption more plausible.
Where it breaks. Neutral governance reduces the risk of single-vendor lock-in, but it does not force every company to adopt the standard, or stop anyone running a proprietary variant underneath it.
How that's handled. Adoption is tracked by who shows up — supporting organisations, SDK languages, and which cloud platforms ship general availability for it.
In technical terms
In technical terms: Anthropic gave MCP to the Agentic AI Foundation, a Linux Foundation directed fund, in December 2025, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg; Google had donated A2A to the same foundation family about six months earlier (O'Reilly Radar, 2026).
Specs keep moving
The handle is still being reshaped
What it is. Neither protocol is a finished standard. MCP alone has had five dated revisions since its November 2024 launch, the latest dated 28 July 2026.
Why it exists. Active revision lets new capabilities and fixes land as real usage surfaces problems the first draft missed.
Where it breaks. Treating the current spec as permanent is a mistake; code built against one revision may need rework against the next, and changes can be additive or breaking.
How that's handled. Implementers track the dated revisions rather than assuming the interface is stable forever.
In technical terms
In technical terms: MCP launched November 2024 and its current specification is dated 28 July 2026, the fifth dated protocol revision since launch (O'Reilly Radar, 2026).
A crowded street
Many noticeboards, not yet one
What it is. MCP and A2A are the leading protocols, but at least a dozen overlapping ones exist, and a separate dialog-context layer is being built to connect them rather than replace them.
Why it exists. Different protocols were built for different fragments of the multi-agent coordination problem — identity, payment, trust, messaging — and none yet covers the whole stack.
Where it breaks. No single standard yet covers everything, so builders still choose between competing or overlapping options depending on what each one is meant to solve.
How that's handled. A separate effort aims to let the different protocols carry a shared thread of context rather than forcing one to win outright.
In technical terms
In technical terms: a rubric-based survey counts protocols including IBM ACP, Cisco AGNTCY/SLIM, ANP, Coral, LOKA, ACNBP, AP2, Visa Trusted Agent Protocol and ERC-8004 (HAL); separately, Ecma International standardised the Natural Language Interaction Protocol (NLIP) as ECMA-430 in December 2025 (arXiv), and the Internet Engineering Task Force (IETF) chartered an "agentproto" working group to define dialog identifiers carried over MCP, A2A or other transports, not to replace them (IETF Datatracker).
Compared with what came before
| Bespoke integrations | Shared protocols (MCP, A2A) | |
|---|---|---|
| Who writes the connector | Each team, for each pairing | Once, against the shared spec |
| Scaling cost | Grows toward N×M as tools and models grow | Grows roughly with N+M |
| Identity across organisations | Ad hoc, often none | Signed Agent Cards (A2A) |
| Governance | Whoever built the connector | A neutral foundation (for MCP, A2A) |
| Stability | Stable until someone changes anything | Still actively revised |
The judgement is not that shared protocols are finished work — they are not — but that the direction of travel, from bespoke wiring toward a common interface with neutral governance, is the same direction every mature layer of computing has eventually taken.
Where it breaks
A shared protocol genuinely does cut the integration burden, but only for the boundary it was built for; MCP does not help two separate companies' agents find each other, and A2A does not help an application reach its own internal tools.
Identity is not trust
A2A's signed Agent Card proves who an agent claims to be and what it claims it can do. It says nothing about whether that agent will behave well with a delegated task, whether the delegating party will get paid correctly, or who is liable if something goes wrong. Those layers sit above the protocol, not inside it.
The specifications are also moving targets. MCP has had five dated revisions since November 2024, the latest dated 28 July 2026 (O'Reilly Radar, 2026); code written against an earlier revision is not guaranteed to work unchanged against a later one. And the landscape beneath MCP and A2A is still crowded rather than settled — a rubric-based survey counts at least a dozen overlapping inter-agent protocols, each addressing a different slice of the coordination problem, from payment (AP2, Visa Trusted Agent Protocol) to blockchain-based identity (ERC-8004) (HAL). Picking MCP and A2A today is a reasonable bet on the current leaders, not a guarantee the street will not add another noticeboard.
Numbers to carry
| Figure | Value |
|---|---|
| MCP launch | November 2024 |
| MCP donated to Agentic AI Foundation | December 2025 |
| A2A donated to the same foundation family | roughly six months before December 2025 |
| Current MCP specification date | 28 July 2026 (fifth dated revision since launch) |
| A2A version reached | v1.0, April 2026 |
| Organisations supporting A2A at v1.0 | over 150 |
| A2A SDK languages | five |
| Platforms with A2A general availability | Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore |
| NLIP standardised as | ECMA-430, December 2025 |
| Overlapping inter-agent protocols counted in one survey | at least a dozen |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "MCP and A2A are the same thing" | MCP standardises an application calling its own tools; A2A standardises independent agents discovering and delegating to each other. |
| "A signed Agent Card means the other agent can be trusted" | It proves claimed identity and capability, not good behaviour, payment or liability in a dispute. |
| "These are finished standards now" | MCP has had five dated revisions since November 2024, the latest dated 28 July 2026 — active, ongoing change. |
| "One protocol has already won" | A rubric-based survey counts at least a dozen overlapping protocols still in play, each covering a different fragment of the problem. |
| "Neutral governance means every company must comply" | Donating a protocol to a foundation like the Agentic AI Foundation reduces single-vendor control; it does not compel adoption. |
Worked example
- Meera's finance assistant (an AI application) needs to check her monthly spending limit before approving a flight booking. It uses MCP to call a budget tool exposed as an MCP server, reading the limit as a resource rather than through a custom connector built just for that tool.
- The same assistant decides the actual booking should go to a specialist travel-booking agent run by a different company, rather than attempting it itself.
- Using A2A, the finance assistant discovers the travel agent and checks its signed Agent Card to confirm identity and what it claims to be able to do.
- The finance assistant delegates the booking task over A2A, handing across the traveller's constraints (dates, budget ceiling) without either side needing a bespoke integration written for this specific pairing.
- The travel agent completes the booking and returns a result over the same A2A channel; illustratively, if this pairing had instead needed a custom-built connector, and the finance assistant already talks to, say, twenty other tools and agents, a single new one added without a shared protocol would mean rewriting logic for that one new relationship rather than reusing the same handle already in place.
Should you use it?
Reach for MCP when an AI application you control needs to call several tools or data sources and you want one integration pattern instead of one per tool. Reach for A2A when the task genuinely crosses an organisational boundary — your agent needs to hand work to an agent you do not control and cannot inspect. Skip both when there is only one tool, run by one team, and a direct call is simpler than standing up a protocol layer for its own sake. The cheapest first experiment is usually wiring one internal tool through an MCP server before touching cross-organisation delegation at all.
Say it in the room
"Use MCP when one application needs to reach many tools without a connector per tool; use A2A only once a task genuinely crosses into another company's agent — and neither protocol decides whether that other agent deserves the task."
Lines to carry
- "One handle fits every tool in reach."
- "A signed note between two separate households."
- "One noticeboard, not each family's own."
- "The handle is still being reshaped."
- "Many noticeboards, not yet one."
- "Identity is not trust."
FAQ
Is MCP only an Anthropic thing?
It started there, launching in November 2024, but it was donated to the neutral Agentic AI Foundation in December 2025, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. It is no longer controlled by one company.
Do I need A2A if I only use one AI vendor's tools?
Probably not yet. A2A earns its keep once your agents need to delegate tasks to agents run by a different organisation. Inside one vendor's ecosystem, MCP alone usually covers the need.
Does a signed Agent Card mean I can trust the other agent completely?
No. It proves the agent is who it claims to be and states what it claims to do. It says nothing about reliability, cost, or what happens if the task goes wrong — those need separate agreements.
Will MCP or A2A stay the same next year?
Unlikely. MCP has had five dated revisions since its 2024 launch, most recently dated 28 July 2026. Build with the expectation that the spec will keep moving.
Are there other protocols I should worry about?
Possibly, depending on what you need. A survey counts at least a dozen overlapping protocols, including ones focused on payment and blockchain-based identity. MCP and A2A cover the two boundaries most builders hit first, but they are not the whole landscape.
Glossary
- MCP (Model Context Protocol) — a standard defining how an AI application connects to external tools, data sources and prompt templates.
- A2A (Agent2Agent protocol) — a standard letting independent AI agents from different vendors discover each other, delegate tasks and exchange results.
- Agent Card — a signed document in A2A that lets an agent verify another agent's identity and capabilities.
- JSON-RPC — a lightweight protocol for sending remote procedure calls encoded as JSON messages, used by MCP.
- Agentic AI Foundation — a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI, that now governs MCP and related protocols.
- NLIP (Natural Language Interaction Protocol) — an Ecma International-standardised lightweight message envelope for AI-agent interaction, carried over transports such as HTTP or WebSocket.
- ECMA-430 — the formal Ecma International standard number assigned to NLIP in December 2025.
- agentproto (IETF working group) — an IETF group defining dialog identifiers and context propagation so different agent protocols can maintain continuity across intermediaries and trust boundaries.
- N×M integration problem — the scaling problem where N models each need custom connectors to M different data sources or tools, which standard protocols aim to reduce.
- Host, client, server (MCP roles) — in MCP, the host is the AI application, the client manages a connection, and the server exposes tools, resources or prompts.
- Dialog context — state information that lets a conversation or task be correlated and continued across devices, networks or interruptions.
- Language Server Protocol (LSP) — an earlier standard that let one interface work across many code editors and programming languages, cited as an inspiration for MCP.
Sources
- A2A Protocol — A2A Protocol Project
- The Interfaces Are Arriving — O'Reilly Radar, 2026
- The Natural Language Interaction Protocol and Standard for AI Agents — arXiv
- A Rubric-Based Survey of Inter-Agent Protocols: Industry Standards, Security Posture, Open Problems, and Three Co-Designed Protocol Extensions — HAL
- Agent Communication Protocols (agentproto) Working Group Charter — IETF Datatracker