MCP vs. x402: How AI Agents Discover Tools and Pay for Services

MCP and x402 solve two different problems in an AI agent transaction. MCP lets a model discover and call tools, read resources, and receive structured results. x402 lets a service state a price, accept a payment authorization, and return a settlement result. MCP is not a payment protocol, and x402 does not define how a model selects and calls tools. An agent that needs paid capabilities will usually combine them.

The shortest useful distinction is this: MCP answers “what can this agent call, and how?” x402 answers “what does this call cost, and how is it paid?”

What is the difference between MCP and x402?

Dimension	MCP	x402
Core problem	Connecting models to external tools, resources, and workflows	Paying for access to a protected service or resource
Main objects	Tools, resources, prompts, input schemas, and results	Payment requirements, payment payloads, and settlement responses
Typical participants	MCP host, client, and server	Payment client, resource server, and optional facilitator
Defines a price	No	Yes, through payment requirements from the seller
Moves value	No	It can, according to the selected payment scheme
Defines wallet policy	No	The core protocol does not define an organization's budgets, allowlists, or approval rules
Works independently	Yes. Most tools do not require payment	Yes. Ordinary HTTP clients can use x402
Common combination	Call a tool that checks or performs an x402 payment	Protect an MCP tool or the HTTP service behind it

These are not competing protocols. They operate at different layers, and their boundaries can overlap. x402 can protect an ordinary HTTP endpoint or integrate with an MCP tool. An MCP tool can call a free internal system, a service authenticated with an API key, or an external resource that requires an x402 payment.

What does MCP actually do?

MCP provides a common interface between model applications and external capabilities. An MCP server can expose tools and resources. The host decides which capabilities to make available to the model and coordinates calls between the user, model, and server.

For tools, the official MCP tools specification defines two essential operations:

A client uses tools/list to receive tool names, descriptions, and input schemas.
A client uses tools/call to submit a tool name and arguments and receive text, structured content, or resource links.

That solves the interoperability problem of describing and invoking a capability. A weather query, database lookup, file operation, and Payment Order search can all become tools a model understands.

Discovering a tool does not mean the model should be allowed to invoke it without controls. The MCP specification describes tools as model-controlled while recommending that applications preserve a human's ability to deny calls. It also requires clients to treat tool annotations as untrusted unless they come from a trusted server. The protocol defines the call shape. It does not automatically decide your organization's authorization boundary.

MCP discovery also has a specific scope. tools/list tells a client what a connected MCP server exposes. It is not, by itself, a search engine for every purchasable service on the internet. A public marketplace, a private service catalog, or the x402 Bazaar extension can provide broader service discovery before a candidate capability enters an MCP workflow.

What does x402 actually do?

x402 puts payment negotiation into a request and response flow. In its common HTTP form, a client requests a protected resource and receives 402 Payment Required with the amount, asset, network, and destination. The client constructs and signs a payment payload, then retries the resource request with proof of payment.

The official x402 documentation describes three standard headers in the v2 HTTP flow:

Header	Direction	Purpose
`PAYMENT-REQUIRED`	Resource server to client	Returns the acceptable payment options
`PAYMENT-SIGNATURE`	Client to resource server	Carries the signed payment payload
`PAYMENT-RESPONSE`	Resource server to client	Reports settlement success, failure, or related transaction data

The resource server may verify and settle locally or delegate those operations to a facilitator. x402 connects payment requirements and settlement to resource access. It does not decide whether a particular organization wants its agent to buy that resource.

A payment requirement is therefore not the same thing as payment authorization. A seller can say, “this call costs 0.10 USDC.” The buyer must still decide whether the origin is trusted, the recipient is allowed, the network and asset are correct, the amount is within policy, and the task requires human approval.

How can MCP and x402 work together?

Three architectures appear frequently in practice.

Architecture 1: An MCP tool calls a paid HTTP API

An MCP server exposes a tool to the agent. During execution, the tool requests an external HTTP endpoint. If the endpoint returns an x402 requirement, the bridge checks it, signs a payment, retries the request, and converts the paid response into an MCP tool result.

Agent
  -> MCP tool call
  -> MCP server requests external API
  -> 402 / PAYMENT-REQUIRED
  -> check and sign payment payload
  -> retry with PAYMENT-SIGNATURE
  -> receive paid resource
  -> MCP tool result

The x402 project documents this MCP and x402 integration. It is useful when an existing paid HTTP service needs to become a model-callable tool.

Architecture 2: Charge directly for an MCP tool

A provider can also make the MCP tool itself the paid resource. The caller still discovers and invokes the tool through MCP, but completes an x402 payment before receiving the result. MCP describes the capability. x402 describes the payment required to use it.

This pattern fits providers that already deliver data, compute, or generated content through MCP. The seller must ensure that an unpaid probe does not execute an irreversible protected operation. Retries of the same paid tool call also need business-level idempotency.

Architecture 3: Use separate payment-control tools to call x402 services

A third pattern keeps business tools and payment control separate. The agent discovers a candidate service, then calls dedicated payment tools for preview, approval, signing, purchase, and recovery. Wallet authority, budgets, and payment recovery do not have to be reimplemented inside every business MCP server.

StableOps Agent Payments uses this boundary. It exposes payment operations as constrained MCP tools while private keys remain in a customer-controlled signer. The control plane applies policy and budgets, and the agent cannot bypass approval by changing tool arguments.

How does StableOps connect MCP and x402?

StableOps provides two MCP servers for different sides of a transaction:

Server	User	Primary purpose	What it cannot do
`@stableops/mcp-server`	Merchant or operations agent	Query or manage Payment Orders, receiving addresses, webhooks, checkout, and subscriptions	Hold wallet keys or initiate an onchain transfer
`@stableops/agent-payments-mcp-server`	Buyer-side payment agent	Configure payment controls, discover and preview x402 services, buy within policy, and inspect payments	Self-approve exceptions or obtain arbitrary signing authority

The first server lets a merchant agent operate StableOps resources under policy. See the StableOps MCP Server. The second lets an agent purchase paid resources for a buyer. See the Agent Payments quickstart. Both use MCP, but they sit on opposite sides of the transaction.

A controlled x402 purchase follows this path:

User supplies a task
  -> agent discovers a candidate service through MCP
  -> preview the exact URL, method, body, and live payment requirement
  -> StableOps checks origin, recipient, network, asset, amount, and budgets
  -> automatically allow or pause for human approval
  -> StableOps issues a short-lived, single-use execution grant
  -> customer-controlled signer verifies every field and signs the payment
  -> MCP runtime retries the original request with PAYMENT-SIGNATURE
  -> resource server verifies and settles, returning the resource and PAYMENT-RESPONSE
  -> agent receives a structured result and payment record

MCP exposes tools such as stableops_preview_x402_purchase, stableops_x402_fetch, and payment lookup to the agent. x402 negotiates payment with the remote resource. StableOps policy, budgets, approval, and signer determine whether the purchase has business authorization.

If a payment requires approval, the agent preserves the original intent_id and resumes that purchase after approval. If settlement is unknown, it queries the original payment instead of creating a replacement. The x402 payment walkthrough covers the complete flow.

Why is MCP permission different from payment permission?

Making a tool available to a model says that the tool is part of its capability set. It does not answer these financial questions:

How much can this agent spend per day?
Which origins and recipients may be paid automatically?
Does an old approval remain valid after the quote changes?
Does the exact body of a POST request match what was reviewed?
Can a timeout after signing be retried safely?
Who holds the private key, and what is the signer allowed to sign?

Likewise, a successful x402 payment does not make an MCP tool result trustworthy. The remote response is still external data. It should not gain a higher trust level merely because the caller paid for it. Hosts and agents must continue treating it as untrusted input to prevent prompt injection, unauthorized tool calls, and sensitive-data exfiltration.

A production system should separate at least five control boundaries:

Control boundary	Question it must answer
Tool visibility	Which MCP tools can the agent see and invoke?
Business authorization	Does the current task permit this service call?
Payment authorization	Do the origin, recipient, network, asset, and amount satisfy policy?
Signing authorization	Does the exact payload match a short-lived execution grant field by field?
Result handling	How are the tool result and settlement state validated, recorded, and recovered?

A budget alone remains insufficient. It limits aggregate quantity but cannot express purchase purpose, recipient, or request content. Read A Budget Is Not a Payment Policy for AI Agents for the complete authorization model.

Should you use MCP, x402, or both?

Choose based on the outcome:

Goal	Recommendation
Let an agent query a database, operate an internal system, or call a free tool	Use MCP
Let an ordinary application pay per call for an HTTP endpoint	Use x402
Let an agent call an existing x402-paid HTTP API	Use MCP and x402 together
Charge per call for an MCP tool	Use MCP to describe the tool and x402 to add payment
Let an agent pay autonomously in production	Add policy, budgets, approval, restricted credentials, and customer-controlled signing beyond MCP and x402

Do not design the system from protocol names alone. First identify what is being called, where payment happens, who can approve it, and how the system recovers after a timeout. Then choose the protocol combination.

Production checklist

For the buyer-side agent

Give the runtime a restricted credential belonging only to that agent, never the organization management key.
Before payment, bind the exact origin, URL, method, request-body digest, recipient, network, asset, and amount.
Apply a per-payment limit, an agent budget, and an organization budget together.
Route unknown origins, unknown recipients, and charges above the automatic threshold to human approval.
Expose payment-specific signing only and require a short-lived, single-use, field-bound execution grant.
Reuse one stable idempotency key for every retry of the same purchase.
When settlement is unknown, query the original payment instead of authorizing a second one.

For the paid service

Make the tool name, description, input schema, and price refer to one clear capability.
Do not perform the protected irreversible operation before payment verification.
Keep probes, refreshed payment requirements, and paid retries safe through business idempotency.
Return the network, asset, amount, recipient, and validity window unambiguously.
Reconcile protocol settlement, resource delivery, and internal accounting as distinct states.
Define recovery for failures, timeouts, duplicate submissions, and unknown settlement.

Frequently asked questions

Can x402 replace MCP?

No. x402 can charge for a resource or tool, but it does not replace MCP's definitions for tool names, input schemas, invocation, and result formats. An ordinary application can use only x402, and a free agent tool can use only MCP.

Can MCP call a paid API?

Yes. An MCP tool can call an external service funded by a subscription, API key, prepaid balance, or x402 payment. MCP does not constrain the commercial model. It standardizes how the capability is exposed and invoked.

Can an MCP tool itself charge through x402?

Yes. The official x402 integration demonstrates both paid MCP tools and MCP tools that access paid HTTP services. In production, either pattern still needs amount, asset, network, and recipient checks before signing.

Does MCP include a wallet, budgets, and payment approval?

No. MCP provides tool invocation and an authorization framework, but it does not define an organization's financial policy. Wallet isolation, budgets, allowlists, approval, and payment recovery belong to the implementation.

Does x402 always require a facilitator?

No. A resource server can verify and settle locally or delegate those operations to a facilitator. The choice depends on the network, payment scheme, and infrastructure the team wants to operate.

How can an agent find x402 services to buy?

Candidates can come from provider documentation, discovery mechanisms such as x402 Bazaar, or the StableOps x402 service directory. Discovery only produces candidates. The buyer must still fetch the live requirement and apply policy before payment.

Start with one controlled call

For the first MCP and x402 integration, choose a low-cost endpoint whose result is easy to verify and has no external side effect. Let the agent discover and preview it, have a human review the origin, recipient, network, asset, and amount, then resume the same purchase. Expand automatic payment only after idempotency, approval, and unknown-settlement recovery behave as expected.

Use the Agent Payments quickstart to configure a sandbox payment path, then complete the x402 payment walkthrough. MCP makes a capability available to an agent. x402 makes that capability payable per call. Policy and constrained signing determine whether the combination is ready for production.

Related articles