As AI systems grow beyond single agents, two protocols have emerged to solve two very different problems. MCP (Model Context Protocol) — created by Anthropic — defines how an agent connects to external tools and data. A2A (Agent2Agent Protocol) — created by Google and now stewarded by the Linux Foundation — defines how agents discover, negotiate with, and delegate work to other agents.
The protocols are not competitors. They sit at different layers of the agent stack. Understanding which one to reach for — and when to use both — is becoming a foundational skill for anyone building production AI systems in 2026.
MCP gives agents hands — access to tools, files, and APIs. A2A gives agents a voice — a standard way to talk to other autonomous agents. Most serious multi-agent systems will eventually need both.
What Is MCP (Model Context Protocol)?
MCP is an open standard released by Anthropic in November 2024. Its purpose is to eliminate the N×M integration problem: before MCP, connecting an AI agent to N different data sources required M custom integrations for each agent. MCP defines a universal client-server architecture where any MCP-compatible agent (Claude, Cursor, GitHub Copilot, Windsurf, and dozens more) can connect to any MCP server — once.
MCP has three primitives:
- Tools — callable functions the agent can invoke (e.g.,
search_database,send_email,run_query). These are the most commonly used primitive. - Resources — read-only data the agent can pull into context (e.g., a file, a Notion page, a database record).
- Prompts — reusable templates that guide the agent's behavior within a specific server context.
MCP operates over a client-server transport layer (stdio for local, HTTP/SSE for remote). The agent host is the MCP client; the tool integration is the MCP server. The relationship is vertical: one agent, many tools below it.
MCP has been adopted rapidly. As of early 2026, the TypeScript MCP SDK is pulling nearly 7 million npm downloads per week, and major platforms — Claude.ai, Cursor, Continue, Zed, and GitHub Copilot — all support MCP natively.
MCP is the USB-C standard for AI agent context — plug any agent into any tool with a single, consistent interface.
What Is A2A (Agent2Agent Protocol)?
A2A was released by Google in April 2025 and donated to the Linux Foundation in June 2025. It addresses the problem MCP was never designed to solve: what happens when one AI agent needs to delegate a task to another autonomous agent?
In MCP, tools are deterministic — they take an input, return an output, and have no internal state or autonomy. In real multi-agent systems, you often need to hand a task to another agent that has its own reasoning, memory, tools, and implementation — and you don't want to expose any of that internals. A2A treats remote agents as opaque peers, communicating only via a defined interface.
A2A is built around three concepts:
-
Agent Cards — A JSON metadata file served at
/.well-known/agent.json. This is the agent's public capability declaration: what it can do, what data formats it accepts, what authentication it requires. A client agent fetches an Agent Card to discover what a remote agent offers before sending any work. -
Tasks — The unit of work in A2A. A client agent sends a Task to a remote agent; the remote agent works on it and returns Artifacts (results). Tasks have a lifecycle:
submitted → working → completed(orfailed,cancelled). -
Messages and Parts — Communication within a task is structured as Messages containing Parts. Parts carry the actual content — text, files, or structured JSON data. This lets agents negotiate the right format for their exchange.
A2A supports three interaction modes:
- Synchronous — request/response (simple tasks with immediate results)
- Streaming (SSE) — real-time incremental updates as the remote agent works
- Push notifications — async webhook callbacks for long-running or disconnected tasks
The relationship is horizontal: agents coordinate as peers, regardless of which framework or vendor built them. A Google ADK agent can delegate to a LangGraph agent, which can hand off to a CrewAI agent — as long as all three speak A2A.
MCP vs. A2A: Side-by-Side Comparison
| Dimension | MCP | A2A |
|---|---|---|
| Created by | Anthropic (Nov 2024) | Google → Linux Foundation (Apr 2025) |
| Current version | Spec 2025-11-25 | v0.3 |
| Direction | Vertical (agent → tools) | Horizontal (agent ↔ agent) |
| What it connects | Agent to tools, data sources, APIs | Agent to other autonomous agents |
| Counterpart behavior | Deterministic (tool follows instructions) | Autonomous (agent reasons independently) |
| Discovery | Listed in MCP client config | Agent Card at /.well-known/agent.json |
| Unit of work | Tool call (request/response) | Task (lifecycle: submitted → working → done) |
| Internal implementation | Server code is visible to operator | Remote agent is opaque (black-box) |
| Interaction modes | Sync request/response, SSE | Sync, SSE streaming, push notifications |
| Data types | Text, JSON, files | Text, JSON, files, structured parts |
| Primary use case | Tool augmentation for one agent | Multi-agent delegation and orchestration |
| Framework support | Claude, Cursor, Copilot, Zed, Continue… | Google ADK, LangGraph, CrewAI, Semantic Kernel… |
How MCP and A2A Work Together
The clearest mental model: MCP defines what each agent can do. A2A defines how agents talk to each other.
Consider a customer support system:
- A Triage Agent receives an incoming ticket. It uses MCP to read the customer record from a CRM tool, check order history from an e-commerce API, and classify the issue.
- For a billing dispute, the Triage Agent sends a Task to a Billing Agent via A2A. The Billing Agent is built on a different framework and runs on a different team's infrastructure — the Triage Agent doesn't know or care about its internals.
- For a technical bug, the Triage Agent delegates via A2A to an Engineering Support Agent that has its own MCP connections to Jira, GitHub, and the error logging system.
Each agent's internal tool access is managed with MCP. Cross-agent coordination is managed with A2A. The two protocols handle completely separate concerns.
A common mistake is trying to use MCP to connect to another agent (treating the agent like a tool). This can work in simple cases but breaks down as soon as the "tool" needs to run long, async tasks, stream intermediate results, or negotiate its own context. That's what A2A was built for.
When to Use MCP
Reach for MCP when your agent needs to:
- Read or write data from external systems — databases, file systems, email, calendars, project management tools
- Call deterministic functions — run a SQL query, fetch a webpage, invoke an API endpoint
- Inject context into the LLM — pull in a document, a codebase, or a knowledge base at inference time
- Build a local tool integration — connect Claude Desktop or Cursor to your internal tools
MCP is the right choice when you control both sides of the integration and the "other side" is a tool, not an agent with its own reasoning. If you haven't built an MCP server yet, our step-by-step MCP server tutorial will get you running in under 30 minutes.
When to Use A2A
Reach for A2A when your system involves:
- Specialized agents that each handle one domain — billing, HR, engineering, customer success
- Cross-team or cross-organization agent collaboration — delegating work to an agent your team doesn't own or maintain
- Long-running tasks that need async updates — work that takes minutes or hours, with streaming progress
- Opaque agent integration — you want to use a remote agent's capability without coupling to its implementation
A2A is also the right protocol when you need agent discovery at runtime — your orchestrator doesn't know in advance which agents are available; it fetches Agent Cards to learn what's out there before routing a task.
A Note on ACP (Agent Communication Protocol)
A third protocol worth knowing: ACP (Agent Communication Protocol) from IBM and BeeAI, which targets intra-system agent coordination — agents within the same deployment or organization. Some teams summarize the stack as: MCP for tool access, ACP for internal coordination, A2A for cross-organizational collaboration. As of early 2026, ACP has less adoption than MCP or A2A, but the pattern is worth watching as enterprise multi-agent systems mature.
The Agent Protocol Stack (2026)
Here is how the three layers fit together:
| Layer | Protocol | Scope |
|---|---|---|
| Tool access | MCP | Agent ↔ tools, data, APIs |
| Internal coordination | ACP | Agents within same org/deployment |
| Cross-agent federation | A2A | Autonomous agents across teams, vendors |
The important insight is that none of these protocols replaces the others. Production agentic systems will use all three — or at least MCP and A2A — as the default foundation layer.
Getting Started
- MCP: Start with Anthropic's MCP TypeScript SDK or follow our MCP server tutorial.
- A2A: The official A2A specification and Google's ADK docs include working examples. Google Codelabs has a hands-on tutorial with a Purchasing Concierge and Remote Seller Agent interaction.
- Both: Most framework-level tools (LangGraph, CrewAI, Semantic Kernel) are adding native support for both protocols — check their latest docs for built-in MCP and A2A integrations.
Understanding the AI agent architecture that underpins these protocols will help you design systems that use MCP and A2A in the right places. If you are orchestrating multiple agents, the multi-agent collaboration patterns guide covers delegation, pipeline, and voting topologies in detail.
Get Started with cowork.ink
Building multi-agent workflows that span MCP integrations and A2A coordination is exactly what cowork.ink is designed for. Connect your agents to the tools and teammates they need — without glue code.