Skip to main content
MCP Fortytwo Prime Installing to Client JSON-RPC x402Escrow Payments
Prerequisites:
MCP endpoint: POST https://mcp.fortytwo.network/mcp.
Web3 wallet with at least 2 USDC on Base or Monad to sign HTTP 402 payment requests.
A client that sends JSON-RPC requests (initialize, tools/list, tools/call)

User Journey: MCP + x402Escrow Payments

Step 1. Initialize the MCP Connection and Inspect Available Tools

These calls are free and do not require payment.
# Initialize:
curl -i -X POST "https://mcp.fortytwo.network/mcp" \
  -H "content-type: application/json" \
  -d '{
    "jsonrpc":"2.0",
    "id":"init-1",
    "method":"initialize",
    "params":{
      "protocolVersion":"2026-03-03",
      "capabilities":{},
      "clientInfo":{"name":"example-client","version":"1.0.0"}
    }
  }'
# List available tools:
curl -i -X POST "https://mcp.fortytwo.network/mcp" \
  -H "content-type: application/json" \
  -d '{
    "jsonrpc":"2.0",
    "id":"tools-1",
    "method":"tools/list"
  }'
The tool exposed by the server is ask_fortytwo_prime.
In conversation with an AI agent, phrases like “Ask Fortytwo” and “Ask Fortytwo Prime” refer to calling this tool.

Step 2. Send a tools/call Request

curl -i -X POST "https://mcp.fortytwo.network/mcp" \
  -H "content-type: application/json" \
  -d '{
    "jsonrpc":"2.0",
    "id":"call-1",
    "method":"tools/call",
    "params":{
      "name":"ask_fortytwo_prime",
      "arguments":{"query":"Explain quantum entanglement in simple words"}
    }
  }'

Server Response

If no active session exists, the server responds with HTTP 402 and a payment-required header.

Payments are Handled with x402Escrow Protocol

What is x402Escrow


Open-sourced on GitHub


Step 3. Build Payment from payment-required

The payment-required header contains base64(JSON) with payment options.
JSON
// Decoded `payment-required` example:
{
  "x402Version": 2,
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "1000000",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "payTo": "0x9562f50f73d8eE22276F13A18D051456d8D137a0",
      "maxTimeoutSeconds": 90
    }
  ]
}
Several accepts[] options can be listed, each with unique network details (eip155:8453 for Base, eip155:143 for Monad). Choose one of the accepts[] options, sign the payment with your wallet, and construct a payment-signature (base64-encoded JSON) containing:
  • network — Selected network
  • client — Payee address
  • maxAmount — Max amount
  • validBefore — Signature validity window
  • Cryptographic signature
JSON
// Decoded `payment-signature` example:
{
  "x402Version": 2,
  "scheme": "exact",
  "network": "eip155:8453",
  "payload": {
    "client": "0x1111111111111111111111111111111111111111",
    "maxAmount": "1000000",
    "validAfter": "0",
    "validBefore": "1760000000",
    "nonce": "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "v": 27,
    "r": "0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
    "s": "0xcccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc"
  }
}

Step 4. Repeat the tools/call and Now Include payment-signature

curl -i -X POST "https://mcp.fortytwo.network/mcp" \
  -H "content-type: application/json" \
  -H "payment-signature: <base64_x402_signature_json>" \
  -d '{
    "jsonrpc":"2.0",
    "id":"call-1",
    "method":"tools/call",
    "params":{
      "name":"ask_fortytwo_prime",
      "arguments":{"query":"Explain quantum entanglement in simple words"}
    }
  }'

Server Response

On success, the server verifies the signature, settles payment on-chain, and opens a billing session. The response includes:
  • x-session-id header — save this for subsequent calls
  • payment-response header — payment confirmation with txHash
  • JSON-RPC result with tool output

Step 5. Use x-session-id for Subsequent Calls

curl -i -X POST "https://mcp.fortytwo.network/mcp" \
  -H "content-type: application/json" \
  -H "x-session-id: <session_uuid>" \
  -H "x-idempotency-key: <uuid>" \
  -d '{
    "jsonrpc":"2.0",
    "id":"call-2",
    "method":"tools/call",
    "params":{
      "name":"ask_fortytwo_prime",
      "arguments":{"query":"Summarize this idea in 5 bullet points"}
    }
  }'
HeaderPurpose
x-session-idTies calls to one paid session
x-idempotency-keyPrevents duplicate payments on retries
jsonrpc.idIdentifies a single request/response pair

Step 6. Session Expiry and Re-payment

When session ends, the server responds with:
ResponseMeaning
402 Payment RequiredSubmit a new payment signature and open a new session
410 GoneSession expired — start a new payment cycle.
Unused credits from previous session get refunded.

Integration Checklist

1
Treat HTTP 402 Payment Required as the first-payment step.
2
Save x-session-id after successful payment.
3
Send x-idempotency-key on every tools/call.
4
On HTTP 410 or repeated HTTP 402, start a new payment cycle.

How Sessions Work: Lifetime and Closure

After the first successful payment, a billing session is created and identified: x-session-id. Each tools/call reserves budget first that gets locked in a x402Escrow contract. With each request, the contract charges the actual cost of inference, and releases unused reserve back to the available session balance. Session closure conditions:
  • If there is no activity for 10 minutes.
  • Session hits a hard cap of 60 minutes from session opening.
  • Session budget is exhausted.
  • Connection is dropped mid-response.
  • An upstream error occurs on a newly opened session.
If a session is close to expiry, new calls may be rejected to avoid starting operations that cannot be completed.
Automatic closure may occur with a small delay, typically up to tens of seconds.

Fund Release

After session closure, the release process starts automatically:
  1. The service finalizes the actual amount spent.
  2. A release transaction is sent on-chain.
  3. The spent portion goes to the service; unused remainder returns to the client’s wallet.
This typically takes a few seconds to a couple of minutes. Network congestion may cause longer delays.

If Release Does Not Happen

A fallback is available via on-chain refund: refundAfterTimeout(escrowId).
Funds always return to the original client address regardless of who calls it.
This refund is only available after the escrow’s refundAt deadline (typically ~90 minutes, exact timing depends on on-chain configuration).
How to get escrowId: from the settle transaction’s Deposited event, or via support on Discord.

What to Store Client-Side

Minimum data worth storing:
DataPurpose
x-session-idCurrent payment session identifier
payment-response
(especially transaction / txHash)
Payment confirmation and settle proof after successful session opening
payment-signature
(at least network + client + nonce)
Required for support and refund flows

Supported Payment Networks

USDC payments are currently accepted on two networks:
NetworkChain ID
Baseeip155:8453
Monadeip155:143
The accepts[].network and accepts[].asset fields in the payment response indicate which network and token address to use.

Token Usage

The actual cost is calculated from input and output tokens.
tools/call responses include usage data:
JSON
{
  "result": {
    "content": [{"type":"text","text":"..."}],
    "_meta": {
      "usage": {
        "tokens_in": 123,
        "tokens_out": 456
      }
    }
  }
}

Error Reference

CodeMeaningAction
402Payment requiredSign a new payment and repeat the tools/call request
410Session expiredOpen a new session, start a new payment cycle
4xx (other)Request or signature issueVerify network, signature validity window, and JSON-RPC format
5xxTemporary server/upstream errorWait and retry. If persistent, contact support on Discord with your txHash