04 Aug 2026 AI Engineering 6 min read

MCP and A2A — The Protocol Layer of the Agent Ecosystem

MCP's 2026-07-28 revision makes the protocol stateless and hardens OAuth; A2A 1.0 brings signed Agent Cards, multi-tenancy, and three protocol bindings. This article verifies the current state of both standards, explains how the agent-to-tool and agent-to-agent layers complement each other, outlines enterprise gateway patterns, and states precisely what the protocols do not solve: semantics and 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 answered with two protocols, not one. The Model Context Protocol (MCP, released by Anthropic in November 2024) standardizes agent-to-tool connections. The Agent2Agent Protocol (A2A, initiated by Google in April 2025) standardizes agent-to-agent communication. 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: if the remote capability is a deterministic function of its inputs, expose it as an MCP tool. Second: if the remote system reasons, holds its own state, and should not be micromanaged step by step, address it via A2A. Third: if both sides live in one runtime under one team, use neither — 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 this is not ceremony. Protocol integration is a multi-year investment, and the 2026-07-28 revision pairs neutral governance with a formal lifecycle policy: features move Active → Deprecated → Removed with a minimum twelve-month window, and a conformance suite gates changes. Predictable evolution, not any single feature, is what makes a protocol safe to build on.

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.

What comes next sits above: verifiable agent identity beyond signed cards, semantic contracts that make tool behavior checkable, content-trust mechanisms against injection, and eventually settlement — who pays whom for a delegated task. None of this is standardized today. For engineering teams the practical conclusion is stable since this year's releases: build on MCP and A2A at system boundaries, wrap them in a governance layer you control, and treat everything above the transport as your own responsibility.