Beta. Content is under active construction and has not been peer-reviewed. Report errors on GitHub.Disclaimer

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.

AdvancedTier 3Frontier~45 min
0

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: NN agents and MM tools require N×MN \times M 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:

  1. MCP (Model Context Protocol). Anthropic. Standardizes how LLMs access tools and data sources.
  2. A2A (Agent-to-Agent). Google. Standardizes how agents discover and communicate with other agents.
  3. ACP (Agent Communication Protocol). IBM/BeeAI. Focuses on asynchronous agent-to-agent messaging.
  4. 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

Definition

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:

  1. Tools: Functions the model can call (execute code, query database)
  2. Resources: Data the model can read (files, API responses, live data)
  3. 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:

  1. The host queries the MCP server for available tools (discovery)
  2. The server responds with tool descriptions, schemas, and parameter types
  3. The LLM generates a tool call matching the schema
  4. The host sends the call to the MCP server
  5. The server executes the tool and returns the result
  6. 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.

Where This Shows Up in Current Papers

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

Definition

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:

  1. Agent Cards: JSON metadata describing an agent's capabilities, input requirements, and authentication methods. Published at a well-known URL for discovery.
  2. Task Management: A lifecycle for delegated tasks (create, query status, receive results, cancel).
  3. Message Exchange: Structured communication between agents, supporting text, files, and structured data.
  4. Streaming: Support for long-running tasks with incremental results.

How A2A Works

Agent A wants to delegate a subtask to Agent B:

  1. 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.
  2. Task creation: Agent A sends a task request to Agent B with the required inputs.
  3. Execution: Agent B processes the task, possibly using its own tools (via MCP) and sub-agents (via A2A).
  4. 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:

AspectMCPA2A
ConnectsAgents to toolsAgents to agents
DirectionAgent calls toolAgent delegates to agent
ComplexitySimple request-responseTask lifecycle management
StateStateless (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

Proposition

Protocol-Based Composability

Statement

With a standardized protocol layer, NN agents can access MM tools and communicate with each other using O(N+M)O(N + M) integration effort (each agent implements the protocol once, each tool implements the protocol once). Without standardization, the same capabilities require O(N×M)O(N \times M) custom integrations.

For the A2A protocol specifically, NN agents can form O(N2)O(N^2) possible collaboration pairs with only O(N)O(N) 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 N×MN \times M integration problem into an N+MN + M 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

Watch Out

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.

Watch Out

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.

Watch Out

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: O(N×M)O(N \times M) integrations. With protocols: O(N+M)O(N + M)
  • 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

ExerciseCore

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?

ExerciseAdvanced

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.

Builds on This

Next Topics