If you've been building multi-agent systems recently you've probably had to pick between these three protocols and found that the docs are either too vague or assume you already know what problem they're solving. Here's a plain-language breakdown.
MCP (Model Context Protocol) — Anthropic, 2024
MCP is vertical. It connects a model to tools: filesystem, databases, APIs, browser control. Think of it as the interface layer between an LLM and the things it can call. It works over stdio locally or HTTP+SSE remotely.
What it's good for: giving a single agent access to external resources in a standardized way. The tooling ecosystem is already decent.
What it doesn't do: connect one agent to another agent. MCP has no concept of agent-to-agent messaging, routing, or discovery. If you have two MCP-equipped agents and you want them to collaborate, MCP doesn't help you there.
Also: if your MCP server is behind a NAT or corporate firewall, remote clients can't reach it. The spec assumes HTTP reachability and most real machines don't have it.
A2A (Agent-to-Agent Protocol) — Google, 2025
A2A is horizontal. It defines how agents exchange tasks with each other: Agent Cards (capability advertisements at well-known URLs), task objects with lifecycle states, and JSON-RPC over HTTP for the wire format.
What it's good for: standardizing the semantics of agent collaboration. If you want agents from different vendors to hand off tasks without a custom integration, A2A is the right layer.
What it doesn't do: handle transport. A2A Agent Cards require a publicly reachable URL. If the agent is on a developer's laptop, behind AWS security groups, or inside a Docker network, it has no card. It doesn't exist to other agents. A2A also has no built-in encryption between agents and no persistent connection model. Each task round-trip is a new HTTP call.
ANP (Agent Network Protocol) — AgentNetworkProtocol, 2025
ANP is focused on identity and discovery. It uses DIDs (decentralized identifiers) to give agents verifiable identities and a meta-protocol for negotiating which application protocol to use. It's more of a coordination framework than a transport.
What it's good for: decentralized agent identity and cross-organization discovery without a central registry. Useful if you care about agents that can prove who they are across trust boundaries.
What it doesn't do: solve reachability. ANP runs over HTTPS, which means the same NAT problem applies. You can have a verified identity and still be unreachable.
The comparison table
| MCP | A2A | ANP | |
|---|---|---|---|
| What layer | App (tool access) | App (task exchange) | App (identity/discovery) |
| Direction | Vertical (model to tool) | Horizontal (agent to agent) | Horizontal (agent to agent) |
| Transport | stdio / HTTP | HTTP | HTTPS |
| NAT traversal | No | No | No |
| Encrypted tunnels | No | No | No |
| Persistent connections | No | No | No |
| Agent identity | Per-server config | Agent Cards (URL-based) | DIDs |
| Works behind firewall | Only with reverse proxy | Only with public URL | Only with public URL |
The gap in that table is the entire right half. Every one of these protocols assumes that both endpoints are publicly reachable over HTTP. In practice, 88% of networks involve NAT. The protocol handles what agents say to each other. Nobody has standardized how they reach each other.
What the missing layer looks like
The three protocols above all sit at L7, the application layer. What's missing is something at L5, the session layer: a peer-to-peer fabric for AI agents that handles virtual addressing, encrypted UDP tunnels, and NAT traversal, so that MCP and A2A can run on top of it without needing public IPs.
The closest analogy is what Tailscale did for humans. Tailscale didn't replace SSH or HTTP. It made those protocols work in places they couldn't before (behind NAT, across clouds, from mobile). An agent transport layer does the same thing for MCP and A2A: it makes them work where they currently can't.
Pilot Protocol is one project in this space. It's an open-source UDP overlay network with 48-bit virtual addresses, X25519+AES-256-GCM encrypted tunnels, and three-tier NAT traversal (STUN, hole-punching, relay fallback). It was submitted as an IETF Internet-Draft. MCP servers and A2A agents run on top of it unchanged. The architecture page has the full technical breakdown if you want to dig in.
There's also libp2p if you want something more established (used by IPFS, Ethereum), though it's heavier and not specifically designed for the agent use case.
So which one should you use?
All three, potentially, at different layers:
- MCP for tool access (your agent calling APIs, reading files, querying databases)
- A2A for task semantics (standardized handoff between agents from different systems)
- ANP if you need cross-org identity verification
- Something at the transport layer if any of your agents are behind NAT (which they probably are if they're running anywhere other than a public cloud VM with an open inbound rule)
The mistake I see most often is people reaching for A2A to solve a reachability problem. A2A isn't broken. You're just asking it to do something it was never designed to do.
Curious what stack people are actually running in production. Are you handling the NAT/reachability problem with a relay, a VPN, or just deploying everything to public cloud and accepting the operational overhead?
Top comments (0)