MCP and A2A: The Two Protocols Shaping Multi-Agent Architecture

Your agent works: it reasons, calls tools and returns results, with one task and one context.

Now put five of them together. One triages support tickets. Another queries your database. A third drafts a response. They need to discover each other, exchange structured data and coordinate without a human routing every message.

The single-agent model breaks at this point, and two protocols step in: MCP connects agents to tools, A2A connects agents to each other. Together, they form the foundation of multi-agent systems in 2026.

The problem with one agent that does everything

A monolithic agent that handles every task sounds appealing but hits a wall fast.

The context window fills up with tool descriptions it does not need. Permissions become impossible to scope. A prompt change for one use case breaks another. Debugging is a guessing game because everything runs in the same loop.

Monolithic applications faced the same constraints a decade ago, and the answer was microservices: small, specialized services that communicate through well-defined interfaces.

Multi-agent systems follow the same trajectory. They have specialized agents, clear boundaries and standardized communication. Microservices had HTTP, REST and gRPC, and agents now have protocols of their own.

MCP: the tool layer

The Model Context Protocol is an open standard, originally created by Anthropic and now governed by the Linux Foundation. It defines how an AI agent connects to external tools, data sources and APIs.

Think of MCP as the vertical axis of your architecture. An agent reaches down to interact with the outside world: databases, file systems, third-party services. Before MCP, every integration was custom glue code. With MCP, you write a server once and every compatible client can use it.

How it works

An MCP server exposes three types of capabilities:

• Tools: functions the agent can call (query a database, send an email, create a GitHub issue)
• Resources: data the agent can read (files, documents, configuration)
• Prompts: reusable prompt templates the server offers to clients

The client discovers these capabilities through a handshake, then calls them via JSON-RPC. The server can run locally (stdio transport) or remotely (Streamable HTTP transport).

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "inventory-server",
  version: "1.0.0",
});

server.tool(
  "checkStock",
  { productId: z.string(), warehouse: z.string() },
  async ({ productId, warehouse }) => {
    const stock = await db.inventory.check(productId, warehouse);
    return {
      content: [
        { type: "text", text: JSON.stringify(stock) },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

The transport evolution

MCP's transport layer has gone through three generations:

Streamable HTTP is now the recommended transport for remote servers. A single HTTP endpoint handles both requests and optional streaming. It works behind load balancers, scales horizontally and supports stateless deployments. The stdio transport remains valid for local tools and CLI integrations.

Adoption and ecosystem

The numbers as of early 2026:

• 97 million monthly SDK downloads (Python + TypeScript combined)
• Over 17,000 MCP servers indexed
• Supported by Claude, ChatGPT, Gemini, Cursor, VS Code, JetBrains IDEs
• Official servers for GitHub, Slack, Notion, Jira, PostgreSQL, Stripe, AWS

If you are building a tool that agents need to access, expose it via MCP.

What MCP does not solve

MCP handles agent-to-tool communication. It says nothing about how agents talk to each other. An MCP server does not know which agent is calling it or whether that agent was dispatched by another agent. There is no task lifecycle, no capability discovery between agents, no structured handoff. The second protocol fills that gap.

A2A: the collaboration layer

The Agent-to-Agent protocol was created by Google in April 2025 and is now under the Linux Foundation. It defines how agents discover each other, exchange messages and coordinate tasks.

If MCP is the vertical axis (agent reaches down to tools), A2A is the horizontal axis (agent reaches across to peer agents). The two protocols operate on different planes and complement each other.

Agent Cards: service discovery for agents

Every A2A-compatible agent publishes an Agent Card at a well-known URL (/.well-known/agent-card.json). This JSON document describes what the agent can do, how to authenticate and which input/output formats it supports.

{
  "name": "Inventory Agent",
  "description": "Manages stock levels and warehouse operations",
  "version": "1.0.0",
  "url": "https://inventory.internal.company.com",
  "skills": [
    {
      "id": "check-availability",
      "name": "Check Product Availability",
      "description": "Returns real-time stock levels across warehouses",
      "tags": ["inventory", "stock", "warehouse"]
    },
    {
      "id": "reorder",
      "name": "Trigger Reorder",
      "description": "Places a reorder when stock drops below threshold",
      "tags": ["inventory", "procurement"]
    }
  ],
  "defaultInputModes": ["text", "data"],
  "defaultOutputModes": ["text", "data"],
  "authentication": {
    "schemes": ["oauth2"]
  }
}

An orchestrator agent can fetch Agent Cards, match skills to the task at hand and route work accordingly. Routing is not hardcoded and no central configuration file lists every agent: discovery is decentralized, like DNS for agents.

Task lifecycle

A2A structures communication around tasks. A client agent sends a message, the server agent creates a task and updates its state as work progresses:

WORKING → INPUT_REQUIRED → WORKING → COMPLETED

Or: WORKING → FAILED

Or: WORKING → CANCELED (client-initiated)

This state machine gives the calling agent visibility into progress. It can wait for completion, provide additional input when requested, or cancel a task that takes too long. Compare this to a raw HTTP call where you get a response or a timeout, with nothing in between.

A TypeScript implementation

import {
  AgentCard,
  AgentExecutor,
  ExecutionEventBus,
  RequestContext,
} from "@a2a-js/sdk";

const agentCard: AgentCard = {
  name: "Code Review Agent",
  description:
    "Reviews pull requests for security and performance issues",
  protocolVersion: "0.3.0",
  version: "1.0.0",
  url: "https://review-agent.internal.company.com",
  skills: [
    {
      id: "review-pr",
      name: "Review Pull Request",
      description:
        "Analyzes a PR diff for security vulnerabilities, performance regressions and code style",
    },
  ],
  defaultInputModes: ["text"],
  defaultOutputModes: ["text"],
};

class CodeReviewExecutor implements AgentExecutor {
  async execute(
    context: RequestContext,
    eventBus: ExecutionEventBus
  ) {
    const message = context.message;
    const prUrl = extractPrUrl(message);

    eventBus.publish({
      state: "WORKING",
      message: "Fetching PR diff...",
    });

    const diff = await fetchPrDiff(prUrl);
    const review = await analyzeWithLlm(diff);

    eventBus.publish({
      state: "COMPLETED",
      artifacts: [{ type: "text", text: review }],
    });
  }
}

The calling agent sends a message with the PR URL. The code review agent acknowledges, processes the diff and returns a structured result. The caller knows the task state at every step.

How they fit together

The emerging architecture has three layers:

Here is how a concrete system looks:

User request: "Analyze last week's support tickets and draft a report"
       │
       ▼
┌─────────────────────┐
│  Orchestrator Agent  │ ← receives the task
│  (A2A client)        │
└───────┬─────────┬───┘
        │ A2A     │ A2A
        ▼         ▼
┌──────────┐ ┌──────────┐
│  Ticket  │ │  Report  │
│  Analyst │ │  Writer  │
│  Agent   │ │  Agent   │
└────┬─────┘ └────┬─────┘
     │ MCP        │ MCP
     ▼            ▼
┌──────────┐ ┌──────────┐
│  Zendesk │ │  Google  │
│  Server  │ │  Docs    │
│  (MCP)   │ │  Server  │
└──────────┘ └──────────┘

The orchestrator discovers specialist agents via their Agent Cards. It delegates ticket analysis to one agent and report writing to another, using A2A. Each specialist agent connects to its tools via MCP. The orchestrator never needs to know about Zendesk or Google Docs. It only needs to know which agents have the right skills.

The mental model from Cisco's engineering team puts it well: MCP is Layer 2 (direct visibility, local access) and A2A is Layer 3 (routing boundary, capability aggregation). If you have built distributed systems before, this maps directly to concepts you already know.

Frameworks that support both protocols

The TypeScript ecosystem is already catching up.

Mastra is the most advanced. It supports MCP server authoring (exposing agents and tools via MCP), MCP client consumption (agents using external MCP servers) and native A2A protocol support for inter-agent communication. The Mastra 1.0 article covers the framework in detail.

LangChain supports A2A endpoints through its Agent Server and MCP tool integration, though primarily in Python.

Google ADK provides native A2A quickstarts for exposing agents, with MCP tool support built in.

The pattern across all of them is the same: MCP for downward integration with tools, A2A for lateral integration with peer agents. For putting it into practice in an existing project, see the guide to designing an agentic module.

Production considerations

Deploying a multi-agent system with both protocols introduces specific challenges.

Security

MCP servers are often thin wrappers around databases, APIs or code interpreters. A misconfigured server is a direct attack surface. Apply least privilege: each agent should only access the MCP servers it needs. Validate tool parameters server-side. Use OAuth 2.1 for remote MCP connections.

A2A adds another dimension. Agent Cards declare authentication requirements, but the protocol does not enforce them. Digital signatures (JWS) for Agent Cards are optional. In a production system, verify Agent Card authenticity before routing tasks to unknown agents.

Observability

Traditional monitoring tools were not designed for agentic architectures. When an orchestrator delegates to three agents, each calling multiple MCP tools, a single user request can span dozens of operations across services.

You need distributed tracing that follows the full chain: user request → orchestrator → A2A delegation → agent processing → MCP tool calls → results. Without this, debugging a failure in a multi-agent pipeline is guesswork.

33% of organizations currently lack audit trails for AI agent activity. This is the gap to close first.

Enterprise gaps

Both protocols are production-ready for the core specification. The enterprise layer is still maturing:

• MCP: SSO integration is replacing static client secrets. Gateway patterns for centralized policy enforcement are emerging but not standardized. Configuration portability across environments remains manual.
• A2A: Agent Card registries for enterprise-scale discovery are early-stage. Cost allocation across multi-agent workflows is undefined. Liability in chained agent decisions is an open legal question.

These gaps do not block adoption, but they shape where you start. Begin with internal agents behind your firewall, where trust and network boundaries are well-understood. External agent-to-agent communication can come later, once the governance tooling catches up.

The microservices parallel

Every architectural shift in our industry follows the same arc. Monoliths become uncomfortable. Someone proposes decomposition. Standards emerge for communication between the pieces. Tooling matures. The industry consolidates around a few patterns.

We went through this with web services (SOAP, then REST, then gRPC). We went through it with microservices (service meshes, API gateways, distributed tracing). We are going through it now with AI agents.

MCP is the equivalent of a database driver or an API client. A2A is the equivalent of gRPC between microservices. Agent Cards are service discovery. The concepts map directly.

If you have built distributed systems before, you already have the mental models: the protocols are recent, the architecture is the same. One point of caution: decomposing does not mean spreading the writes, see why only one agent should write.

MCP already has 97 million monthly downloads and 17,000 servers, and A2A is backed by Google, Microsoft, AWS and Salesforce. Teams that learn multi-agent architecture early will know how to decompose problems into specialized agents, connect them through standard protocols and operate them in production.

Start with one MCP server for a tool your agents already use. Add a second agent with an Agent Card. Make them collaborate. That is the starting point I take on an agents and workflows powered by language models engagement when the product needs several agents from day one.