MCP + A2A Protocol: The Complete Architecture Guide

In November 2024, Anthropic open-sourced the Model Context Protocol. In April 2025, Google followed with Agent-to-Agent (A2A). By December 2025, both protocols sat under Linux Foundation governance, with OpenAI, Microsoft, AWS, and Block as co-founders. By March 2026, MCP had crossed 97 million monthly SDK downloads — faster adoption than almost any protocol in computing history. Something structural is happening. This guide explains what, exactly, and what it means if you are building on it.

Why These Protocols Matter Right Now

Before MCP and A2A, connecting AI systems to tools and to each other required custom integrations for every single combination. Ten AI applications and 100 tools meant potentially 1,000 different integrations. This was the “M × N problem” — and it was killing real-world AI deployment before it started. Every AI vendor built their own tool-calling system. None of them talked to each other. The economic cost was brutal.

The analogy that stuck — and is now used across the industry — is this: MCP is USB-C for AI. A2A is HTTP for AI agents. The analogy is imperfect, as all analogies are, but it captures something real. MCP gives an agent hands. A2A gives agents a language to talk to each other. Together they solve the M × N problem at two different levels.

MCP Architecture Deep Dive

MCP uses a client-server architecture built on JSON-RPC 2.0. A host application — Claude Desktop, Claude Code, Cursor, VS Code with Copilot — creates multiple isolated MCP client sessions. Each session maintains a stateful JSON-RPC channel with its own MCP server. Servers expose capabilities; clients consume them. The host enforces user consent and security boundaries.

  ┌─────────────────────────────────────────────┐  │              HOST APPLICATION               │  │     (Claude Desktop / Cursor / VS Code)     │  │                                             │  │   ┌─────────────┐     ┌─────────────┐      │  │   │  MCP Client │     │  MCP Client │      │  │   │   Session A │     │   Session B │      │  │   └──────┬──────┘     └──────┬──────┘      │  └──────────┼───────────────────┼─────────────┘             │  JSON-RPC 2.0     │  JSON-RPC 2.0    ┌────────▼────────┐   ┌──────▼────────┐    │   MCP Server    │   │   MCP Server  │    │   (Filesystem)  │   │   (Postgres)  │    └────────┬────────┘   └──────┬────────┘             │                   │          Local Files       Database

The Three Primitives: Tools, Resources, and Prompts

Every MCP server exposes its capabilities through exactly three primitives. Understanding these is understanding MCP itself.

This separation of concerns is not accidental. By distinguishing who controls each primitive, MCP encodes a consent model into the protocol itself. Tools change the world and require the model to decide when to invoke them. Resources provide context and are surfaced by the application. Prompts encode expertise and are selected by the user. The design prevents a single party from unilaterally doing something dangerous.

// Client → Server: request to list available tools{  "jsonrpc": "2.0",  "id": 1,  "method": "tools/list"}// Server → Client: tool manifest{  "tools": [{    "name": "query_database",    "description": "Run a read-only SQL query",    "inputSchema": {      "type": "object",      "properties": {        "sql": { "type": "string" }      },      "required": ["sql"]    }  }]}

Streamable HTTP Transport & MCP v2

MCP launched with two transports: stdio for local subprocess communication (still the default for desktop clients) and HTTP with SSE for remote servers. The March 2025 spec replaced SSE with Streamable HTTP — a single /mcp endpoint that handles both fast synchronous responses and long-running streaming tasks over the same connection.

The critical architectural shift Streamable HTTP enabled: stateless operation. The original SSE transport pinned each MCP session to a specific server process. Scaling required session-affinity infrastructure. Streamable HTTP eliminates this. MCP servers can now be deployed as Kubernetes pods, serverless functions, or Cloudflare Workers, scaled horizontally behind a standard load balancer — the same deployment model as a REST API.

The November 2025 spec (the formal “v1” anniversary release) added a capability that fundamentally changes what MCP can do: sampling with tool support. Previously, MCP servers could request that clients run inference on their behalf (sampling), but those requests couldn’t include tool definitions. This meant servers couldn’t run their own agentic loops. The 2025 spec closes this gap. Servers can now include tool definitions in sampling requests, implement multi-step reasoning, and execute parallel tool calls — all server-side, without requiring complex client implementations.

Looking at the 2026 roadmap, the forthcoming MCP Server Cards (analogous to A2A’s Agent Cards) will allow servers to advertise their capabilities in a machine-readable format at a well-known URL, enabling automatic discovery without manual configuration. This moves MCP from a configured protocol to a discoverable one — a significant upgrade for enterprise deployments at scale.

A2A Protocol Architecture Deep Dive

If MCP is about equipping an AI agent with tools, A2A is about connecting agents with each other. Where MCP is vertical (agent down to tool layer), A2A is horizontal (agent to agent, peer-to-peer or orchestrated). It was built from Google’s internal experience scaling multi-agent enterprise systems — the kind of experience that reveals problems invisible in small deployments.

A2A uses three well-understood web technologies for transport — HTTP, JSON-RPC 2.0, and Server-Sent Events — specifically because enterprises already know how to secure, monitor, and scale them. The protocol design philosophy was to solve new coordination problems with existing infrastructure, not to require new infrastructure.

Agent Cards & Dynamic Discovery

The most important concept in A2A is the Agent Card — a JSON document served at /.well-known/agent-card.json that describes what an agent can do, how to reach it, and what authentication it requires. Think of it as a business card, capabilities manifest, and API specification rolled into one.

// GET /.well-known/agent-card.json{  "name": "InventoryAgent",  "description": "Manages warehouse inventory and triggers reorders",  "url": "https://agents.acme.com/inventory",  "version": "1.4.2",  "capabilities": {    "streaming": true,    "pushNotifications": true  },  "skills": [{    "id": "check_stock",    "name": "Check Stock Levels",    "description": "Returns current inventory for SKU(s)",    "inputModes": ["text"],    "outputModes": ["text", "data"]  }],  "securitySchemes": {    "oauth2": {      "type": "oauth2",      "flows": {        "clientCredentials": {          "tokenUrl": "https://auth.acme.com/token"        }      }    }  }}

What makes Agent Cards powerful is that they enable dynamic discovery without a central registry. A client agent can fetch an Agent Card from any URL, understand what the remote agent offers, verify the authentication requirements, and begin coordination — all without any prior configuration or API documentation review by a human.

Task Lifecycle & Async Patterns

The A2A task lifecycle is one of the protocol’s most carefully designed aspects. Enterprise agent workflows are not fast — they may involve human review, multi-step reasoning, external API calls, or waiting for events that haven’t happened yet. A2A is async-first by design, not as an afterthought.

The input-required state is particularly significant. It formalizes human-in-the-loop patterns that previously required custom implementation in every system. An agent can pause a multi-day enterprise workflow, surface a request to a human via any channel, resume when the input arrives — and the A2A protocol tracks the state throughout.

MCP + A2A: The Two-Layer Stack

When you put both protocols together, a coherent architecture emerges that solves the full spectrum of AI integration challenges. The canonical way to think about it:

  ┌─────────────────────────────────────────────────────┐  │              ORCHESTRATOR AGENT                     │  │        (Your primary AI / LLM application)          │  └────────────────┬────────────┬────────────────────────┘                   │ A2A        │ MCP          ┌────────▼──────┐  ┌──▼──────────────────────┐          │ SPECIALIST    │  │  TOOL LAYER               │          │ AGENTS        │  │  • Databases              │          │               │  │  • File Systems           │          │  Agent A  ←──A2A  │  • CRM / SaaS APIs        │          │  Agent B  ←──A2A  │  • Internal Services      │          │  Agent C  ←──A2A  │  • Web / Search           │          └───────────────┘  └───────────────────────────┘           Horizontal layer       Vertical layer           (peer coordination)    (tool access)

The IBM documentation captures the complementary relationship precisely: a retail inventory agent using MCP to interact with its product database; when stock runs low, it uses A2A to communicate with an external supplier agent to place orders. MCP gives the inventory agent access to its data. A2A gives it the ability to coordinate with an agent it does not own, running on infrastructure it does not control.

“The two-layer stack — MCP for vertical tool integration, A2A for horizontal agent coordination — is rapidly becoming the architectural default for enterprise agent deployments.”

— Zylos Research, Agent Interoperability Protocols 2026

With both protocols now governed by the same Agentic AI Foundation under the Linux Foundation, they will evolve in concert. The risk of divergence — different auth models, incompatible discovery mechanisms, conflicting transport approaches — is structurally mitigated. The 2026 roadmap shows explicit work on making MCP Server Cards and A2A Agent Cards convergent in format.

Security: The Honest Assessment

No honest guide to MCP can avoid this section. Rapid adoption has outpaced security hardening. The OpenSSF AI/ML Security Working Group launched SAFE-MCP in 2026, cataloging over 80 attack techniques specifically targeting tool-based LLMs. OWASP lists prompt injection as the number one vulnerability in its LLM Top 10 for 2025. The attack surface that MCP creates is real, documented, and actively exploited.

Real-world incidents have already occurred. In mid-2025, a privileged Cursor agent processed support tickets containing user-supplied SQL instructions, leading to token exfiltration via a public support thread. The MCP community documented a supply chain attack in 2025 where compromised servers silently redirected outgoing email — over 13,000 MCP servers launched on GitHub in 2025 alone, and security review of community servers is inconsistent at best.

For A2A, security is handled at the HTTP transport layer rather than within the protocol’s JSON-RPC semantics. Production deployments must use HTTPS with TLS 1.3+. Agent Cards should be signed (experimental signed Agent Cards are in the A2A roadmap for 2026) to prevent spoofing. Authorization tokens should never appear in A2A message payloads — they belong in HTTP headers, where they can be managed by existing enterprise auth infrastructure.

Governance: From Anthropic to the Linux Foundation

The governance shift that happened in December 2025 is more important than it might appear to developers focused on protocol mechanics. On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. The co-founders were Anthropic, Block, and OpenAI. Platinum members: Google, Microsoft, AWS, Cloudflare, Bloomberg.

This is extraordinary. OpenAI, Google, and Anthropic — direct competitors in foundation models — jointly governing shared infrastructure. It almost never happens at this speed. The comparison to CNCF’s early days is apt: by April 2026, AAIF had grown to over 170 member organizations, more than double CNCF’s membership at a comparable stage.

What it means practically: MCP’s technical roadmap is now driven through community Spec Enhancement Proposals (SEPs) and working groups, not Anthropic’s internal engineering priorities. The lead maintainer, David Soria Parra, continues to guide technical direction — but with the governance structure of a foundation project rather than a product team. For enterprises planning multi-year AI infrastructure investments, this is the signal that MCP is safe to bet on. It is no longer a single vendor’s protocol. It is internet infrastructure.

Enterprise Adoption in Practice

The numbers from Gartner: 40% of enterprise applications will integrate AI agents by 2026. 75% of API gateway vendors and 50% of iPaaS vendors will have MCP features by end of 2026. Every major cloud platform has moved: Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud have all integrated A2A natively. AWS, Microsoft, and Google all support MCP through their developer platforms.

The adoption pattern that has emerged is consistent: organizations start with MCP to connect existing AI assistants to internal data and tools (CRM, Jira, internal wikis, Snowflake, HR systems, Slack, knowledge bases). Once MCP is established as the integration layer, they layer A2A on top for cross-system and cross-vendor agent coordination. The two-layer deployment pattern is now the documented enterprise default.

For teams building multi-agent workflows today, the practical guidance from the field: the write-once-use-everywhere promise of MCP is real. A Postgres MCP server built today works across Claude, Cursor, VS Code Copilot, and any other MCP-compatible client. Community feedback suggests 40–60% lower token usage in tool-heavy workflows compared to embedding tool schemas directly in context windows. The efficiency gains are not theoretical.

The 2026 Roadmap: What’s Coming

The official 2026 MCP roadmap, published by lead maintainer David Soria Parra in March 2026, focuses on five areas: transport scalability, agent communication, governance maturation, enterprise readiness, and richer agent-to-system interaction.

• Stateless transport (near-term): A new stateless transport proposed by Google eliminates session pinning, enabling MCP servers to run cleanly on Cloud Run, Kubernetes, and other horizontally-scaled infrastructure without sticky sessions.
• MCP Server Cards: Machine-readable capability advertisements at well-known URLs — the MCP equivalent of A2A’s Agent Cards. This moves MCP from configured to discoverable, transforming how agents find and connect to tools at scale.
• Better async task primitives: Unlocking agent-to-agent communication within MCP. An experimental version exists; client support is expanding rapidly. TypeScript SDK v2 and Python SDK v2 are actively in development.
• Enterprise identity (SSO integration): Moving from static API key secrets to SSO-integrated authentication. The 2026 roadmap prioritizes enterprise identity federation as a first-class capability.
• Triggers and streaming skills: Servers will be able to initiate interactions proactively (event-based triggers) rather than only responding to client requests. Streaming skills enable richer incremental output patterns.
• Composable tool execution: Progressive discovery and tool composition — agents discovering which tools are available incrementally rather than loading full manifests upfront, significantly improving performance for large server ecosystems.

For A2A, the 2026 trajectory points toward signed Agent Cards (cryptographic verification of agent identity), richer streaming patterns for long-running coordination, and deeper convergence with MCP’s discovery model. With IBM’s ACP merged into A2A in August 2025, there is no longer a competing agent-communication standard to worry about. The protocol landscape has consolidated faster than anyone predicted.

Who Should Build on What — a Decision Framework

The protocol landscape can feel daunting. Here is a direct framework for deciding what you need and when.

The most common mistake teams make is treating the protocols as alternatives. They are not. The question is never “MCP or A2A?” It is “at which layer does this specific problem live?” Once that is clear, the right protocol selection follows immediately.