Agent-to-Agent Protocols: A2A and MCP Explained for Production Teams

For most of 2024 and into 2025, agent-to-agent communication was ad hoc. Teams built proprietary message formats, custom HTTP endpoints, and bespoke serialization schemes for each integration between agents. It worked, but it meant every new agent added to a system required custom integration work on both sides. Two standards have emerged to change that: MCP from Anthropic and the A2A protocol from Google. Neither has won. Both are production-ready. Understanding both is now essential for anyone building multi-agent systems.

Why Protocols Matter Now

The push for standardization in agent communication comes from a practical problem: the number of integrations grows quadratically with the number of agents. If you have ten agents that each need to communicate with each other, you have ninety potential communication paths. Without a shared protocol, each path requires a custom implementation. With a shared protocol, each agent implements the protocol once and can communicate with any other agent that does the same.

MCP: Model Context Protocol

MCP, introduced by Anthropic in late 2024, solves a specific problem: how do you give an LLM access to data and tools that live outside the model in a standardized, extensible way? Before MCP, each LLM application built its own mechanism for exposing tools to the model. MCP standardizes this as a JSON-RPC 2.0 protocol between a host (the LLM application) and servers (capability providers).

The MCP architecture has three participants. The host is the application that contains the LLM, manages client connections, and presents capabilities to the model. The client is built into the host and manages the protocol connections. Servers are external processes that provide tools, resources (data sources), and prompts to the model through the protocol.

MCP's strength is its breadth of capability types. A single MCP server can expose tools (functions the model can call), resources (data the model can read, identified by URI), and prompts (reusable instruction templates). This covers the full spectrum of ways an LLM needs to interact with external systems.

# A minimal MCP server implementation
from mcp.server import Server, NotificationOptions
from mcp.server.models import InitializationOptions
import mcp.server.stdio
import mcp.types as types

server = Server("research-server")

@server.list_tools()
async def handle_list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="web_search",
            description="Search the web for information",
            inputSchema={
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "Search query"},
                    "max_results": {"type": "number", "default": 5},
                },
                "required": ["query"],
            },
        ),
    ]

@server.call_tool()
async def handle_call_tool(name: str, arguments: dict) -> list[types.TextContent]:
    if name == "web_search":
        results = await search(arguments["query"], arguments.get("max_results", 5))
        return [types.TextContent(type="text", text=format_results(results))]
    raise ValueError(f"Unknown tool: {name}")

@server.list_resources()
async def handle_list_resources() -> list[types.Resource]:
    return [
        types.Resource(
            uri="research://documents/latest",
            name="Latest research documents",
            description="Most recently added research documents",
        ),
    ]

async def main():
    async with mcp.server.stdio.stdio_server() as (read_stream, write_stream):
        await server.run(read_stream, write_stream,
            InitializationOptions(server_name="research-server", server_version="1.0"))

A2A: Agent-to-Agent Protocol

A2A, introduced by Google in early 2025, solves a different problem: how do agents delegate tasks to other agents? Where MCP is about connecting models to tools, A2A is about connecting agents to other agents. The key concept in A2A is the agent card, a JSON document that describes an agent's capabilities, authentication requirements, and API endpoints. Agents discover each other through these cards.

The A2A workflow has a clear structure. The caller fetches the callee's agent card from a well-known URL. The caller authenticates using the mechanism specified in the card. The caller submits a task as a structured JSON request to the agent's endpoint. The callee processes the task and streams status updates. Then the callee returns a structured result with typed artifacts.

# A2A client, sending a task to another agent
import httpx
from dataclasses import dataclass
from typing import AsyncIterator

@dataclass
class AgentCard:
    name: str
    url: str
    capabilities: list[str]
    auth_type: str  # "bearer" | "mtls" | "apikey"

async def fetch_agent_card(agent_url: str) -> AgentCard:
    async with httpx.AsyncClient() as client:
        resp = await client.get(f"{agent_url}/.well-known/agent.json")
        data = resp.json()
        return AgentCard(**data)

async def send_task(
    agent: AgentCard,
    task_description: str,
    context: dict,
    auth_token: str,
) -> AsyncIterator[dict]:
    """Send a task to an A2A agent and stream status updates."""
    payload = {
        "id": generate_task_id(),
        "message": {
            "role": "user",
            "parts": [{"type": "text", "text": task_description}],
        },
        "metadata": context,
    }
    async with httpx.AsyncClient() as client:
        async with client.stream(
            "POST",
            f"{agent.url}/a2a",
            json=payload,
            headers={"Authorization": f"Bearer {auth_token}"},
            timeout=300,
        ) as response:
            async for line in response.aiter_lines():
                if line.startswith("data: "):
                    event = json.loads(line[6:])
                    yield event
                    if event.get("final"):
                        break

# Usage: orchestrator sending a task to a research worker
research_agent = await fetch_agent_card("https://research-worker.internal")
async for update in send_task(research_agent, "Research AI safety papers from 2025", {}, token):
    if update["type"] == "status":
        print(f"Status: {update['status']}")
    elif update["type"] == "artifact":
        print(f"Result: {update['artifact']['text']}")

Key Differences Between MCP and A2A

The most important distinction is the level of abstraction. MCP operates at the model level. It gives a model access to capabilities through a standardized interface. The model decides when and how to use those capabilities as part of its reasoning. A2A operates at the agent level. It lets one complete agent system delegate work to another complete agent system. The delegating agent doesn't need to know how the receiving agent works internally.

• Scope: MCP connects an LLM to tools and data. A2A connects an agent to other agents.
• Statefulness: MCP tool calls are stateless (each call is independent). A2A tasks are stateful (the receiving agent manages task state through completion).
• Streaming: MCP returns results synchronously. A2A supports long-running tasks with streaming status updates.
• Discovery: MCP servers are registered manually by the operator. A2A supports dynamic discovery through agent cards at well-known URLs.
• Trust model: MCP operates within a single trust boundary (the host application). A2A explicitly models trust between independent agents.

MCP in Practice

MCP has strong production adoption for tool and data source integration. Claude Desktop supports MCP servers directly. Cursor and VS Code have MCP integration. The ecosystem of open-source MCP servers for common services (GitHub, Slack, databases, file systems) is substantial and growing.

The primary MCP security concern is supply chain risk. Any MCP server you connect to a model becomes a path for tool injection attacks. A malicious MCP server can return carefully crafted responses that manipulate the model's subsequent behavior. Vet MCP servers with the same scrutiny you'd apply to any production dependency, and run them in sandboxed environments.

A2A in Practice

A2A is newer and the production ecosystem is less mature than MCP's. But the pattern of task delegation between agent systems is fundamental enough that A2A, or something very much like it, will be the backbone of most multi-agent production systems by the end of 2026. Building your agent communication layer to be compatible with A2A semantics now is forward-compatible work.

The agent card is the most important concept for teams getting started with A2A. Before worrying about the full protocol, define your agent cards. They are the contract between agents. A well-designed agent card describes capability precisely enough that an orchestrator agent can decide autonomously whether to delegate a task to a given worker.

{
  "name": "research-specialist-agent",
  "description": "Specializes in finding and summarizing technical documents",
  "url": "https://agents.yourcompany.com/research",
  "version": "2.1.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "stateTransitionHistory": true
  },
  "skills": [
    {
      "id": "research-topic",
      "name": "Research a Topic",
      "description": "Given a topic, finds relevant documents, summarizes key findings, and returns structured research notes",
      "tags": ["research", "summarization", "technical"],
      "examples": [
        "Research the latest developments in transformer architecture",
        "Find papers on prompt injection defenses published in 2025"
      ],
      "inputModes": ["text"],
      "outputModes": ["text", "data"]
    }
  ],
  "authentication": {
    "schemes": ["Bearer"]
  }
}

When to Use Which Protocol

Use MCP when you need to give a language model structured access to tools and data sources you control. File system access, database queries, API calls, code execution, and document retrieval are all natural MCP use cases. Use A2A when you need one agent system to delegate multi-step tasks to another agent system, especially when those systems are independently developed, deployed, or operated.

The two protocols compose well. An agent that receives A2A tasks can use MCP servers internally to execute those tasks. The A2A layer handles inter-agent delegation. The MCP layer handles the agent's access to tools and data. This is the architecture most production multi-agent systems will converge on.

Interoperability and the Real World

Both protocols are still evolving. The A2A specification had significant changes between its initial release and v0.2. The MCP specification added streaming support and changed its transport recommendations. Building tight coupling to specific protocol versions creates upgrade debt. Design your agent communication layer with a protocol adapter pattern so that the core agent logic is independent of the specific protocol version.

Conclusion

MCP and A2A address different layers of the multi-agent stack and are best understood as complementary rather than competing. MCP standardizes how models access tools and data. A2A standardizes how agents delegate tasks to other agents. The teams that understand both protocols and know when to apply each will ship more interoperable, maintainable multi-agent systems than those who rely on ad hoc communication patterns.