RL Theory
Agent Protocols: MCP and A2A
The protocol layer for AI agents: MCP (Model Context Protocol) for tool access, A2A (Agent-to-Agent) for inter-agent communication, and why standardized interfaces matter for the agent ecosystem.
Prerequisites
Why This Matters
Every useful AI agent needs to interact with the world: read files, query databases, call APIs, browse the web. Without standards, every agent framework builds its own tool integration layer. The result: agents and tools require custom integrations. This is the same problem the web faced before HTTP, or that payment systems faced before standard card protocols.
Agent protocols solve this with a standard interface layer. MCP standardizes how agents access tools and data. A2A standardizes how agents communicate with other agents. Together, they make the agent ecosystem composable: any agent can use any tool, and any agent can collaborate with any other agent, without custom integration per pair.
Mental Model
Think of agent protocols like USB for AI. Before USB, every peripheral (printer, mouse, keyboard) needed its own proprietary connector. After USB, any device works with any computer through a standard interface. MCP is the "USB for tools": any LLM can use any MCP-compatible tool. A2A is the "network protocol for agents": any agent can discover and communicate with any other agent.
The Protocol Landscape
The current agent protocol ecosystem includes four main proposals:
- MCP (Model Context Protocol). Anthropic. Standardizes how LLMs access tools and data sources.
- A2A (Agent-to-Agent). Google. Standardizes how agents discover and communicate with other agents.
- ACP (Agent Communication Protocol). IBM/BeeAI. Focuses on asynchronous agent-to-agent messaging.
- ANP (Agent Network Protocol). Community-driven. Aims for a unified agent networking standard.
MCP and A2A are the most widely adopted as of 2026 and solve complementary problems.
MCP: Model Context Protocol
Model Context Protocol (MCP)
MCP is a standardized protocol for connecting LLMs to external tools and data sources. It defines a client-server architecture where:
- MCP Host: The application (IDE, chat interface, agent framework) that contains the LLM
- MCP Client: A component within the host that maintains a connection to an MCP server
- MCP Server: A lightweight program that exposes tools, resources, and prompts through the MCP standard
The protocol defines three core primitives:
- Tools: Functions the model can call (execute code, query database)
- Resources: Data the model can read (files, API responses, live data)
- Prompts: Reusable prompt templates with arguments
How MCP Works
An MCP server exposes a set of capabilities through a JSON-RPC interface. When an LLM needs to use a tool:
- The host queries the MCP server for available tools (discovery)
- The server responds with tool descriptions, schemas, and parameter types
- The LLM generates a tool call matching the schema
- The host sends the call to the MCP server
- The server executes the tool and returns the result
- The result is injected into the LLM's context
This is similar to function calling, but with a critical difference: the tool definitions come from an external, standardized server, not from the model's training data or the application's hardcoded tool list. Any MCP server works with any MCP-compatible host.
Why MCP Matters
Without MCP, tool integration is bespoke. Each agent framework (LangChain, CrewAI, AutoGen) defines its own tool interface. A tool built for LangChain does not work in CrewAI without a wrapper. This fragments the ecosystem and creates maintenance burden.
With MCP, a tool author writes one MCP server. Every MCP-compatible agent framework can use it. The tool ecosystem becomes shared infrastructure rather than framework-specific code.
Every major agent framework now supports MCP. Claude Code, Cursor, Windsurf, and VS Code (via GitHub Copilot) use MCP for tool access. LangChain, CrewAI, and AutoGen provide MCP client integrations. The practical effect: an MCP server for a database (e.g., PostgreSQL) works across all these environments without modification. This is why the MCP ecosystem has grown rapidly. tool authors get broad distribution by targeting a single standard.
A2A: Agent-to-Agent Protocol
Agent-to-Agent Protocol (A2A)
A2A is a protocol for agents to discover, communicate with, and delegate tasks to other agents. Where MCP connects agents to tools, A2A connects agents to other agents. The protocol defines:
- Agent Cards: JSON metadata describing an agent's capabilities, input requirements, and authentication methods. Published at a well-known URL for discovery.
- Task Management: A lifecycle for delegated tasks (create, query status, receive results, cancel).
- Message Exchange: Structured communication between agents, supporting text, files, and structured data.
- Streaming: Support for long-running tasks with incremental results.
How A2A Works
Agent A wants to delegate a subtask to Agent B:
- Discovery: Agent A fetches Agent B's Agent Card from its well-known URL. The card describes what Agent B can do and what inputs it needs.
- Task creation: Agent A sends a task request to Agent B with the required inputs.
- Execution: Agent B processes the task, possibly using its own tools (via MCP) and sub-agents (via A2A).
- Result delivery: Agent B returns the result to Agent A. For long tasks, streaming provides incremental updates.
MCP and A2A Are Complementary
MCP and A2A solve different problems:
| Aspect | MCP | A2A |
|---|---|---|
| Connects | Agents to tools | Agents to agents |
| Direction | Agent calls tool | Agent delegates to agent |
| Complexity | Simple request-response | Task lifecycle management |
| State | Stateless (per call) | Stateful (task progress) |
| Use case | "Query this database" | "Research this topic" |
A production agent system typically uses both: MCP for direct tool access and A2A for delegating complex sub-tasks to specialized agents.
The Composability Principle
Protocol-Based Composability
Statement
With a standardized protocol layer, agents can access tools and communicate with each other using integration effort (each agent implements the protocol once, each tool implements the protocol once). Without standardization, the same capabilities require custom integrations.
For the A2A protocol specifically, agents can form possible collaboration pairs with only implementation effort (each agent implements the A2A interface once).
The value of the protocol ecosystem grows quadratically with the number of participants while the implementation cost grows linearly.
Intuition
This is the same network effect that made the web valuable. HTTP let any browser access any website. MCP lets any agent use any tool. The protocol is the shared abstraction that turns an integration problem into an problem. Each new tool or agent that joins the ecosystem immediately interoperates with everything else.
Why It Matters
Without standardized protocols, the agent ecosystem fragments into walled gardens. Each framework has its own tools, its own integrations, and its own agent-to-agent communication scheme. Users are locked into a single framework. With protocols, users can mix agents and tools from different vendors. This creates competitive pressure and accelerates ecosystem growth.
Failure Mode
Protocols succeed only if they achieve critical mass. A protocol with 3 compatible tools is not useful. Competing protocols can fragment the ecosystem worse than no protocol at all. MCP's rapid adoption by major platforms (Anthropic, Microsoft, Google, and many others) suggests it may achieve the critical mass needed. But the protocol landscape is still evolving, and consolidation is not guaranteed.
Protocol Design Decisions
Authentication and Security
Both MCP and A2A must handle authentication: who is allowed to call which tools and which agents? MCP delegates authentication to the transport layer (OAuth, API keys). A2A includes authentication in the Agent Card specification. Security is critical because agents with tool access can have real-world effects (write files, send emails, execute code).
Synchronous vs Asynchronous
MCP is primarily synchronous: call a tool, get a result. A2A supports both synchronous (immediate result) and asynchronous (long-running task with status updates). Asynchronous support is essential for agents that delegate multi-hour research tasks or complex computations.
Discoverability
A2A addresses agent discovery through Agent Cards published at well-known URLs. MCP servers are typically configured explicitly (the host knows which servers to connect to). Future extensions may add dynamic tool discovery to MCP.
Common Confusions
MCP is not function calling
Function calling is a model capability: the model generates structured tool calls. MCP is a protocol: it standardizes how those tool calls reach external tools. A model that supports function calling still needs MCP (or an equivalent) to connect to tools that live outside the model's host application. MCP standardizes the connection; function calling standardizes the model's output format.
A2A does not require agents to understand each other's internals
A2A is a communication protocol, not a shared reasoning framework. Agent A does not need to know how Agent B works internally. It only needs to know what Agent B can do (from the Agent Card), what inputs it needs, and what outputs it produces. This is the same principle as API design: the interface is public, the implementation is private.
Protocols do not make agents reliable
MCP and A2A standardize communication, not capability. An agent that hallucinates will still hallucinate when using MCP tools. A tool that returns wrong results will still return wrong results over the MCP protocol. Protocols solve the integration problem, not the reliability problem. Reliability requires evaluation, monitoring, and guardrails at a different layer.
Summary
- MCP standardizes agent-to-tool communication (Anthropic)
- A2A standardizes agent-to-agent communication (Google)
- MCP primitives: tools (call), resources (read), prompts (templates)
- A2A primitives: agent cards (discover), tasks (delegate), messages (communicate)
- Without protocols: integrations. With protocols:
- MCP and A2A are complementary: MCP for tools, A2A for delegation
- Major frameworks (LangChain, CrewAI, Claude Code, Cursor) support MCP
- Protocols solve integration, not reliability
- The ecosystem is still consolidating; MCP has the strongest adoption
Exercises
Problem
An organization has 4 agent frameworks and 10 custom tools. Without MCP, how many integrations do they need? With MCP, how many implementations are needed? What is the savings?
Problem
Design a multi-agent system using MCP and A2A for the following task: a user asks "What were the key findings in last quarter's financial report, and how do they compare to analyst expectations?" Identify which interactions use MCP and which use A2A.
References
Canonical:
- Anthropic, "Model Context Protocol Specification" (2024)
- Google, "Agent-to-Agent Protocol Specification" (2025)
Current:
- IBM/BeeAI, "Agent Communication Protocol (ACP)" (2025)
- MCP community documentation and server registry (2025-2026)
Next Topics
The natural next steps from agent protocols:
- Context engineering: how protocol-mediated tool outputs and agent responses are assembled into the model's context
- Hallucination theory: reliability challenges that protocols do not solve but make more visible
Last reviewed: April 2026
Prerequisites
Foundations this topic depends on.
- Agentic RL and Tool UseLayer 5
- Markov Decision ProcessesLayer 2
- Convex Optimization BasicsLayer 1
- Differentiation in RnLayer 0A
- Sets, Functions, and RelationsLayer 0A
- Basic Logic and Proof TechniquesLayer 0A
- Matrix Operations and PropertiesLayer 0A
- Concentration InequalitiesLayer 1
- Common Probability DistributionsLayer 0A
- Expectation, Variance, Covariance, and MomentsLayer 0A
- Policy Gradient TheoremLayer 3
Builds on This
- Multi-Agent CollaborationLayer 4