04 Aug 2026 AI Engineering6 min read

MCP and A2A — The Protocol Layer of the Agent Ecosystem

The 2026-07-28 revision gives MCP a stateless core and hardened OAuth; A2A 1.0 adds signed Agent Cards, multi-tenancy, and three protocol bindings. We assess both standards, separate agent-to-tool from agent-to-agent communication, outline enterprise gateways, and identify the remaining boundary: protocols establish neither semantics nor trust in content.

Why Agent Ecosystems Need a Protocol Layer

An agent is a program in which a language model plans, invokes tools, and iterates on results. As soon as several teams — or several companies — ship agents, two integration problems appear that are commonly conflated. The first: how does an agent reach a tool, an API, a database, without a bespoke adapter for every pairing? The second: how does an agent delegate work to another agent it did not build and cannot inspect?

The industry has accordingly answered these two problems with two protocols rather than one. The Model Context Protocol (MCP, released by Anthropic in November 2024) standardizes connections between agents and tools. The Agent2Agent Protocol (A2A, initiated by Google in April 2025) instead governs communication between agents. Both now sit under Linux Foundation governance, and both reached inflection points in 2026: MCP with its largest revision to date, A2A with its first stable release.

An agent reaches its tools over MCP — one standard surface. 1/4

MCP After the 2026-07-28 Revision

The MCP revision of 2026-07-28 — the fifth spec release — makes the protocol core stateless. The initialize handshake and the Mcp-Session-Id header are removed; every request carries protocol version, client identity, and capabilities in its _meta field, so any request can land on any server instance behind an ordinary load balancer. A new server/discover call replaces the upfront capability exchange, and Multi Round-Trip Requests replace server-initiated streams for mid-call questions.

Two changes matter most for infrastructure teams. Streamable HTTP requests must now carry Mcp-Method and Mcp-Name headers, so gateways can route and rate-limit without parsing JSON bodies. Authorization, built on OAuth 2.1, was hardened: clients must validate the iss parameter per RFC 9207, and Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. Tasks and MCP Apps now ship as versioned extensions rather than core features.

The adoption numbers are verifiable. Anthropic reports over 400 million monthly SDK downloads as of July 2026, a fourfold increase within a year. The Linux Foundation counted more than 10,000 published MCP servers in December 2025; the official registry listed roughly 18,850 entries by July 2026 — with the caveat that an independent probe found 17.2% of advertised remote endpoints unreachable. Scale is real; curation is not automatic.

A2A 1.0 as the Agent-to-Agent Standard

A2A 1.0, released March 12, 2026, is the first stable version of the agent-to-agent standard. Its core object is the Agent Card: a JSON document describing an agent's identity, skills, and endpoints. Version 1.0 makes cards cryptographically verifiable — JSON Web Signatures (RFC 7515) over RFC 8785-canonicalized JSON — so a caller can establish who an agent is before delegating a task across organizational boundaries.

The interaction model is task-based: send or stream a message, then get, list, or cancel the resulting task; results arrive as messages and artifacts. Three protocol bindings are normative — JSON-RPC, gRPC, and HTTP+JSON — defined against a single a2a.proto source of truth with equivalence guarantees. Multi-tenancy lets one endpoint securely host many agents. Per the Linux Foundation, more than 150 organizations supported the standard by April 2026; the technical steering committee includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow.

How the Two Layers Complement Each Other

The two protocols do not compete; they operate at adjacent layers. MCP connects an agent to capabilities it controls: the tool executes a defined function and returns data. A2A connects an agent to peers it does not control: the remote agent plans, uses its own tools, and keeps its internal state opaque. In practice one service is often both — an MCP client toward its tools and an A2A server toward other agents.

Three decision rules cover most cases. First, expose a remote capability as an MCP tool if it is a deterministic function of its inputs. Second, use A2A if the remote system reasons independently, manages its own state, and should not be directed step by step. Third, use neither protocol when both sides run in the same runtime under one team's control — in-process framework constructs are cheaper than any wire protocol.

Dimension	MCP (2026-07-28)	A2A (1.0)
Connects	Agent to tools and data	Agent to peer agents
Unit of exchange	Tools, resources, prompts	Tasks, messages, artifacts
Discovery	Registry; server/discover call	Signed Agent Card (JWS, RFC 8785)
Bindings	JSON-RPC over Streamable HTTP; stdio	JSON-RPC, gRPC, HTTP+JSON
Authorization	OAuth 2.1, RFC 9207, CIMD	OAuth 2.0 flows, PKCE, mTLS
State model	Stateless core, explicit handles	Task lifecycle with task IDs
Governance	AAIF (Linux Foundation)	Linux Foundation, 8-company TSC

Neutral Governance under the Linux Foundation

In December 2025 Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. MCP joined goose and AGENTS.md as founding projects. A2A had already moved from Google to the Linux Foundation in 2025. No single vendor now controls the protocol its ecosystem depends on.

For enterprises, that governance is more than ceremony. Protocol integration is a multi-year investment, so the 2026-07-28 revision pairs neutral stewardship with a formal lifecycle policy. Features move Active → Deprecated → Removed with a minimum twelve-month transition, while a conformance suite gates changes. A protocol becomes safe to build on through predictable evolution, not through any single feature.

Gateway Patterns for Enterprise Governance

Neither protocol defines role-based access control, audit trails, or cost limits. That is a deliberate scoping decision, and the ecosystem fills it with a gateway pattern: a control plane between agents and servers. The gateway enforces filtered discovery — an agent sees only the tools its identity permits — brokers tokens so raw credentials never reach the agent, logs every call with user identity and arguments, and applies rate limits per agent and per tool.

The stateless MCP core makes this layer cheaper to operate: Mcp-Method and Mcp-Name headers allow routing and policy at the HTTP layer, and cacheable list responses (ttlMs, cacheScope) remove the need for long-lived streams. Registries federate across business units and public sources; AWS's open-source MCP Gateway and Registry (Apache 2.0) is one reference implementation. For A2A the same pattern applies at the organization boundary, with signed Agent Cards verified before any task is delegated.

What the Protocols Deliberately Leave Open

Both protocols transport structure, not meaning. MCP delivers a tool's JSON schema and behavior annotations such as read-only or destructive hints — but the specification explicitly marks these as untrusted hints, and nothing in the protocol verifies that a description matches what the tool actually does. Schema quality remains an engineering responsibility of the server author, and it directly determines how reliably agents route calls.

Nor do the protocols establish trust in content. A signed Agent Card authenticates identity, not honesty. Tool poisoning — malicious instructions embedded in tool metadata or responses — is an indirect prompt injection that no transport can prevent: the MCPTox benchmark, built on 45 live MCP servers, observed attack success rates of up to 72.8% for some agents. Provenance tracking, content filtering, and least-privilege isolation must be built above the protocol layer.

The honest converse also holds: not every system needs these protocols. A multi-agent design that lives inside one runtime — one process, one team, one deployment — is better served by framework-internal constructs than by A2A endpoints. And a fixed set of three internal APIs does not justify a registry and a gateway. Protocols pay off at boundaries; inside a boundary they add latency and attack surface.

Outlook: The Protocol Layer Becomes Infrastructure

The direction is visible in the specifications themselves. Both protocols converged on the architecture of the web: stateless requests, standard headers, cacheable responses, gateway-friendly routing. That convergence is what lets thirty years of HTTP operations knowledge — load balancing, WAFs, observability — apply unchanged to agent traffic. We read the 2026 releases as the protocol layer declaring its transport questions solved.

The next open problems sit one layer higher: verifiable agent identity beyond signed cards, semantic contracts for checkable tool behavior, content-trust mechanisms against injection, and eventually settlement — who pays for a delegated task. None of this is standardized today. The engineering rule is therefore clear: use MCP and A2A at system boundaries, surround them with a governance layer you control, and continue to treat everything above transport as your responsibility.