Protocol Comparison

The protocols in this section answer different questions. MCP answers "how does one agent use a tool?" A2A answers "how does one agent delegate to another agent it does not control?" The remaining entrants — ACP, AGNTCY, and ANP — stake out positions around or between those two poles. This page lines them up against a common set of dimensions, all verified against each project's primary specification, and then explains how the pieces fit together.

A useful first cut is the layer each protocol targets. MCP is a vertical protocol: it connects an agent down to capabilities (see protocols-mcp.html). A2A, ACP, and ANP are horizontal: they connect an agent across to peer agents (see protocols-a2a.html and protocols-acp.html). AGNTCY is broader still — a full infrastructure stack rather than a single wire protocol.

flowchart TB
    subgraph Across["Horizontal — agent ↔ agent"]
        A2A[A2A]:::p
        ACP[ACP]:::p
        ANP[ANP]:::p
    end
    subgraph Stack["Infrastructure stack"]
        AGNTCY[AGNTCY: OASF + Directory + SLIM]:::s
    end
    AgentA["Agent"]:::a
    AgentB["Peer Agent"]:::a
    Tools["Tools / Data (servers)"]:::t
    AgentA <-->|A2A / ACP / ANP| AgentB
    AgentA -->|MCP — vertical| Tools
    AgentB -->|MCP — vertical| Tools
    classDef p fill:#e8f0fe,stroke:#4285f4;
    classDef s fill:#fef7e0,stroke:#f9ab00;
    classDef a fill:#e6f4ea,stroke:#34a853;
    classDef t fill:#fce8e6,stroke:#ea4335;

The comparison matrix

Every cell below is drawn from the named project's own specification or documentation. Where a project deliberately leaves something open (e.g. multiple transport bindings), the cell says so rather than inventing a single answer.

A few cells deserve a caveat. A2A is often described elsewhere as just "gRPC/REST," but its specification defines three equal-status transport bindings of the same method set — JSON-RPC 2.0, gRPC, and HTTP+JSON/REST — none designated as mandatory or primary. Agents SHOULD implement at least one and declare which they support via the AgentCard's preferredTransport/additionalInterfaces fields; JSON-RPC 2.0 is merely the default value of preferredTransport when it is omitted. And note that "ACP" is overloaded: here it means IBM/BeeAI's Agent Communication Protocol, not AGNTCY's separately-named Agent Connect Protocol — a genuine source of confusion in the ecosystem.

MCP + A2A: a complementary stack

The two most widely deployed protocols, MCP and A2A, are designed to compose rather than compete, because they operate at different layers of an agentic-system. MCP standardizes the connection from an agent down to its tools and data; A2A standardizes the connection from an agent across to a peer agent it does not control.

In a typical deployment a single agent plays both roles at once. It exposes an agent-card so peers can find and delegate to it over A2A, while internally it satisfies those requests by calling tools over MCP. The trust boundaries differ accordingly: MCP traffic stays within one agent's own control surface (often a local stdio-transport subprocess), whereas A2A deliberately crosses organizational boundaries to a remote party.

sequenceDiagram
    participant Client as Client Agent
    participant Server as Server Agent
    participant Tool as MCP Server (tool)
    Client->>Server: A2A — delegate task (message/send)
    Note over Server: To do the work, the server agent
uses its own tools…
    Server->>Tool: MCP — tools/call
    Tool-->>Server: tool result (content / isError)
    Server-->>Client: A2A — task result (artifacts)

A note on the wire format above: in MCP a tool is invoked with a JSON-RPC tools/call request, and the response carries its output in a content field (with an isError flag) — not in an Anthropic-style tool_use/tool_result content block. Those tool_use and tool_result block types belong to the model-facing tool-use layer of an LLM API (see tool use), which the agent translates into an MCP tools/call. The two live at different layers, and the diagram annotates each with its own vocabulary.

The mental model: A2A is how agents talk to each other; MCP is how each agent gets its work done. One delegation over A2A can fan out into many tool calls over MCP inside the agent that accepted it.

Where the protocols overlap

The horizontal protocols — A2A, ACP, and ANP — overlap in ambition (agent-to-agent interoperability) but diverge in philosophy:

• A2A vs. ACP. Both let independent agents exchange tasks over HTTP. A2A standardizes a richer object model (Task, Message, Part, Artifact) and a JSON-RPC method set; ACP bets on plain RESTful JSON usable from curl with no special client. This overlap was resolved organizationally rather than technically: under the Linux Foundation, ACP's effort is converging into A2A, with the ACP team winding down active development.
• ANP stakes out the most different position. Instead of assuming agents live behind known HTTP endpoints owned by an organization, it targets a decentralized web of agents identified by decentralized-identifiers (the did:wba method) and described in JSON-LD — closer in spirit to a peer-to-peer protocol for the "agentic web" than to an enterprise integration standard. Requests are authenticated by signing them with the keys the DID resolves to; the current default carries that signature in HTTP Message Signatures headers, with the original DIDWba-scheme Authorization header retained as a compatibility mode.
• AGNTCY is not really in the same category. Rather than a single wire protocol, it is a stack of components — the oasf schema for describing agents, an Agent Directory for discovery, the SLIM messaging layer, plus identity and observability. It can therefore sit alongside A2A and MCP (carrying or cataloguing them) rather than replacing either.

Discovery is the dimension where the overlap is sharpest, and the designs cluster into two camps: a well-known-uri convention (A2A's /.well-known/agent-card.json; ANP's web-hosted descriptions) versus a synced/registry model (AGNTCY's Agent Directory; ACP's registry plus offline manifests). MCP sits apart again — it has no network-wide discovery at all; a client is pointed at a server and then enumerates capabilities with tools/list.

When to use which

A practical decision guide, grounded in each protocol's stated purpose:

• Give one agent access to a tool, file, database, or API. Use MCP. This is its sole job, and it is the most mature option for it. See protocols-mcp.html.
• Let your agent delegate a task to another team's or vendor's agent. Use A2A. Its Task lifecycle, sse streaming, and push notifications are built for long-running cross-organizational work. See protocols-a2a.html.
• You want the simplest possible agent-to-agent HTTP surface today. ACP's RESTful design is the lightest to stand up — but weigh its convergence into A2A before committing for the long term. See protocols-acp.html.
• You need org-spanning discovery, identity, and observability across many agents and frameworks. Look at AGNTCY as connective infrastructure that wraps the others.
• You are building for an open, decentralized agent web with no central registry. ANP and its DID-based identity are the closest fit, accepting that it is the least mature.

For the overwhelmingly common case — an enterprise agent that uses tools and occasionally delegates to a partner agent — the answer is not "choose one." It is MCP for tools, A2A for peers, with the other three reserved for the specific niches above.