DM Explains · No. 027 · Architecture
Protocol federation: how AI agents will talk to tools and each other
MCP lets an agent use a tool. A2A lets one agent ask another for help. Neither yet lets a downstream agent prove who sent it.
· 15 min read
Read me first
Model Context Protocol lets an agent use a tool. Agent2Agent lets one agent ask another agent for help. Both genuinely cut the custom glue code teams used to write for every pairing, but neither one yet lets the agent receiving a delegated task prove who sent it.
A support agent looks up an invoice via MCP (f1,f2) then hands off to a refunds agent via A2A (f3,f4) through a shared discovery layer (f6) — but 0 of 8 surveyed protocols offer a verifiable delegation credential (f9), so the refunds agent cannot prove who sent the task.
A team wires up an agent from one vendor to a tool server built by another, writes bespoke code to make the two understand each other, ships it, and then a second agent needs the same tool. So they write the glue again. And again for the next pairing, and the one after that. Multiply this by every agent and every tool an organisation runs, and the maintenance burden stops being an engineering nuisance and becomes a security question nobody can answer cleanly: when an agent from one vendor hands a task to an agent from another, who, exactly, authorised that handoff?
Everyday picture. Dadi keeps a directory by the front door listing every room in the house and what you can ask of it, so any visitor can read it and request help without being told in advance. When Papa needs something his own household can't do, he phones a neighbour's house and asks for their expert, using a calling convention both houses have agreed on in advance.
Where the picture breaks. Papa knows and trusts the neighbour on the other end of the phone. Today's agent protocols have no equivalent: the neighbour's expert has no standard way to prove who authorised the call before acting on it.
Why it exists now
Anthropic launched Model Context Protocol in late 2024 as a universal way to standardise how an AI application discovers and calls external tools. Before that, every connection between an agent and a tool, or between two agents, was hand-built: a specific tool's shape baked directly into a specific application's code. That does not scale once an organisation runs agents from several vendors and frameworks that all need to reach the same handful of tools, and it scales even worse once those agents also need to talk to each other.
Since MCP's launch, Google introduced Agent2Agent (A2A) for agent-to-agent delegation, Cisco released a framework called Agntcy, and the Internet Engineering Task Force (IETF) began drafting a document surveying MCP, A2A and Agntcy "to set the stage for possible standards activity" (IETF — IETF). Through 2025 and 2026, MCP's governance moved to the Linux Foundation, which GitHub's engineering blog describes as a signal that the protocol "has reached the maturity threshold of a true industry standard" (GitHub Blog — The GitHub Blog, 2026). Meanwhile a recent survey counts more than a dozen competing or overlapping protocols trying to solve adjacent slices of the same problem (HAL — HAL, 2026).
How it works
The old way
One key cut specially for every single door
What it is. Before any shared protocol, every link between an agent and a tool, or between two agents, needed its own bespoke integration code.
Why it exists. Each tool exposes a different shape of function, parameters and return values; each agent framework expects a different calling convention. Without a shared standard, someone has to write the translation by hand.
Where it breaks. This does not scale once an organisation runs agents from multiple vendors and frameworks that all need the same tools: the number of custom integrations grows roughly with the number of pairings, not the number of parts.
How that's handled. This is exactly the gap MCP and A2A were built to close.
In technical terms
In technical terms: function calling in this era hardcoded a specific tool's schema directly into a specific model or application, with no dynamic discovery and no reuse across agents.
MCP: tool binding
A directory by the door, read at runtime
What it is. MCP lets an agent list the tools available to it, retrieve their schemas, and call them through a standard interface, all at runtime rather than at build time.
Why it exists. Decoupling a tool's implementation from its usage means any MCP-compliant agent can connect to any MCP-compliant tool server without a custom adapter built in advance (ACM — ACM Transactions on Software Engineering and Methodology). This has already produced thousands of independently built MCP servers exposing services such as GitHub, Slack and Blender, with applications such as Cursor and Claude Desktop connecting to new servers on demand.
Where it breaks. MCP standardises agent-to-tool calls only. It says nothing about how one agent should ask a different agent for help.
How that's handled. That gap is what A2A addresses, a separate layer entirely.
In technical terms
In technical terms: a client lists available tools, retrieves their schemas, and invokes them through a standard interface; this dynamic discovery and schema negotiation is independent of any one model or framework, and the architecture draws on the Language Server Protocol rather than conventional function calling (ACM — ACM Transactions on Software Engineering and Methodology).
Bi-directional channels
The room can also knock back
What it is. MCP supports tools sending events back to the calling agent, not just answering a single request, plus access control and capability negotiation as built-in features rather than afterthoughts.
Why it exists. Simple function calling is one request, one response. Bi-directional communication gives a more auditable foundation: a tool can notify the agent of a change without being polled first.
Where it breaks. Bi-directionality adds surface area to secure. A recent survey of MCP's landscape describes an open set of security threats rather than a solved problem (ACM — ACM Transactions on Software Engineering and Methodology).
How that's handled. Treat MCP's richer channel as something to monitor, not something to assume is safe by default.
In technical terms
In technical terms: MCP defines bi-directional communication and capability negotiation as first-class parts of the protocol, extending beyond one-shot calling.
A2A: agent handoff
Calling the neighbour's expert, not the plumber
What it is. A2A is Google's standard for one agent delegating a task to a different, independently built agent, regardless of which vendor or framework built either one.
Why it exists. A user-facing agent often lacks a skill it needs; A2A gives it a common way to find and message another agent that has it (A2A Protocol — A2A Protocol).
Where it breaks. A2A is frequently pitched as MCP's rival in coverage of the space, but it solves a different problem. Without MCP, an A2A-connected agent still has no standard way to reach tools; it can only reach other agents.
How that's handled. Use the two together, which is also how the people building them describe the relationship.
In technical terms
In technical terms: the A2A Protocol project describes MCP as handling agent-to-tool communication and A2A as handling agent-to-agent communication, positioning the two as complementary layers rather than competitors (A2A Protocol — A2A Protocol).
Layering the two
Tools below, colleagues beside
What it is. An enterprise agent can use MCP to call its own tools and A2A to delegate subtasks to sibling agents built elsewhere.
Why it exists. MCP is driven by Anthropic, A2A by Google, and Agntcy by Cisco — three separately governed projects aimed at different layers of the same stack. Stacking tool-binding and peer-messaging gives a fuller interoperability picture than either alone.
Where it breaks. Stacking two protocols still leaves a gap: neither specifies how the agent receiving a delegated request verifies who authorised it.
How that's handled. That gap carries through to the final step below; nothing in the current stack closes it yet.
In technical terms
In technical terms: a proposed Three-Layer Agentic Stack maps MCP, A2A, ACP and ANP to distinct architectural roles and estimates that a unified approach across them reduces integration complexity by an estimated 60 to 70 per cent compared with ad-hoc solutions, though this figure is the paper's own estimate rather than a measured industry average (Zenodo — Zenodo, 2026).
Discovery layers
A switchboard for houses that don't share a directory
What it is. Because no single protocol has won outright, translation and discovery layers such as the NANDA Index connect agents across MCP, A2A and other stacks.
Why it exists. Such a layer lets agents built on different protocols register and find each other, with adapters translating between them, so nobody has to implement every protocol in existence just to be reachable (arXiv — arXiv).
Where it breaks. A translation layer is an extra dependency and an extra trust point. It discovers and bridges agents; it does not resolve the authorisation gap underneath.
How that's handled. Treat discovery and authorisation as two separate problems, because today only the first one has working answers.
In technical terms
In technical terms: the NANDA Index operates as a global discoverability layer where agents across MCP, A2A, Microsoft's NLWeb and standard HTTPS can register and discover each other across existing protocol registries (arXiv — arXiv).
The authorisation gap
Nobody can prove who sent the agent
What it is. A rubric-based survey scored eight tool-binding and peer-messaging protocols against ten axes, and found the authorisation axis empty at its top level across all eight.
Why it exists. Discovery and messaging were solved first because they are the easier problem: find the other agent, speak a common format. Proving that a request carries legitimate authority from a human or another agent requires a verifiable credential, and none of the surveyed protocols defines one yet.
Where it breaks. This is the open problem across the whole field, not a flaw particular to MCP or A2A. Treat any production delegation chain today as unverified until this is addressed.
How that's handled. Build human review or scoped, time-limited credentials around the gap at the application level, since the protocol layer does not yet cover it.
In technical terms
In technical terms: the survey counted thirteen inter-agent protocols overall, including Google A2A, Anthropic MCP, IBM ACP, Cisco AGNTCY/SLIM, ANP, Coral, LOKA, ACNBP, AP2, Visa Trusted Agent Protocol, ERC-8004 and UCP, and scored eight of them against ten axes; none scored at the top authorisation level (HAL — HAL, 2026).
Compared with what came before
| Old way | Protocol federation | |
|---|---|---|
| Integration effort | Bespoke code per agent-tool or agent-agent pair | Shared protocol, written once per side |
| Tool discovery | Hardcoded in advance | Listed and queried at runtime (MCP) |
| Agent delegation | Custom API per vendor pair | Common messaging standard (A2A) |
| Cross-protocol reach | Not applicable | Discovery layers such as the NANDA Index bridge stacks |
| Proof of who authorised a handoff | Whatever the custom code happened to check | No standard credential in any surveyed protocol |
The judgement is unglamorous: protocol federation genuinely removes the pairwise glue-code burden, and a proposed unified framework estimates that effect at a 60 to 70 per cent reduction in integration complexity, by the framework's own estimate rather than a measured industry figure (Zenodo — Zenodo, 2026). What it has not yet removed is the question that matters most once agents start acting on each other's behalf: proof of authority.
Illustrative: a support agent needs an invoice and a refund → 1 discovery finds a billing tool and a refunds agent in the registry → 2 MCP call fetches the invoice (agent-to-tool) → 3 capability match confirms no local refund skill → 4 A2A delegates the case to the refunds agent (agent-to-agent) → 5 trust check asks for a delegation credential — f9: 0 of 8 surveyed protocols standardise one → refund processed once verified
Inside a single request, the two layers behave differently enough that confusing them is the most common mistake. The billing lookup is an agent-to-tool call: the support agent lists what the billing server offers, retrieves its schema, and invokes it, all under MCP. The refunds handoff is an agent-to-agent delegation: the support agent is not calling a tool, it is asking a separate, independently built refunds agent to take over part of the task, under A2A. One is a directory lookup followed by a function call. The other is a message to a peer that has to decide, with no standard credential available, whether to trust it.
Where it breaks
If an agent needs to reach a tool and nothing more, A2A's extra machinery is unnecessary weight; MCP alone covers it. If a task genuinely requires handing work to a different agent, A2A is the right layer, but only once the organisation has decided how it will handle the fact that neither protocol verifies who authorised the handoff.
No standardised delegation credential
A rubric-based survey of eight scored inter-agent protocols found none offers a verifiable delegation credential at the top authorisation level. A receiving agent today has no protocol-level way to confirm who, or what, authorised the request in front of it (HAL — HAL, 2026). Anything built on A2A or similar peer-messaging today needs its own authorisation controls bolted on at the application layer.
MCP's own bi-directional channels widen the attack surface rather than narrowing it: a tool that can send unsolicited events to an agent is a tool that can be misused to send unsolicited events, and the ACM survey of the MCP landscape frames this as a set of open security threats rather than something settled (ACM — ACM Transactions on Software Engineering and Methodology). The proliferation of competing protocols is itself a cost: more than a dozen specifications now exist, each with contributing authors from Microsoft, Google, Hugging Face and others, and reconciling which one a given tool or agent actually speaks is its own integration tax (The Stack — The Stack).
Numbers to carry
| Fact | Figure |
|---|---|
| MCP governance moves to Linux Foundation | 2026, described as reaching "the maturity threshold of a true industry standard" |
| Protocols counted in one 2026 survey | 13, spanning A2A, MCP, ACP, Agntcy/SLIM, ANP, Coral, LOKA, ACNBP, AP2, Visa Trusted Agent Protocol, ERC-8004, UCP |
| Protocols scored against ten axes, authorisation gap | 8 scored, 0 reach the top authorisation level |
| Estimated reduction in integration complexity from unifying MCP, A2A, ACP, ANP | 60 to 70 per cent, by one framework's own estimate, not an independently measured figure |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| MCP and A2A are rivals, pick one | The A2A project itself describes them as complementary: MCP for agent-to-tool, A2A for agent-to-agent |
| A shared protocol means the receiving agent can trust the request | No protocol scored in the 2026 rubric-based survey offers a verifiable delegation credential at the top authorisation level |
| Function calling and MCP are the same thing | Function calling hardcodes a tool's schema into one application; MCP standardises discovery and invocation independent of any single model or framework |
| Once agents share a protocol, security is solved | The ACM survey of MCP describes an open landscape of security threats, not a closed problem |
Worked example
- Meera (standing in for the support agent) receives a customer request: "where's my refund". The agent needs an invoice number before it can act.
- The agent, via MCP, lists the tools it has access to, finds a billing lookup tool, retrieves its schema, and calls it with the customer's account ID to fetch the invoice.
- The billing tool returns the invoice and, because MCP supports bi-directional events, could notify the agent later if the invoice status changes mid-conversation.
- The agent decides (illustrative: in a real deployment this would be governed by whatever policy the organisation set, not a thought the system has) that processing the actual refund is outside what it is built to do, and that a separate refunds agent, built by a different team, handles that.
- The agent, via A2A, sends a delegation message to the refunds agent describing the task and attaching the invoice details.
- The refunds agent receives the message and, under today's protocols, has no standardised way to verify that this delegation genuinely carries the authority it claims to; it proceeds on the strength of the message alone, which is exactly the gap the HAL survey flags.
- The refunds agent processes the return and reports completion back, closing the loop that started with Meera's original request.
Should you use it?
Reach for MCP when an agent needs to call tools that already exist as MCP servers, or when a team wants one agent to work with many tools without writing a new adapter for each. Reach for A2A when a task genuinely needs to move from one independently built agent to another, not merely from one function call to another. Skip both when a single team controls both ends of an integration and a direct API call is simply less to maintain than adopting a formal protocol. Treat any production system where an agent acts on another agent's say-so as carrying an open authorisation risk, because no protocol surveyed in 2026 closes it. The cheapest first experiment is connecting one existing agent to one MCP tool server internally and watching what breaks, before attempting any cross-vendor agent delegation at all.
Say it in the room
"Use MCP when an agent needs tools; use A2A when an agent needs another agent; and before trusting any handoff between them, know that nothing today proves who sent it."
Lines to carry
- "A key cut for every door does not scale once there are many houses."
- "A directory you can read at runtime beats a key you had to be given in advance."
- "Calling a neighbour's expert is not the same as knowing who sent them."
- "Tools below, colleagues beside: MCP and A2A stack, they don't compete."
- "Discovery is solved before authorisation is."
FAQ
Is A2A going to replace MCP?
No. The people building A2A describe it as handling a different problem: MCP connects an agent to tools, A2A connects one agent to another. Coverage that frames them as rivals is describing a race that the protocols themselves were not designed to run.
Can I use MCP without A2A?
Yes, and most deployments today do. If an agent only ever needs to call tools and never needs to hand work to a different agent, MCP alone is enough.
What happens if two organisations use different protocols entirely?
Discovery layers such as the NANDA Index exist precisely for this: they let agents built on MCP, A2A, Microsoft's NLWeb or plain HTTPS register and find each other, with translation happening in the middle. It adds a dependency, but it avoids every agent having to implement every protocol.
Does a shared protocol mean I can trust a delegated request?
Not yet. A 2026 rubric-based survey scoring eight protocols against ten axes found none reaches the top authorisation level, meaning there is no standard way for a receiving agent to verify who authorised the task in front of it. Build that check yourself, outside the protocol, for now.
Is this actually standardised, or still shifting?
Both, depending on the layer. MCP's governance has moved to the Linux Foundation, which is a real signal of maturity for the tool-binding layer. The agent-to-agent and authorisation layers are still being actively surveyed and drafted, including by the IETF, so treat that part as unsettled.
Glossary
- MCP (Model Context Protocol) — an open protocol, launched by Anthropic, that standardises how an AI agent discovers and calls external tools and data sources.
- A2A (Agent2Agent Protocol) — an open protocol, driven by Google, that standardises how independent AI agents communicate and delegate tasks to each other.
- Protocol federation — connecting independently built agents and tools using shared, open protocols instead of one-off custom integrations.
- Agntcy — an open framework for agent interoperability driven by Cisco.
- ACP (Agent Communication Protocol) — a protocol associated with IBM, addressing a related but distinct niche such as performative messaging.
- ANP (Agent Network Protocol) — a protocol focused on peer discovery and formal interfaces for agent networks.
- JSON-RPC — a lightweight remote procedure call format encoded in JSON, used by several agent protocols.
- Schema negotiation — a client and a tool agreeing at runtime on the structure of data they will exchange, without it being hardcoded in advance.
- Delegation credential — a verifiable token or proof that one agent has been authorised to act on behalf of another; currently missing from surveyed protocols.
- NANDA Index — a discoverability layer letting agents built on different protocols register and find each other.
- Three-Layer Agentic Stack (TLAS) — a proposed framework mapping MCP, A2A, ACP and ANP to distinct architectural roles.
- Agent federation — one AI agent handing off or delegating part of a task to another agent with different skills.
- IETF — the Internet Engineering Task Force, a standards body that develops Internet protocols.
- Linux Foundation governance — a neutral, non-profit structure under which open-source projects, including MCP, can be jointly maintained by multiple companies.
Sources
- Framework, Use Cases and Requirements for AI Agent Protocols — IETF
- Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions — ACM Transactions on Software Engineering and Methodology
- A2A Protocol — A2A Protocol
- A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, and ANP — arXiv
- MCP joins the Linux Foundation — The GitHub Blog, 2026
- Toward a Unified Interoperability Framework for Autonomous AI Agent Ecosystems — Zenodo, 2026
- A Rubric-Based Survey of Inter-Agent Protocols — HAL, 2026
- NANDA Index and cross-protocol agent interoperability paper — arXiv
- The protocol proliferation problem: Making sense of the open agent stack — The Stack