MCP server

An RPC endpoint is not much use to an AI agent on its own. The agent has to know that a balance is hex, that it means nothing until you know the token's decimals, that an address with code is not a wallet, and that a transaction existing on chain is not the same as it having worked.

Our MCP server does that part. It exposes the chains we serve as tools an agent can reason about, and — if you give it a wallet — it buys its own capacity through x402 when the free tier runs out, without stopping to ask.

Install

claude mcp add originrpc -- npx -y originrpc-mcp

That already works: no key, no signup, anonymous tier. For sustained use pick one of the two below.

With an account

claude mcp add originrpc \
  -e ORIGINRPC_KEY=originrpc_live_your_key \
  -- npx -y originrpc-mcp

Usage bills to that key like any other traffic, and shows up in your dashboard alongside it.

With a wallet

claude mcp add originrpc \
  -e ORIGINRPC_X402_PRIVATE_KEY=0xyour_key \
  -e ORIGINRPC_MAX_SPEND_USDC=5 \
  -- npx -y originrpc-mcp

Fund the wallet with USDC on Monad and it pays for itself. When the agent exhausts the free tier mid-analysis, the server signs a payment, gets a key back, and the call the agent made goes through — the agent never sees the interruption.

ORIGINRPC_MAX_SPEND_USDC caps what one process will spend without being asked again. It defaults to 5. Set ORIGINRPC_AUTO_PAY=0 to turn automatic payment off and buy only through the x402_topup tool.

What it can do

> what does 0x6A750dDaE4960E7f06070d4fc538D7E01AF6Ca60 hold on monad?

  1.968486794 MON, a wallet (not a contract), 2 transactions sent.

Sixteen tools, grouped by what you would actually ask:

Finding your way — list_chains, chain_status

Reading state — inspect_address, token_balances, call_contract, get_logs, get_block, get_transaction, wait_for_transaction

Costing things — estimate_gas, gas_price

Other architectures — tron_account, solana_account

Your own spending — x402_status, x402_topup

Anything else — rpc, which passes a raw JSON-RPC method straight through.

call_contract reads any contract from its signature, so there is no ABI to supply:

call_contract(
  chain:     "monad",
  to:        "0x754704Bc059F8C67012fEd69BC8A327a5aafb603",
  signature: "function balanceOf(address owner) view returns (uint256)",
  args:      ["0xc6b666c6e04a6781E14DfA5F5455E10967268246"]
)

get_logs works the same way — give it an event signature and the arguments come back named instead of as topic hashes.

Networks

The tool list is fixed but the network list is not: it is fetched from the gateway at runtime, so a chain we add appears without you updating anything. Every EVM chain we serve works with every EVM tool.

Solana has no anonymous tier, so solana_account needs ORIGINRPC_KEY. x402 currently sells EVM capacity only.

About the private key

It signs one kind of message: an EIP-3009 transferWithAuthorization moving USDC to our published payment address, for the amount we quoted. It never signs a transaction, never leaves your machine, and is never sent to us — we only ever receive the signature.

Use a wallet funded with what you mean to spend. Not your main one.