BlockRun MCP: 19 Pay-Per-Call Tools for Claude and Other MCP Agents

The account-signup problem BlockRun MCP was built around

The README states the premise plainly: agents cannot sign up for accounts, cannot enter credit cards, and can only sign transactions. That is not a marketing line so much as a description of where most data vendors break down in an agent loop. A human developer signs up once, copies a key into .env, and the integration works forever. An agent that needs a price, a search result and a prediction-market quote has to be handed credentials for each vendor, and someone has to keep those credentials alive.

BlockRun MCP collapses that into one credential. The README says 19 tools sit behind a single self-custody wallet, with no per-vendor signups, and that the wallet signature is the authentication. Payment happens per request in USDC through the x402 protocol, described as fractions of a cent each, on Solana or Base. If your organisation cannot hand a wallet to an agent, the alternative is a BlockRun API key prefixed brk_live_, obtained from user.blockrun.ai, billed against prepaid credit at exact usage.

The audience is narrow and specific: people running MCP-compatible agents, chiefly Claude Code, who want the agent to reach live data without a human in the loop for every vendor. It is not a general HTTP client and it is not a data warehouse. It is a paid gateway with a fixed catalogue.

What the 19 tools actually cover, and the free tier

The README groups the tools as markets, research, web search, images, video, on-chain data, and Polymarket trading, and says 78 chat-visible models are reachable through the chat tool. On-chain queries are described as spanning 40 chains over RPC. Those numbers come from the README's own template markers, so treat them as the project's claims about its catalogue rather than a third-party count.

Four tools are listed as costing nothing: blockrun_chat with mode set to "free", blockrun_dex, a crypto price tool, and blockrun_models. That matters for evaluation. You can wire the server into an agent and exercise the free surface without funding anything, which is the cheapest way to find out whether the tool descriptions confuse your model before you put money behind them.

The rest of the catalogue is pay-per-call. Most of it returns data. One tool, blockrun_polymarket, does something different: the README says it places real, confirm-gated trades settled in USDC. The project's own framing is the "signal to trade loop", reading live odds and placing the bet from the same wallet. That is the feature that makes this server unusual, and it is also the feature that raises the stakes of a misconfiguration.

Installing BlockRun MCP and making a first call

The README gives a single command for Claude Code, registered at user scope so it applies across projects. Run it from a shell and Claude Code will pick up the server; the README says a wallet is auto-created on first run.

claude mcp add blockrun -s user -- npx -y @blockrun/mcp@latest

After that, fund the wallet with USDC, or skip the wallet entirely by setting BLOCKRUN_API_KEY in the environment. The README describes the wallet key as living at ~/.blockrun/.session with 0600 permissions, or in the OS keychain once you opt into BLOCKRUN_KEYCHAIN=strict. If you want to try the server before funding anything, the free tier is the place to start: blockrun_chat with mode:"free", blockrun_dex, the crypto price tool and blockrun_models cost nothing.

Before letting an agent spend, turn on the spend confirmation gate. The README documents BLOCKRUN_CONFIRM_SPEND=on, which pauses the agent before any paid call above your threshold so nothing is signed until you approve.

export BLOCKRUN_CONFIRM_SPEND=on

The README also documents a reduced tool schema for trading use. The project's own context-cost graphic states that the full schema costs 12.7K tokens, about 6 percent of a 200K context window, charged every turn whether or not you call a tool, and that --profile trading brings it to 5.2K. That measurement method is written up in docs/mcp-schema-overhead.md, which is worth reading before you decide which profile to run.

Wallet mode versus account mode, and where the money sits

The two payment paths are not cosmetic variants. Wallet mode authenticates with a signature and settles each call in USDC via x402, with no account, no credit card and no subscription. Account mode authenticates with a brk_live_ key and bills prepaid credit at exact usage. The README frames the second as being for teams that cannot run wallets, which is a real constraint in plenty of organisations: finance wants an invoice, security does not want a keypair on a build agent, and neither wants to explain a Solana balance to an auditor.

The trade-off is custody. In wallet mode the README says the key never leaves your machine and BlockRun cannot move your funds. That is a genuine property, and it also means there is no recovery path if the machine is lost and the key was not backed up. The default location is a file at ~/.blockrun/.session with 0600 permissions. The keychain option, BLOCKRUN_KEYCHAIN=strict, is opt-in rather than the default, which is the right ordering for a tool that has to work on headless machines, but it does mean the out-of-the-box posture is a plaintext file on disk protected by file permissions alone.

Account mode moves the risk elsewhere: a leaked brk_live_ key spends prepaid credit rather than draining a wallet, which caps the blast radius at whatever balance you have loaded. If you are putting this in CI or on a shared host, that is the argument for account mode regardless of how comfortable you are with wallets.

Polymarket trading is the feature that needs a policy, not just a config

Reading odds through an MCP tool is unremarkable. Placing a bet through one is not. The README says blockrun_polymarket places real, confirm-gated trades settled in USDC, and that the same self-custody wallet both reads the odds and places the bet. The confirmation gate is the control that stands between an agent's reasoning and a settled transaction.

That control is only as good as its configuration. BLOCKRUN_CONFIRM_SPEND is documented as pausing the agent before any paid call above your threshold, which means the threshold is a number you choose and the pause is a prompt you have to actually read. An agent that has been told to trade and a human who approves reflexively is a combination the software cannot fix. If you enable trading, the honest position is that you have given an LLM a funded wallet and a tool that settles real money, and the confirm gate reduces the frequency of that event rather than removing it.

The generative UI is the other half of this. On Claude Desktop, claude.ai, VS Code and Cursor the README says the Polymarket preview renders as a live order card with a Place button, and the wallet as a panel with balances, a QR code and card top-up. That is a better interface for a human approving a trade than reading JSON, but it also means the approval step is a button, and buttons get clicked.

The context tax, and why the project publishes its own overhead numbers

The most useful thing in this repository may be the context-cost graphic. It states that the server's tool schema costs 12.7K tokens, roughly 6 percent of a 200K context window, and is charged every turn whether or not a tool is called. The README notes that every MCP server imposes this cost and almost none of them say so, and links to docs/mcp-schema-overhead.md for the measurement method.

That is a real limitation stated by the vendor rather than discovered by a user. Nineteen tools with rich descriptions are not free to advertise to a model. The --profile trading option is the documented mitigation, cutting the schema to 5.2K tokens, which the graphic describes as 59 percent less. The cost of that reduction is not spelled out in the README: a smaller profile presumably exposes fewer tools or shorter descriptions, and the README does not say which tools survive the cut. If your workflow depends on a specific tool, verify it is present under the profile before you standardise on it.

There is a second-order effect worth naming. A 12.7K-token schema sits in every turn of every conversation, including the ones where the agent is doing something unrelated to markets. On a long session that is a persistent tax on both cost and the model's usable context. The measurement script, npm run measure:schema, is in package.json, so you can reproduce the number on your own machine rather than taking the graphic's word for it.

How it differs from wiring up provider APIs yourself

The obvious alternative is not another MCP server. It is doing what developers have always done: sign up with a search vendor, a market-data vendor and an on-chain RPC provider, put three keys in an environment file, and write the tool wrappers yourself. That approach gives you exactly the tools you need, no context tax from 19 unused ones, and no dependency on a payment protocol you may not want to explain to anyone.

The difference in approach is who holds the credential and who settles the bill. With direct integrations, a human holds accounts and the agent borrows keys. With BlockRun MCP, the agent holds a wallet and pays per call, and the README's argument is that this is the only shape that works when the agent is the one deciding what data it needs. The cost is that you inherit a catalogue rather than a curated set, and you accept x402 and USDC settlement as part of your stack.

A second alternative, for teams that want the catalogue without the wallet, is the account mode the README already provides: a brk_live_ key and prepaid credit. That is not a different project, but it is a materially different operational posture, and it is the version most enterprises will end up running.

Licence, maintenance and what upgrading costs

The package is MIT licensed, which permits commercial use and modification with the usual attribution requirement. That is about as permissive as it gets, and it means you can vendor the source if you need to. It says nothing about the terms of the underlying data sources or the Polymarket trading venue, which are separate relationships the licence does not cover. The repository contains a SECURITY.md and a CONTRIBUTING.md, so there is a stated process for both, though the README does not document a rollback procedure if a release misbehaves.

On maintenance: the last push was on 2026-09-09, and the repository is not archived. The release cadence visible in the changelog is fast. v0.47.0, v0.48.0 and v0.49.0 all landed within a few days of each other in early September 2026, and the v0.49.0 notes mention that the error message now says whether money moved, alongside thirty-seven audit findings. v0.48.0 added the ability to keep a key in a file and made a 429 response say when to retry.

That cadence is the upgrade cost. A pre-1.0 package moving through point releases this quickly will change behaviour, and the changes described are the kind that affect error handling and credential storage, not cosmetics. Pin a version in your agent configuration rather than tracking @latest, and read the changelog before moving. The npx invocation in the README uses @latest, which is convenient for a first run and a poor default for anything you depend on.

Editorial conclusion

Adopt BlockRun MCP if your agent needs live market, search or on-chain data and you are willing to fund a USDC wallet on Solana or Base, or to hold a brk_live_ key instead. Skip it if your data needs are met by a free API you already pay for, or if you cannot accept that a paid call settles a transaction the moment it is signed. Before rolling it out, read docs/mcp-schema-overhead.md, decide between the default schema and --profile trading, and set BLOCKRUN_CONFIRM_SPEND with a threshold you can live with.

Frequently asked questions

Official sources

1. BlockRunAI/blockrun-mcp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases