AI / LLM
MCP and A2A: Protocol Standards for LLM Agents
Two standards have emerged in the last year that address interoperability problems the agent community has been reinventing ad hoc for as long as agents have existed. Before them, connecting an LLM to a database meant writing a custom tool per database. Connecting one team's agent to another team's agent meant negotiating a proprietary API. Both problems are now addressed by published protocols with growing adoption.
MCP (Model Context Protocol), introduced by Anthropic in late 2024, standardizes how LLMs access external data and tools (Anthropic, 2024). Any MCP-compatible client connects to any MCP-compatible server. A2A (Agent-to-Agent Protocol), introduced by Google in 2024, standardizes how agents discover and call each other (Google, 2024). It is built on HTTP plus JSON-RPC 2.0 plus Server-Sent Events and now operates under the Linux Foundation. This article covers what each protocol does, when to use which, and where they sit in Google's broader six-protocol stack for agent systems.
MCP: the tool side
MCP answers one question. How should a language model access a tool, a database, or a data source in a way that does not require custom glue per integration?
The answer is a client-server protocol. The agent (or the IDE, or any LLM-using application) is the client. The tool or data source is fronted by an MCP server. The client and the server speak a common protocol over stdio, HTTP, or Server-Sent Events. The server exposes tools, resources, and prompts; the client discovers them, calls them, and receives structured responses.
flowchart LR
A[Agent or client application] <-->|MCP over stdio/HTTP/SSE| S1[MCP server: database]
A <-->|MCP| S2[MCP server: GitHub]
A <-->|MCP| S3[MCP server: filesystem]
S1 <--> DB[(Database)]
S2 <--> GH[GitHub API]
S3 <--> FS[Local files]
The design benefit is combinatorial. N clients and M servers used to need N times M integrations; with MCP they need N plus M. Anthropic ships MCP servers for common systems (filesystem, GitHub, Postgres, Slack). Third parties have written servers for dozens more. Claude Desktop, Cursor, Zed, and several other clients consume any of them.
MCP was the first of the two standards to land, and it rapidly became the default for tool integration in Anthropic's ecosystem. Google's agent documentation explicitly recommends MCP for the data-access layer of agent systems.
A2A: the agent side
A2A answers a different question. How should two agents, potentially built on different frameworks and operated by different organizations, discover each other and exchange tasks?
The design is more involved than MCP because inter-agent communication has structure that tool access does not. A2A defines a task lifecycle (working, input-required, completed, failed, canceled), a security model (HTTPS mandatory, OAuth2/OpenID Connect for authentication), and an agent-card discovery mechanism published at a well-known URL.
flowchart LR
C[Calling agent] -->|GET /.well-known/agent-card.json| D[Discovery]
D --> CARD[Agent card: capabilities, auth, endpoints]
C -->|JSON-RPC task| S[Remote specialist agent]
S -->|SSE streaming updates| C
S -->|terminal state: completed/failed| C
An agent's agent card, served at /.well-known/agent-card.json, names what the agent can do, how to authenticate, and where to send tasks. A calling agent fetches the card, selects the right remote agent for its task, and sends a task over JSON-RPC 2.0. The remote agent streams progress updates via Server-Sent Events and terminates with a status.
The protocol reached v0.3 in 2025 with gRPC transport support, agent-card signing for authenticity verification, and over 150 supporting organizations. It is governed by the Linux Foundation under Apache 2.0.
MCP versus A2A
The two protocols are not competitors; they address different layers. The choice depends on what is on the other end of the connection.
| Question | Answer |
|---|---|
| You are connecting to a database, API, or file system | Use MCP |
| You are looking up agent tools, resources, or prompts | Use MCP |
| You are calling a remote specialist agent built by another team | Use A2A |
| You are building a multi-team agent system | Use A2A for agent-to-agent, MCP for data access |
| Raw data is not exposed, only capabilities | Use A2A |
| You need cross-organization agent communication | Use A2A |
A production agent system commonly uses both. The agent uses MCP to talk to its local tools and databases; it uses A2A to delegate subtasks to specialist agents that live elsewhere. The separation of concerns keeps each protocol focused on what it is good at.
Two versions in code
The excerpt below shows an MCP client using Anthropic's official SDK. The client connects to a server, lists the available tools, and invokes one.
from anthropic.mcp import ClientSession, StdioServerParameters, stdio_client
server_params = StdioServerParameters(
command="npx",
args=["-y", "@modelcontextprotocol/server-filesystem", "/workspace"],
)
async def main():
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
tools = await session.list_tools()
print([t.name for t in tools.tools])
result = await session.call_tool(
"read_file", {"path": "/workspace/README.md"})
print(result.content[0].text)The A2A excerpt below uses a thin HTTP client to discover an agent and dispatch a task. Production implementations use the official A2A SDK, which handles authentication, JSON-RPC framing, and SSE streaming.
import httpx
BASE = "https://specialist.example.com"
async def a2a_task(task_description: str) -> dict:
async with httpx.AsyncClient() as client:
card = (await client.get(f"{BASE}/.well-known/agent-card.json")).json()
auth = get_oauth_token(card["auth"]["token_url"])
task = await client.post(
card["endpoints"]["task"],
headers={"Authorization": f"Bearer {auth}"},
json={"jsonrpc": "2.0", "method": "tasks/create", "id": 1,
"params": {"input": task_description}})
task_id = task.json()["result"]["id"]
# In practice, subscribe to SSE for streaming updates.
# Here, simple poll until terminal status.
while True:
s = (await client.get(f"{card['endpoints']['task']}/{task_id}",
headers={"Authorization": f"Bearer {auth}"})).json()
if s["result"]["status"] in ("completed", "failed", "canceled"):
return s["result"]The LangGraph and LangChain ecosystems both have MCP and A2A integrations that handle the protocol details. Full runnable versions will live at github.com/subodhjena/agentic-patterns under examples/28_protocols_mcp.py as that lesson lands.
Google's six-protocol stack
MCP and A2A are the two most widely adopted protocols in the agent space, but Google's published architecture names six. Each covers a different layer of an agent system.
| Layer | Protocol | Function |
|---|---|---|
| Data | MCP | Tool and data access |
| Agent | A2A | Agent-to-agent routing |
| Commerce | UCP | Shopping workflows |
| Authorization | AP2 | Payment mandates and audit trail |
| UI | A2UI | Eighteen component primitives for rendering |
| Streaming | AG-UI | Typed Server-Sent Events, framework-agnostic |
Most teams in 2026 use MCP and A2A heavily and the others sparingly. The pattern of the stack (one published standard per problem) is more important than memorizing every protocol. Teams that build on the stack inherit whatever adoption the standards have at the time.
Where the protocols help
Adoption pays off in specific scenarios.
Multi-framework systems. A LangGraph agent calling a Claude Desktop workspace, an OpenAI Assistant calling a local Python MCP server, or a Google ADK agent calling an Anthropic agent all work because the protocols are framework-agnostic.
Long-lived tool integrations. A tool written once against MCP is available to every MCP-compatible client now and later. A tool written against a framework's native API is portable only within that framework.
Cross-organization agent systems. A2A's security model and agent-card discovery are designed for the case where the calling agent and the called agent belong to different organizations. Custom protocols rarely handle this cleanly.
Vendor independence. Teams that build on MCP and A2A avoid lock-in to a specific framework's agent and tool abstractions. The protocols travel with the agent as it moves between platforms.
Where the protocols are still maturing
The standards are young. Some edges are still rough.
Error semantics. Both protocols carry status codes, but the interpretation of specific errors is not yet uniform across implementations. A tool that returns "rate limited" on one server may return "service unavailable" on another.
Streaming fidelity. A2A's SSE streaming is consistent in spec but inconsistent in production. Some servers batch updates aggressively, producing user-visible latency.
Agent card evolution. The card format has shifted across A2A versions. Clients need to handle multiple card shapes gracefully.
Security review. A guardrail layer (covered in the Safety stage) must still vet every tool call that comes through MCP and every task sent through A2A. The protocols do not substitute for application-layer safety.
Discovery at scale. When an organization runs hundreds of MCP servers or A2A agents, discovering which one to call is itself a search problem. The protocols do not solve agent-selection; they solve invocation once the selection is made.
Trade against custom integrations
Teams sometimes wonder whether the overhead of adopting a standard is worth it when a one-off integration would be faster. The table summarizes the tradeoff.
| Axis | Custom integration | MCP or A2A |
|---|---|---|
| Time to first integration | Faster | Slower (learn the protocol) |
| Time to fifth integration | Slower (each is bespoke) | Faster (reuse the client) |
| Portability | None | High |
| Vendor independence | Low | High |
| Community support | None | Growing |
| Best fit | One-off experiments | Production systems with multiple integrations |
For production systems with more than a handful of tools or more than one agent, the standards are almost always the right choice.
Neighbors in the series
The agent-computer interface article, in the Agents stage, covers tool design; MCP is the wire format that carries those tools across process and organization boundaries. Supervisor and router, in the Multi-Agent stage, is the local-process pattern that A2A generalizes across organizations. Skills as contextual memory, in the Memory stage, covers procedural knowledge as filesystem folders; MCP servers often front those skill files for remote agents.
References
- Anthropic. Introducing the Model Context Protocol. November 2024.
- Anthropic. Model Context Protocol specification. 2024.
- Google. Agent-to-Agent (A2A) protocol. 2024.
- Linux Foundation. A2A Project governance. 2025.
- Google Cloud. Six-protocol stack for agent systems. 2024.