MCP vs A2A vs ACP: Agent Tool and Agent Protocols
Three patterns keep showing up in agent architecture slides: MCP (agent → tools), A2A (agent → agent via a registry of agent cards), and ACP (agent → agent over REST with a metadata manifest). They solve different connection problems — do not treat them as rivals for the same job.
This guide maps each flow, when to use it, and how they compose. MCP deep-dives live in [Nine AI Concepts for 2026](/blog/nine-ai-concepts-2026); multi-agent anatomy in [What Is Agentic AI?](/blog/what-is-agentic-ai).
Running example: a support agent that needs Postgres + GitHub (MCP), then delegates a specialist research agent (A2A or ACP) before answering.
MCP: agent → tools
Model Context Protocol (MCP) connects an agent host to external tools and data. Flow: User request → MCP Host (chat UI, IDE like Cursor, or custom app) → MCP Client packages the need → MCP Server bridges to resources → tools (Postgres, GitHub APIs, Google Drive files) → structured response back up the chain.
MCP is not agent-to-agent messaging. It standardizes how one runtime discovers and calls capabilities — databases, APIs, files — without a custom plugin per model.
When to use: give one agent hands on your systems. When not to: peer delegation between two autonomous agents — that is A2A/ACP territory.
Quick reference
- Host examples: Claude desktop, Cursor/VS Code, custom AI apps.
- Client routes; server exposes tools/resources with auth scopes.
- Typical tools: DB, GitHub, Drive — structured results, not free-form HTML.
- Keep REST for human clients; add MCP for agent-driven discovery.
- Auth still matters — MCP is not a free pass to production data.
Remember this
I can trace MCP Host → Client → Server → tools → structured response.
A2A: agent → agent via registry
A2A (agent-to-agent) is peer discovery and delegation. Agent A gets the user request, queries a registry of Agent Cards (capability descriptions), finds Agent B, delegates the task, and consumes results. A dashed path covers “more information needed” so B can ask A for clarification.
The registry is the phone book; cards advertise what each peer can do. This fits multi-agent systems where specialists appear and disappear.
When to use: dynamic specialist discovery across a fleet. When not to: a fixed two-agent handoff you already hard-wire — a registry may be overhead.
Quick reference
- Agent Card = capability metadata for a peer.
- Registry returns cards; A delegates to B.
- Results (and clarify loops) flow back to A.
- Complementary to MCP: B may still use MCP for its own tools.
- Industry experiments — design for versioned cards and auth between peers.
Remember this
I know A2A as registry + agent cards for peer discovery and task delegation.
ACP: agent → agent over REST
ACP frames agent-to-agent as REST/HTTP with a metadata manifest of available agents. Agent A reads the manifest, discovers Agent B, sends an HTTP request, and gets a sync or async response depending on the task.
If your org already operates APIs, gateways, and OpenAPI, ACP-style contracts feel familiar: agents are services with manifests instead of (or alongside) Agent Cards in a custom registry.
When to use: standardized HTTP between agent services in your mesh. When not to: IDE-local tool plugins — prefer MCP for host↔tool.
Quick reference
- Manifest lists capabilities (like a service catalog).
- Communication: REST/HTTP request/response.
- Sync for quick tasks; async when work is long-running.
- Fits API gateways, mTLS, and existing observability.
- Still need schemas for task payloads and errors.
Remember this
I can describe ACP as manifest discovery plus REST sync/async between agents.
How to choose — and combine them
Use the connection type as the filter: agent → tools → MCP. agent → agent with a capability registry/cards → A2A. agent → agent with HTTP + manifest and sync/async semantics → ACP.
Real systems compose: the host uses MCP for Postgres/GitHub; the orchestrator A2A-delegates a research peer; that peer might expose ACP endpoints to other services. Start with MCP for tool access; add A2A/ACP only when you truly need peer agents.
Quick reference
- MCP = tools/data plane for one agent runtime.
- A2A = peer discovery via registry + cards.
- ACP = peer calls via REST + manifest.
- Do not replace MCP with A2A for database access.
- Practice: draw your support bot — label each hop MCP, A2A, or ACP.
Remember this
I can pick MCP vs A2A vs ACP from tools vs peer-agent needs — and combine them.
MCP gives agents tools. A2A and ACP give agents peers — one via registry cards, one via REST manifests. Confusing the three produces either a mega-prompt with no real integrations or a mesh of agents that cannot touch a database.
Your homework: for one product flow, list every hop. Tag each MCP / A2A / ACP / plain REST. Delete any hop that does not earn its protocol. Then implement one MCP server before standing up a registry.
Related Articles
Explore this topic