Agents on Bitcoin: the MCP × x402 Bridge Pattern

Three pieces of infrastructure landed in the last year: MCP gave agents a protocol for calling tools, x402 gave them a way to pay for those calls, and Bitcoin sits where it has always sat — as the asset an autonomous system actually wants to settle in. None of them talk to each other by default.

At Engrave we built the bridge. This is the pattern, not the sales pitch.

The Missing Bridge

If you have been following the agent-economy conversation, you have seen each of these pieces discussed separately. MCP — Anthropic's Model Context Protocol — is now the default way agents discover and call tools. x402 — the resurrection of HTTP status code 402 — is becoming the payments layer for machine-to-machine commerce. Bitcoin has been quietly doing what Bitcoin does while this conversation happens around it.

The gap is connective tissue. An MCP server that exposes trivial tools is not useful infrastructure. An x402 endpoint that returns JSON blobs is not an agent economy. A Bitcoin RPC locked behind a wallet UI is not agent-accessible at all.

What agents need — what autonomous systems operating with budgets and goals actually require — is:

1. A tool surface they can reason over, with typed contracts and predictable semantics.
2. An authentication layer that does not assume an account creation flow.
3. A settlement primitive they can pay from and be paid into without trusting the provider.

MCP gives you the first. x402 gives you the second. Bitcoin is the third. Wired together, they form the first full-stack agentic infrastructure where the agent is genuinely the first-class caller.

What MCP Actually Gives You

Skip the marketing: MCP is a protocol for exposing tools to LLM-based agents with discoverable schemas and typed contracts. The server advertises its tools (name, input schema, output schema, description). The agent discovers them at connection time and can then invoke them like local function calls, with the LLM doing the planning and the MCP client doing the I/O.

The part that matters for infrastructure design is that MCP forces you to define the contract. In a REST wrapper you can get away with loose typing — clients figure it out. In an MCP server, the agent is the client, and it cannot figure it out. The schema is the interface, and ambiguity in the schema becomes an agent reasoning failure at runtime.

For Bitcoin specifically, this is healthy pressure. The underlying RPC surface of bitcoind is the product of fifteen years of organic evolution — overloaded return shapes, inconsistent error formats, flags that mean different things in different contexts. None of that translates to a good MCP tool.

What you want is a small, composable surface. A handful of well-defined tools that an agent can plan against:

• bitcoin_get_balance(address) → { confirmed_sats, unconfirmed_sats }
• bitcoin_list_utxos(address, min_confirmations) → Array<{ txid, vout, value_sats, confirmations }>
• bitcoin_construct_psbt({ inputs, outputs, fee_strategy }) → { psbt_base64, estimated_fee_sats, estimated_vbytes }
• bitcoin_broadcast_psbt(signed_psbt_base64) → { txid }
• bitcoin_track_confirmation(txid, target_confirmations) → { confirmations, block_height, block_hash }

Each one is idempotent where possible, has a clean failure mode, and composes cleanly with the next. The agent can plan a full workflow — read balance, select UTXOs, construct PSBT, get it signed, broadcast, track to confirmation — by chaining these tools.

Importantly, each tool returns machine-first data. No HTML. No messages that mean "the operator should see this." The server talks to a machine; formatting for humans is the agent's job if the workflow needs it.

Designing Bitcoin as Callable Tools

Making Bitcoin operations agent-callable is more than schema discipline. It requires three properties that are not free by default.

Determinism. Given the same inputs, the tool should produce the same output — or fail with the same error. This is harder than it sounds for operations that depend on node state (mempool, fee estimates, block tip). The right move is to snapshot the relevant state into the output: don't just return a PSBT, return the PSBT along with the fee rate at construction time, the inputs selected, and the block height the construction used as reference. The agent can then reason over whether the PSBT is still valid if it gets signed late.

Idempotency where possible. Read operations are trivially idempotent. Write operations (broadcast) are not — a double broadcast is a user error, and the server should guard it. A common pattern is to return a stable identifier at PSBT construction time that the broadcast tool can use to deduplicate retries.

Clear error semantics. This is where the agent reasoning layer lives or dies. Structured errors with categories (INSUFFICIENT_FUNDS, FEE_TOO_LOW, DOUBLE_SPEND_DETECTED, NETWORK_TIMEOUT) let the agent plan a recovery path. String errors like "error processing transaction" force it to hallucinate.

The test I run: take a junior agent, give it a budget of 10,000 sats, ask it to send 5,000 sats to an address, and see whether it plans a valid sequence of tool calls without asking a human. If it can, the tool design is correct. If it gets stuck, the schema is lying somewhere.

x402 as the Authentication Layer

MCP defines the what. x402 handles the how-do-I-pay-to-call-it.

The naïve approach for monetising an MCP server is the same as any API: have the user sign up, get an API key, put the key in the MCP client's config. This works for a human developer configuring Claude or Cursor once. It does not work for an autonomous agent that might want to call a Bitcoin MCP server exactly once, in the middle of a workflow, with no prior relationship.

x402 solves this precisely. The MCP server, instead of gating tools behind a key, gates them behind an HTTP 402 response with a payment instruction. First call returns 402 and a price. The agent settles on-chain (USDC on Base is the common choice; native BTC is coming). The server verifies the payment and grants access to the tool call. The agent pays per-call for exactly what it uses.

Three benefits compound for agent infrastructure specifically:

No account management overhead. You never have to build user onboarding, key rotation, billing, or customer support. The chain is your user database.

Micropayments are native. With stablecoins on an L2, you can charge $0.01 per tool call without the payment processing eating the revenue. Legacy API-key pricing forces you into $49/month-minimum plans because credit card processing makes anything smaller uneconomic.

The payment is the authentication. There is no separate auth loop. The proof of payment is the proof of authorisation. This removes a class of credential-leak bugs entirely.

I wrote a full explainer on how x402 works end-to-end — the TL;DR is: HTTP 402 was reserved in 1999 for exactly this use case, and the web finally has the machinery to implement it.

PSBT Signing Without Custody

The hardest question in designing agent-callable Bitcoin infrastructure is: who holds the keys?

The wrong answer is "the MCP server does." That makes the server custodial, which introduces regulatory surface, counterparty risk, and the exact trust assumptions Bitcoin was designed to eliminate. It also breaks the protocol's security model — if the server can sign, the server can steal.

The right answer is Partially Signed Bitcoin Transactions (PSBTs). The server constructs an unsigned transaction from the agent's tool inputs, serialises it as a PSBT, and returns it. The agent — or, more realistically, a signer the agent is authorised to delegate to — signs the PSBT externally. The signed PSBT is handed back to the server, which finalises and broadcasts.

At no point does the server see or hold private keys. This is the same custody model the Bitcoin ecosystem has matured over years for hardware wallets, multisig coordinators, and collaborative custody setups. MCP just makes it callable by a machine.

The practical flow, in five tool calls:

1. Agent calls bitcoin_construct_psbt with inputs (amount, recipient, fee strategy). Server returns a PSBT.
2. Agent routes the PSBT to its configured signer — a local wallet, a remote HSM, an MCP-wrapped signing service, whatever the agent's principal has authorised.
3. Signer returns the signed PSBT to the agent.
4. Agent calls bitcoin_broadcast_psbt with the signed PSBT. Server verifies, finalises, broadcasts.
5. Agent calls bitcoin_track_confirmation with the resulting txid. Server returns confirmations.

The signing step happens outside the MCP server entirely. That is the feature, not the bug. Different agents will have different trust models — a research agent might use a single hot wallet, a treasury-management agent might route through a multisig coordinator. The MCP server does not need to care.

Cross-chain as a Product Decision

One last piece of the pattern: if you build an MCP server that gates Bitcoin operations behind x402 payments, you still have to decide where the payments settle.

The honest answer is that Bitcoin mainnet is the wrong place for micropayments today. On-chain fees price out sub-dollar transactions during any mempool congestion. Lightning helps, but Lightning-native x402 tooling is still young.

USDC on Base (or Solana, or another low-fee chain) is the pragmatic default for the payment leg. BTC is the pragmatic default for the utility leg — the thing the tools actually operate on.

This looks like compromise; it isn't. Different chains earn different seats:

• Settlement chain for utility: Bitcoin. Hardest money, permanent inscriptions, most-secure UTXO set.
• Settlement chain for payments: a low-fee stablecoin chain. USDC on Base is the current default. Solana works. Lightning is the eventual right answer.
• Distribution chain for any token economy around the tools: wherever liquidity lives. For Engrave, that was Solana via pump.fun; for other projects it may be a Uniswap pair on Base.

The rule: each chain does what it is best at, and the product architecture routes traffic to the correct seat. Agents do not care about chain politics — they care about where the cheap compute is, where the cheap payments are, and where the asset actually lives.

What Builders Should Do Now

If you are building anything that needs to be agent-accessible — not just Bitcoin infrastructure, any infrastructure — four concrete moves:

Wrap your existing API in an MCP server. Even if you keep the REST surface around for humans, give agents a typed tool interface. The discipline of defining the schemas will expose every ambiguity in your product surface. Fix those before agents find them at runtime.

Put x402 in front of at least one tool. You do not have to rip out your API-key auth. You can add 402 as a parallel path: key-based access for enterprise customers with contracts, x402 for machine traffic that shows up once. The two coexist cleanly.

Design tool contracts for reasoning, not for UX. The agent does not need a beautiful error message. It needs a structured error code, a recovery hint, and a deterministic idempotency key. Stop writing for humans when the caller is a machine.

Pick the right chain for the right job. If you are building a token economy around your tools, the distribution chain (where the token trades) and the utility chain (where the tools actually do their work) can be different. Do not feel obligated to put everything in one place because a marketing deck said so.

The infrastructure for the agent economy is being built right now. The teams that matter in two years are the ones shipping rails today — not the ones shipping autonomous-influencer demos. MCP gives you the tool surface. x402 gives you the payments. Bitcoin gives you the settlement layer the autonomous caller actually wants.

Wire them together deliberately, and the agent-accessible economy stops being a roadmap item and starts being a thing an agent with a budget can do today.

The Engrave work that sits behind this post is the full case study →. For the payment layer on its own, see x402 and AI agent payments. For the Bitcoin engineering side, the 1,500 Ordinals walk-through covers the tooling landscape before MCP existed.

If you are building agent-accessible infrastructure and want a second set of eyes on the contract design, Web3 consulting → is where to start.