How to use Mu - tools for agents - with x402 payments | Mu

Mu

Home<br>Tools<br>Agents<br>Services<br>Wallet

Login

How to use Mu - tools for agents - with x402 payments

Crypto · Agents · Dev<br>Updated 9 minutes ago · Asim · {this.textContent='Copied!';setTimeout(()=>{this.textContent='Share'},2000)})}" title="Share this post">Share<br>For a while I&rsquo;ve been playing around with Mu - an open source project that provides tools for agents behind one MCP server and app.

You can find it on github https://github.com/micro/mu.

I started to wonder how to turn this into something I could run and charge money for. Then spent some time building out payments using stripe and a top-up credit model. Eventually getting tired of that, I realised agents should probably do this without an account using Coinbase&rsquo;s x402 protocol.

This is an example of how to use an agent to pay for MCP tools with a USDC wallet and x402 on the live instance of Mu at https://micro.mu.

What is x402

HTTP 402 was reserved in 1997 and left unimplemented for two decades. x402 puts it to work: a server answers 402 with a machine-readable price, the client pays on-chain and retries, and the whole exchange takes one round trip with no human involvement. I guess its no more interesting than adding a credit card to some cloud account and getting an API token. But what if in the long term your agent could discover and use many different x402 servers with no human involvement. Thats where it gets interesting. But we have to enable that future first. And so Mu accepts USDC payments using x402 as an experiment to test the thesis.

Note: You can run your own Mu server and make some money doing it!

A transaction

Here&rsquo;s a real call, on Base mainnet, from an agent when doing this experiment:

Status<br>SUCCESS — block 49920226

Tx<br>0x58d2ac05de3b410ee4f9c2af0e9977a270be5bf8559cf054a23228f95f0e3a54

Amount<br>0.020000 USDC

From<br>0x4160A86303eeBA12fc0A3FFB8480A9d2D1eAb7A1 (the agent)

To<br>0x9a717EFF039622231C65ADbF7B2A002b544b06A9 (the server)

Gas paid by<br>0x67b9ce70… — the facilitator, not the payer

Payer ETH<br>0.0 — it has never held any

The paying wallet holds no ETH and never needed any. It signs an authorisation; somebody else pays the gas to execute it. An agent can therefore be funded with nothing but the money it spends — no gas token, no top-up effort, no account or token to deal with. Maybe many of us are thinking, so what? We are no crypto experts. Well turns out ethereum &ldquo;gas&rdquo; fees can add up to a lot, so using USDC on Base cuts through a lot of that.

What happens on the wire

Four steps, and only the third involves any cryptography you have to think about.

Call as normal. An ordinary request with no credentials. Free endpoints just answer — which matters more than it sounds, and we will come back to it.

Read the 402. The body names the price, the asset, the chain and the address to pay. Nothing is hardcoded in the client; the server declares its own terms.

Sign an authorisation. An EIP-3009 transferWithAuthorization for exactly that amount. It moves nothing by itself — it is permission, not a transfer.

Retry with the header. The server presents the signature to a facilitator, which settles it on-chain and pays the gas. The tool answers in the same response.

Here is a real challenge, from a live server:

$ curl -s -X POST https://micro.mu/mcp \<br>-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",<br>"params":{"name":"web_search","arguments":{"query":"x402"}}}'

"x402Version": 1,<br>"accepts": [{<br>"scheme": "exact",<br>"network": "base",<br>"maxAmountRequired": "20000",<br>"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",<br>"payTo": "0x9a717EFF039622231C65ADbF7B2A002b544b06A9",<br>"extra": { "name": "USD Coin", "version": "2" }<br>}]

maxAmountRequired is in atomic units — 20000 is $⁠0.02. You can run that command right now. It costs nothing to be told a price.

Paying it, in about ten lines

You don&rsquo;t need to implement any of this. The x402 Foundation ships clients for Go, TypeScript, Python and Java. In Go, the payment lives inside an ordinary http.Client, so the calling code has no payment logic in it at all:

signer, _ := evmsigners.NewClientSignerFromPrivateKey(os.Getenv("X402_PRIVATE_KEY"))

// v1 names its networks "base"; v2 uses CAIP-2. Registering both<br>// is one line and survives a server upgrading underneath you.<br>client := x402.Newx402Client().<br>RegisterV1("base", evmv1.NewExactEvmSchemeV1(signer)).<br>Register("eip155:*", evm.NewExactEvmScheme(signer, nil))

httpClient := x402http.WrapHTTPClientWithPayment(<br>http.DefaultClient,<br>x402http.Newx402HTTPClient(client),

// From here it's just HTTP. The 402, the signature and the<br>// retry all happen inside RoundTrip.<br>resp, _ := httpClient.Post(server+"/mcp", "application/json", body)

The error you hit first is an empty wallet, and facilitators report it as execution reverted — words that say nothing about funding anything. If you are building the server side, catch that case and say &ldquo;this...