What currencies can MCP servers accept with x402?

Does MCP define a currency?

No. MCP defines how hosts, clients and servers exchange context and invoke tools. A tool can be free, funded by an existing subscription, protected by OAuth, metered internally or placed behind an x402 payment wrapper. The payment implementation belongs to the HTTP resource and its surrounding application, not to the MCP specification.

This distinction matters for search and documentation. Saying that an MCP server 'accepts USDC' is shorthand for a deployed payment path that quotes and settles USDC before executing a tool. Buyers still need the exact network, asset identifier, scheme and destination. A ticker symbol alone is not enough because similarly named assets can exist on different networks or contracts.

What does x402 support today?

The current x402 network documentation describes fungible-token payments across EVM networks, Solana, TON, Algorand, Stellar, Aptos and Hedera. EVM support can use compatible ERC-20 assets through EIP-3009 or Permit2; other ecosystems use their native fungible-token standards. The protocol uses CAIP-2 network identifiers so a requirement names the network unambiguously.

Protocol support is broader than any one hosted facilitator. A facilitator may serve only selected networks, environments or schemes, and production support can differ from the public test facilitator. Sellers must confirm the option end to end rather than copying the protocol's full network list into product copy. Buyers should accept only networks and asset contracts their signer explicitly recognizes.

Why is USDC common in paid agent tools?

A stable-value asset makes small per-call prices easier to understand and budget than a volatile token amount. The official buyer and MCP examples commonly start with wallets funded in USDC, and many directory listings advertise USDC on Base, Solana or both. That convention supports familiar dollar-like prices while retaining programmatic wallet authorization and onchain settlement.

Common does not mean mandatory or identical everywhere. USDC contracts, mint addresses and decimal precision differ by network. A seller should use an explicit asset definition and a buyer should verify it against an allowlist. Display copy can say '$0.01' for readability, but logs and payment policy need the atomic amount and exact asset that the signed requirement authorizes.

A currency choice is really four choices

The visible asset is only one part of an accepted payment option. The network determines where the asset lives, the scheme determines how the client authorizes and the server settles, and the facilitator determines which combinations can be verified and settled in that deployment. If any one component is unsupported, the option is not usable even when both parties recognize the token symbol.

Document the tuple together: scheme, network, asset and maximum or exact amount. Also publish the receiving destination and whether settlement is immediate or batched. Buyers can then compare the requirement with their signer capabilities and spending policy without interpreting marketing phrases such as 'multi-chain' or 'stablecoin enabled.'

• Asset: the token contract, mint or fungible-asset identifier.
• Network: the exact CAIP-2 namespace and reference.
• Scheme: exact, upto, batch-settlement or another supported mechanism.
• Facilitator: the service or local implementation that can verify and settle that combination.

Can one MCP tool accept more than one network or token?

Yes. An x402 resource can advertise multiple payment requirements, allowing a compatible client to select one option. A seller might offer the same dollar price in USDC on Base and Solana, or support several assets on an EVM network. The handler should deliver the same promised result regardless of which advertised option the buyer selects.

Multi-option support increases reach but also multiplies testing and reconciliation. Each option needs a working signer path, adequate facilitator support, correct decimal handling and clear revenue accounting. Do not advertise a fallback option that has only been compiled. Complete a controlled payment on every production option and monitor failures by scheme, network and asset.

Testnet currency is not production revenue

Official quickstarts begin on test networks so developers can validate requirements, signatures and responses without risking real funds. Test USDC and other development assets have no necessary relationship to mainnet value. A successful Base Sepolia or Solana devnet call proves a software path, not that the seller is ready to receive production payments.

Moving to mainnet means changing more than a label. Confirm the production network identifier, asset address, receiving wallet, facilitator endpoint and operational controls. Test the exact deployed route with a very small real payment, then verify both settlement and tool output. Keep test and production keys, balances and discovery records visibly separate.

How should a provider choose a payment rail?

Start with the buyers and wallets you can support, not the longest protocol feature list. A provider targeting current agent developers may prefer a widely documented stablecoin path on Base or Solana. A provider serving an existing ecosystem may choose another supported network. In either case, confirm production facilitator coverage, settlement operations, treasury handling and regulatory obligations with qualified advisers.

Then match the rail to call economics. Extremely small, frequent calls may need a scheme that reduces per-call settlement overhead. Higher-value, occasional tools may prioritize simple fixed-price authorization. Currency choice cannot rescue an unclear product: the tool still needs a defined output, reliable execution and a price that reflects the complete task.

A buyer checklist for a quoted currency

Treat every 402 response as the current source of payment truth. Compare the quoted network, asset, scheme, amount and destination with the tool's documentation and your policy. Reject ambiguous assets, unexpected destination changes and networks the signer was not configured to use. Never infer a safe contract from the word USDC alone.

For a newly discovered paid MCP tool, begin with a dedicated wallet and a read-only call. Record the exact payment requirement, settlement response and returned result. A directory listing helps shortlist candidates, but only the live requirement tells the buyer what the server is asking to receive at that moment.

Related directory entries

Sources and methodology

TOLL·402 distinguishes public claims, registry discovery, unpaid quote checks and settled paid-call verification. Sources below support the visible claims; presence in a registry is not treated as verification.

1. x402 networks and token support — Current network identifiers, token standards and facilitator scope.
2. x402 seller quickstart — Multi-network payment options, testnet setup and mainnet transition.
3. Official MCP server with x402 guide — Current wallet and multi-network example for MCP-connected tools.