Blockchain RPC for AI Agents: a Hosted MCP Server, a CLI and a Cookbook

Coding agents write a lot of blockchain code now, and most of it starts with the same questions: what is the RPC URL for this chain, does it support eth_getBlockReceipts, is there an archive node, why does eth_getLogs fail over 10,000 blocks. An agent that has to guess those answers writes code that breaks on the first run. An agent that can look them up, and then try the call, gets it right.

This week we shipped three things for that: a hosted MCP server, a command-line tool, and an agent cookbook. All three are free to use, and the public parts work without an account.

The MCP server

The server is at https://rpc.swiftnodes.io/mcp. It speaks Streamable HTTP, so there is nothing to install. In Claude Code:

claude mcp add --transport http --scope user swiftnodes https://rpc.swiftnodes.io/mcp \
  --header "Authorization: Bearer $SWIFTNODES_API_KEY"

In Cursor or any client that takes a JSON config:

{
  "mcpServers": {
    "swiftnodes": {
      "url": "https://rpc.swiftnodes.io/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Leave the header out and the server still works, with the five public tools:

With a key, two more:

get_method_support is the one we find most useful. It answers from the method-support matrix, which we rebuild every week by probing each chain, so an agent can learn that a chain lacks trace_* before it writes an indexer that depends on it.

probe_endpoint works on any public endpoint, not only ours. Point it at the RPC URL your project already uses and it reports the chain, the head block, whether old state is available, and how fast it answers. It refuses private and internal addresses and does not follow redirects.

Read-only by design

The server cannot move funds. rpc_call refuses any method that sends, signs or broadcasts a transaction, and the admin_, personal_, miner_, engine_ and debug_set families. Every tool carries readOnlyHint: true, so clients that respect MCP annotations can run them without asking each time. If an agent needs to send a transaction, it has to use your own wallet code, where you can see it.

It is also listed in the official MCP Registry as io.swiftnodes/swiftnodes, and as a local stdio package on npm: npx -y swiftnodes-mcp runs the five public tools on your own machine.

The CLI

Agents are good at running shell commands, so the CLI is built for them as much as for people. It is one file with no dependencies:

curl -fsSL https://swiftnodes.io/install.sh | sh
swiftnodes login

login uses a device flow: it prints a short code, you approve it in the browser, and the CLI receives a 90-day session. No key is pasted into a terminal or a chat.

The command that saves the most time sets up a project:

swiftnodes chains base
swiftnodes project setup --chain base --create-key my-app

That creates a key and writes SWIFTNODES_API_KEY, SWIFTNODES_RPC_URL and SWIFTNODES_WSS_URL into .env, keeping your other lines and making sure .env is in .gitignore. An agent asked to "set up an RPC for this project" can do it in one step, and the key never appears in its context. Full reference in the CLI docs.

Keeping an agent's key safe

An agent's key ends up in more places than a human's: generated code, logs, sometimes a pull request. So keys can now be restricted to IP addresses or CIDR ranges, and to browser origins, including wildcards like https://*.example.com. A request must match one of the rules, or it gets a 403. Set restrictions in the dashboard or with swiftnodes keys restrict. A key limited to your server's IP is worth little to anyone who finds it in a repository.

The cookbook

The agent cookbook has eight recipes, each a prompt you paste into your agent:

• Large USDC transfer tape
• Multi-chain wallet balance snapshot
• Uniswap v3 swap tape
• Gas and fee board across chains
• Daily balance history from archive state
• New contract deployments feed
• Bitcoin address watcher
• Robinhood Chain activity monitor

Before publishing, we gave each prompt to a separate agent with a fresh account and let it build the thing from scratch against live endpoints. Where agents went wrong, we fixed the prompt, not the output: the reliability notes shared by every recipe (retry 429s and timeouts with backoff, split an eth_getLogs range that returns too many results, retry a newest block that comes back null, keep WebSockets alive with a ping) came from watching them fail.

For agents that read docs directly

Some agents skip the website and fetch plain files. These are all public:

• /llms.txt: an index of the docs for language models
• /endpoints.json: every chain, slug, chain ID and endpoint URL, with archive flags
• /pricing.md and /rate-limits.md: plans and limits as Markdown

Try it

Add the MCP server without a key and ask your agent which chains support eth_getBlockReceipts. If the answer is useful, create a free account for a key and let it make the calls too. Setup details are in the MCP docs.