MCP and A2A in Production: The Complete Guide

What MCP Actually Specifies

The Model Context Protocol defines three primitives. Tools are functions the model can call. Resources are data that supply context to the model without being part of the conversation itself. Prompts are reusable workflow templates. Under the hood, these are exchanged as JSON-RPC 2.0 messages over HTTP or a local connection — servers expose capabilities, and the agent, acting as a client, invokes them.

In production, MCP shows up in three recurring patterns:

• Developer tooling: an agent pulls logs from Grafana or Datadog in one place instead of an engineer tabbing between dashboards
• Knowledge-worker copilots: a chat assistant reaches into Salesforce and meeting notes through the same tool-calling interface
• Self-serve analytics: non-technical teams query data warehouses in plain English, with MCP mediating the actual query execution

The Governance Gap

MCP standardizes the connection between an agent and a tool. It does not specify how that tool authenticates the caller, what the agent is allowed to do once connected, or how the interaction gets logged. That's a real, practical gap — not a theoretical one. Enterprises deploying MCP at scale have split into two camps: those building access control, audit logging, and middleware now because they can't wait for the ecosystem to mature, and those holding sensitive workloads back until it does.

If you're in the first camp, the governance layer isn't optional scaffolding — it's the actual production requirement. See AI Agent Governance and Audit Trails for the audit trail schema, least-privilege access pattern, and approval-gate decision rule to build on top of an MCP deployment.

What Changed With the Stateless Architecture

MCP moved to the Agentic AI Foundation under the Linux Foundation in December 2025, with Anthropic as the original donor and OpenAI and Block joining as co-founders, alongside AWS, Google, Microsoft, Cloudflare, GitHub, and Bloomberg as supporting members — putting governance of the spec itself in vendor-neutral hands rather than any single company's roadmap.

The July 2026 spec release moved MCP toward a stateless architecture. Practically, that matters for scaling: an MCP server that doesn't need to hold session state between requests can be load-balanced and scaled horizontally the way a standard stateless API can, instead of requiring sticky sessions or shared session storage across server instances. For a team running MCP servers behind more than a handful of concurrent agents, that's the difference between straightforward horizontal scaling and a session-affinity problem you have to solve yourself.

What A2A Actually Specifies

Agent-to-Agent (A2A) solves a different problem: communication between independent agents that don't share internal tools, memory, or a codebase. Where MCP is hierarchical — an agent calls a passive server — A2A is peer-to-peer.

Agents publish what they can do via an Agent Card, a JSON document at a well-known URL (/.well-known/agent.json) describing their capabilities and how to reach them. Work is exchanged through a Task with a defined lifecycle: submitted → working → input-required → completed, cancelled, or failed. That lifecycle is what makes A2A suitable for long-running work — hours or days — including human-in-the-loop pauses, without either side exposing its internal tools or memory to the other.

A concrete illustration: a customer-facing agent talks to a repair shop's manager agent over A2A. The manager agent runs a diagnostic conversation with a mechanic agent, also over A2A. The mechanic agent then invokes its own diagnostic tools — internally, over MCP. Two protocols, two different layers, working together in the same system.

When You're Already Committed to A2A: What to Actually Build

If you've decided you're crossing a real trust boundary — a partner's agent, a vendor's system, another team's service you don't control — the implementation work is: publish an accurate Agent Card that reflects what you'll actually honor, implement the full Task lifecycle including cancellation and failure states (not just the happy path), and decide up front what state you're willing to expose in a Task versus what stays internal. Most of the actual engineering effort in an A2A integration is in that last decision — drawing the line between what the other side needs to know to collaborate and what your system keeps private.

For the underlying question of whether you need A2A at all, see MCP vs A2A — most systems labeled "multi-agent" today are one team's orchestrator calling tools in sequence, not independent agents actually crossing a boundary, and don't need A2A at all.

Current Ecosystem State

MCP: reported third-party figures put monthly SDK downloads at roughly 97 million by March 2026, with a July 2026 survey reporting 78% of enterprise AI teams running MCP-backed agents in production — both figures are third-party-reported, not independently verified here, but directionally consistent with MCP now being the default tool-calling layer across OpenAI, Google, Microsoft, IBM, and Amazon's agent products.

A2A: at its one-year anniversary in April 2026, the Linux Foundation reported 150+ supporting organizations, 22,000+ stars on the core repository, and SDKs shipping in five languages — Python, JavaScript, Java, Go, and .NET. Real cross-organization agent traffic in production remains comparatively rare relative to the number of organizations supporting the standard; adoption of the tooling has outpaced adoption of the pattern it enables.