// Last updated 2026-04-27

Agent protocols — MCP, A2A, x402, AP2, and ERC-8004 explained

A useful autonomous agent needs to call tools, talk to other agents, pay and be paid, and prove who it is. Five open protocols cover those gaps: MCP handles tool access, A2A handles peer coordination, x402 and AP2 each handle a layer of payments, and ERC-8004 handles identity and reputation. They don’t compete — each is doing a job the others mostly don’t touch.

This page describes each protocol on its own terms. ERC-8004 is maintained by this team, but that’s not a reason to give it more coverage — the write-ups have to be fair across the board to be useful.

The problem each protocol solves

Without shared protocols, an agent is like a computer with no network stack — fully capable of running local code, unable to do much with the outside world.

Tools. An agent needs to read files, call APIs, query databases. Without a shared interface, every tool is a custom integration. MCP standardizes the contract between agent and tool so a single client can talk to any conforming server.

Peer coordination. Agents working on complex tasks often need to find other agents and delegate sub-problems. A2A defines the discovery and handshake protocol so agents can locate each other and negotiate a job without bespoke glue.

Payments. An agent calling a paid API can’t fill in a checkout form. x402 and AP2 handle the machine-readable side of that — how an HTTP server signals “pay before I return data,” and how an agent programmatically satisfies that requirement.

Identity. An agent calling another agent, or a human evaluating whether to trust one, needs a stable verifiable record. ERC-8004 puts that record onchain so anyone can read it without asking the platform that hosts the agent.

MCP — Model Context Protocol

Anthropic published the Model Context Protocol spec in late 2024 to address a real problem: every tool had a different integration API, which meant tool authors and agent authors were both writing a lot of custom glue code.

MCP defines a uniform interface between an MCP client (the agent, or the model environment it runs in) and an MCP server (a tool, data source, or service). Servers expose three capability types: resources (readable context, like files or database rows), prompts (pre-written prompt templates), and tools (callable functions with defined input/output schemas). The client discovers what a server offers and calls into it using the shared wire format.

MCP doesn’t touch the LLM itself, the agent’s reasoning, or payments. An MCP server has no concept of who is calling or whether the caller has paid. That’s intentional — MCP solves one problem and leaves the rest to other layers.

As of early 2026, MCP has the widest adoption of the five protocols covered here. Most major model providers ship an MCP client, and a growing catalog of servers covers common categories: filesystem, web search, code execution, databases, and external APIs.

Concretely: an agent that needs to read a document before deciding what to do issues a resources/read request through its MCP client to an MCP filesystem server. The server returns the document content in the standard format. The agent never needed to know which filesystem library the server was built on.

Spec: https://modelcontextprotocol.io/

A2A — Agent2Agent

MCP handles agent-to-tool communication. Google’s Agent2Agent (A2A) protocol handles the other side: agent-to-agent communication.

The central primitive is the agent card — a JSON document published at a well-known URL for each agent. The card describes the agent’s name, capabilities, supported tasks, and the endpoint to call. An agent looking for a counterpart fetches the card, checks whether capabilities match, and submits a task using the A2A protocol. Task state runs through a defined lifecycle: submitted, working, completed, failed.

The two protocols are designed to coexist. An agent might use MCP to fetch data from tools, then A2A to hand part of the problem to a peer. They don’t conflict; they operate at different points in the call graph.

As of early 2026, A2A has gained traction in enterprise multi-agent scenarios, though production deployment is narrower than MCP’s broader developer-ecosystem reach.

A worked case: a research agent finishes an English summary and needs a translation. It pulls the agent card from a known translation service, confirms translation is in the listed capabilities, and submits a task via A2A. The translation agent returns the result through the task-completion flow.

Spec: https://github.com/google/A2A

x402

x402 is a payment protocol for HTTP APIs, originated by Coinbase. The design reuses an existing HTTP status code — 402 Payment Required — that has been reserved since 1999 but was never standardized. x402 gives it a concrete definition for programmatic agent payments.

The flow has four steps: the API server returns a 402 response with a machine-readable payment specification (amount, token, network, recipient); the client executes the payment on the specified chain; the client retries the original request with a X-Payment header carrying proof of payment; the server verifies and returns a 200. The whole exchange happens without human intervention.

x402 does not dictate which chain or token to use. The 402 response body specifies the payment requirements; the client picks a supported option. In practice, the Coinbase reference implementation focuses on USDC on Base, but the protocol itself is payment-rail-agnostic.

The protocol handles micropayments well. A single API call that costs a fraction of a cent doesn’t work with traditional invoicing; x402 makes per-call billing practical.

As of early 2026, x402 has a working reference implementation and production usage in payment-focused agents.

In practice, an agent calling a paid data API receives 402 with a body specifying 0.01 USDC on Base. The agent signs a transaction, gets a receipt, and retries the request with the receipt in the header. The server verifies onchain and returns the data.

Spec / reference implementation: https://github.com/coinbase/x402

AP2 — Agent Payments Protocol

AP2 (Agent Payments Protocol) covers a broader slice of agent payments than x402. Where x402 specifies a single payment handshake at the HTTP level, AP2 defines the higher-level conceptual layer: payment intents (a declared budget and purpose), mandates (a pre-authorized recurring agreement), and settlement (how individual payments close against those intents).

The relationship between the two is layered rather than competing. An AP2-enabled agent can use x402 as the transport for individual payments while managing the overall budget and authorization through AP2’s intent/mandate primitives. Not all AP2 implementations require x402 — other settlement transports are possible — but the protocols compose cleanly when both are present.

As of early 2026, AP2 is in active development and less deployed than x402, which is narrower and easier to adopt standalone. AP2’s main use case is multi-step workflows where an agent needs to pre-authorize a budget rather than seek approval for each payment.

Picture an agent running a research workflow across five paid data services. It declares a single AP2 payment intent covering the expected total. Each per-service payment draws against that mandate. The hiring agent audits one settlement record instead of five separate flows.

Spec (in development; canonical URL unconfirmed): https://github.com/google/ap2

ERC-8004

The odd one out in this list is ERC-8004 — it doesn’t handle tool calls, agent discovery, or payments. What it handles is the question every other layer eventually needs answered: who is this agent, and is it worth trusting?

ERC-8004 is an Ethereum Improvement Proposal that defines three onchain registries for agent identity and reputation. The full spec is at https://eips.ethereum.org/EIPS/eip-8004; a deeper explanation lives at What is ERC-8004?.

The three registries:

• Identity Registry — mints an ERC-721 token per agent, whose tokenURI resolves to metadata (name, description, endpoints). Durable as long as the chain runs. Read more: Identity Registry.
• Reputation Registry — stores signed client feedback. Each record is tied to a real Ethereum address via signature; records are revocable but the revocation itself is part of the reliability signal. Read more: Reputation Registry.
• Validation Registry — records request/response pairs from independent validators who score an agent on a specific dimension (0–100). Read more: Validation Registry.

Together they let any reader answer two questions — who is this agent? and what do third parties say about it? — without trusting any single aggregator.

ERC-8004 was finalized as an EIP in early 2026. The registries are deployable on any EVM-compatible chain; the reference deployment is live on Ethereum mainnet and several L2s.

A typical lifecycle: an agent mints an ERC-8004 token pointing to its metadata. Clients post signed feedback after each interaction. A validator runs the agent through a test suite and submits a score. A prospective client checks the reputation record before deciding to use it — without asking the operator for references.

How they compose

Suppose an agent is hired to produce a translated summary of a paywalled academic article:

Identity. The agent has an ERC-8004 token in the Identity Registry. Its tokenURI points to metadata listing its capabilities: document summarization, source citation. The client verified this before hiring the agent.

Tool access. The agent uses MCP to call a summarization service. The MCP server exposes a tools/call interface; the agent submits the article URL and gets back a structured summary without knowing the server’s internal implementation.

Payment. The summarization API is paywalled. The server returns a 402 response specifying 0.05 USDC on Base. The agent pays via x402, retries with the payment header, and receives the summary. If this agent is part of a larger workflow with a pre-authorized budget, AP2 manages the mandate — the x402 payment draws against it rather than requiring fresh authorization.

Peer coordination. The agent needs the summary in French. It fetches the agent card for a translation service, confirms the card advertises translation support, and submits the task via A2A. The translation agent returns the completed text through A2A’s task lifecycle.

Reputation. After the workflow completes, the hiring client posts a signed ERC-8004 feedback event rating the agent’s quality. An independent validator who runs systematic checks adds a scored validation record. The agent’s onchain reputation grows, visible to any future client.

Each protocol focuses on a distinct job. The overlaps that exist are at the edges, not the core — the next section covers them.

What’s still missing or overlapping

The stack has real overlap at the edges, and a few gaps worth naming.

x402 and AP2 overlap at the edges. Both can appear in the same payment flow; AP2’s higher-level intent layer wraps x402-style per-call settlement. For simple use cases, x402 alone is sufficient and AP2 adds complexity without benefit. The line between “use x402” and “use AP2 with x402 underneath” is a function of workflow complexity, not a clear protocol boundary.

MCP and A2A can describe the same thing differently. An agent that acts as a service for other agents can be modeled as either an MCP server (tool interface) or an A2A peer (agent card + task protocol). Both descriptions can be accurate. The practical distinction is the audience: MCP is more natural when the caller is an LLM agent consuming a capability; A2A is more natural when the caller is another agent doing peer negotiation.

Notable gaps. There’s no widely-adopted standard for an agent’s persistent memory across sessions — each platform handles this privately. Delegated authority is similarly unresolved: an agent acting under an AP2 mandate has no guaranteed way to prove that delegation to an MCP server or an A2A peer.

These aren’t permanent gaps — the stack is young and the boundaries will keep shifting. What’s described here is the state as of early 2026.

Further reading

Primary sources for each protocol:

• MCP — https://modelcontextprotocol.io/
• A2A — https://github.com/google/A2A
• x402 — https://github.com/coinbase/x402
• AP2 — https://github.com/google/ap2 (in active development; check for canonical site updates)
• ERC-8004 — https://eips.ethereum.org/EIPS/eip-8004

On this site:

• Onchain agents — what an onchain agent is and why the blockchain layer matters
• What is ERC-8004? — the cornerstone explainer for identity and reputation