What is the difference between MCP, A2A, AP2 and x402?
MCP connects an AI application to tools and information. A2A lets separate agents communicate about work. AP2 supplies verifiable authorization for agent purchases and payments. x402 provides a way to request payment for an HTTP resource. They address different questions, so choosing one is not necessarily rejecting the others.
A protocol is an agreed format and set of rules for communication. It is not an AI model, a finished shopping app or a guarantee that two services can work together. This guide helps you identify the missing capability in an application before adding another integration. You do not need all four to build a useful assistant.
When would I use MCP rather than A2A?
Model Context Protocol, or MCP, standardizes connections to external tools and resources. For example, a writing assistant might read an approved product catalogue through an MCP server. The application still decides which tools are available and what the user may authorize. Connecting a server does not make everything it returns trustworthy.
Agent2Agent, or A2A, concerns communication between separate agents. Imagine a research assistant handing a defined task to another organization’s specialist agent and receiving progress and results. The other agent can manage its own tools internally. A2A can connect the agents while MCP connects either agent to its tools.
Ask what sits on the other side of the connection: a specific function or dataset, or an independent agent handling a task? This distinction is more useful than a claim that one standard replaces the other. A simple form that calls one database may need neither.
What does AP2 authorize, and what changed after its launch?
Agent Payments Protocol, or AP2, distinguishes checkout authorization from payment authorization. Its v0.2 specification uses linked Checkout and Payment Mandates and receipts. Validation belongs in deterministic code; an AI response saying “approved” is not the required verification.
The current documentation describes open mandates that express constraints and closed mandates for a particular transaction. A person can approve a specific purchase directly, or authorize bounded autonomous execution. Those bounds must be checked by the responsible participants; they do not enforce themselves.
Google announced AP2 v0.2 and its donation to the FIDO Alliance on April 28, 2026. When following a tutorial, check its version: terminology from the September 2025 launch can differ from the current specification. An announcement about a protocol is not evidence that every merchant or wallet supports it.
AP2 does not define every catalogue API or settle a dispute automatically. The v0.2 specification also leaves delegation of mandates between shopping agents outside its scope. A2A communication therefore does not, by itself, transfer spending authority.
Where does x402 fit into a paid API request?
An x402 resource server can respond with HTTP 402 and payment requirements. A compatible client supplies payment information; the server verifies it, handles settlement according to the selected scheme and returns the resource. A facilitator can help with verification and settlement. The precise flow depends on the version, network and scheme.
That mechanism answers a payment-for-access question. It does not establish that an agent’s owner approved this purchase or that the purchased information is accurate. A statement that the protocol has no protocol fee also does not erase possible network, service or facilitator costs. Check the actual provider’s terms.
If you only want to understand HTTP 402 and wallet payment, start with our x402 introduction. If you are implementing a service, use the integration guide for request handling and testing. This comparison focuses on which responsibility each protocol addresses.
Worked example: a research assistant buying a small dataset
Consider a fictional assistant preparing a product report. It reads a permitted internal catalogue through MCP. If a separate specialist agent is useful, it can exchange a research task through A2A. Neither action should grant permission to buy anything.
For a paid dataset, the application must separately obtain and enforce the owner’s purchase authority. An AP2-compatible checkout could represent that authorization; a compatible x402 endpoint could handle payment for a resource. This is a design illustration, not a claim that arbitrary AP2 and x402 implementations plug together without integration.
Give the application an illustrative total budget of $0.30 and a provider allowlist. Three different requests at $0.08 each cost $0.24 before additional fees; a fourth would cost $0.32 and exceed the cap. If fees apply, include them in the same total before authorizing. Do not round away small charges or treat an unknown final cost as zero.
For concurrent requests, reserve budget before dispatch so several workers cannot all spend the same remaining amount. After a timeout, check payment and delivery records before retrying. Budget accounting and duplicate-request handling need application logic even when the communication protocol is standardized.
Five-minute exercise: choose the smallest useful integration
Write down one task your assistant must perform, then label each boundary. For “read our catalogue and draft a comparison,” start with read access and output checks. Add another agent only if it performs a distinct needed task. Add payment machinery only if the workflow actually purchases something.
For the fictional $0.30 budget, mark these tests before running anything with money: three $0.08 requests without fees pass; four fail; an unapproved provider fails; and a request whose full cost is unknown pauses for a decision. A failed delivery after a successful payment must enter reconciliation instead of a blind second purchase.
- Connection: identify the tool, agent or paid resource and the exact supported protocol version.
- Authority: name who approved the operation, its limits, expiry and allowed provider.
- Execution: test insufficient budget, expired authorization, timeouts and repeated requests.
- Evidence: keep request, authorization, payment and delivery identifiers without exposing credentials.
What should a beginner build first?
Start with one read-only task using sample data and a clear expected answer. Introduce paid access only after you can explain where consent is captured, where limits are checked and how you determine whether the result arrived. A wallet balance is not a spending policy, and a successful request is not proof of a correct answer.
Then use the AI answer-checking guide to verify the report itself. If an assistant reads outside documents or can take actions, review prompt-injection and permission boundaries as a separate concern.
Sources & further reading
- MCP: connect AI applications to tools and data
- A2A: how agent communication differs from MCP
- AP2 v0.2 specification: mandates, roles and verification
- AP2: open and closed checkout/payment mandates
- Google: April 28, 2026 AP2 v0.2 and FIDO Alliance announcement
- x402: HTTP payment flow and supported schemes
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.