BlockRun MCP: an MCP server that pays for its own data with x402
Live data for AI agents — search, research, markets, crypto, X/Twitter. Pay-per-call via x402 micropayments.
At a glance
- What is it?
- BlockRun MCP is an MIT-licensed Model Context Protocol server that fronts 19 tools for search, research, markets and on-chain data behind a single self-custody wallet or a BlockRun API key. The interesting part is the payment path, and the interesting cost is the context it occupies.
- Who is it for?
- Adopt BlockRun MCP if your agent needs live market, search or on-chain data and you are willing to fund a self-custody wallet with USDC, or if a team needs an API key and prepaid credit instead of a keypair. Do not adopt it if you want per-vendor API keys with human signup, if you cannot accept that the tool definitions occupy context on every turn, or if you are not prepared to reason about irreversible USDC settlement.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The signup wall that agents cannot climb
The README states the problem in one line: agents can't sign up for accounts, agents can't enter credit cards, agents can only sign transactions. That is a real constraint and not a marketing frame. A developer integrating a market data vendor normally creates an account, copies a key into .env, and attaches a card. An agent running unattended has no path through that flow. BlockRun MCP replaces the account with a wallet signature and the card with a per-call USDC payment over x402, the micropayment protocol the repository tags as a topic. The intended user is therefore narrow and specific: someone running Claude Code or another MCP-compatible agent who wants live data without provisioning a credential per vendor, and who is comfortable holding a small USDC balance on Solana or Base. If you are building a traditional backend service with a billing relationship and a finance team, this is not aimed at you, and the README says as much by offering a second mode for teams that can't run wallets.
Two authentication paths, one tool surface
The architecture visible in the README is a single MCP server that exposes one set of tools and swaps the payment layer underneath. In wallet mode the server authenticates with a signature and settles each call in USDC via x402 on Solana or Base. In account mode it authenticates with a BlockRun API key prefixed brk_live_ and bills prepaid credit at exact usage. The README claims the same tools either way, and the tool count appears in a templated comment (br:mcp.tools) that resolves to 19 in most places and 20 in one paragraph, which is a discrepancy worth resolving against the live package rather than the README. The tools themselves span chat, image and video generation, prediction markets, live web and X search, and on-chain queries across a stated 40 chains. A free tier is listed explicitly: blockrun_chat with mode:"free", blockrun_dex, the crypto blockrun_price, and blockrun_models cost nothing. Everything else is metered. The wallet auto-creation on first run is the piece that makes the first-run experience work at all, since a keypair that must be generated by hand would defeat the purpose.
Installing it and funding the wallet
The README gives one command for Claude Code: claude mcp add blockrun -s user -- npx -y @blockrun/mcp@latest. The -s user flag scopes the server to the user rather than the project. On first run the wallet is auto-created, and the README suggests funding with $5 USDC. If you would rather not run a wallet, set BLOCKRUN_API_KEY and skip it entirely. The key material lives at ~/.blockrun/.session with 0600 permissions, and the README says the OS keychain takes over once you opt into BLOCKRUN_KEYCHAIN=strict. Two other config keys matter. BLOCKRUN_CONFIRM_SPEND=on makes the agent pause before any paid call above a threshold you set, so nothing is signed until you approve. The --profile trading flag is presented as a context-reduction measure: the README's own graphic states that the default profile costs 12.7K tokens, about 6 percent of a 200K context window, charged every turn whether or not a tool is called, and that the trading profile drops this to 5.2K, a 59 percent reduction. That number is a claim from the project's own measurement, documented in docs/mcp-schema-overhead.md, and you should reproduce it against your own client before trusting it.
The context tax nobody else itemizes
The most useful thing in this repository may be the schema overhead measurement. Every MCP server injects its tool definitions into the context window on every turn, and the README points out that almost none of them say so. BlockRun MCP publishes its own figure and a method for measuring others. That is a genuine contribution to how people evaluate MCP servers, and it also exposes the project's own weakness: 12.7K tokens per turn is not small. It is roughly the size of a short document, spent before your agent does anything. The --profile trading flag exists precisely because the full tool surface is expensive to carry. This creates a real trade-off the README does not resolve. If you only need web search, you are paying context for image generation, video, prediction markets, and 40 chains of RPC queries you will never call. The honest reading is that BlockRun MCP is priced for agents that use several of its tools, not for agents that need one.
Read and trade in the same wallet is the sharp edge
The feature that distinguishes this from a data aggregator is blockrun_polymarket, which the README describes as placing real, confirm-gated trades settled in USDC. The pitch is that an agent can read live odds and place the bet from one self-custody wallet. That is also where the failure modes concentrate. A data call that goes wrong costs fractions of a cent. A trade that goes wrong does not, and the README's own v0.49.0 release note is titled around the error saying whether money moved, which tells you that distinguishing a failed call from a failed settlement was a problem worth a release. The confirm gate is the mitigation: with BLOCKRUN_CONFIRM_SPEND=on the agent pauses before paid calls above your threshold. Whether that gate covers the trade path as thoroughly as it covers ordinary paid calls is not spelled out in the material available, and it is the first thing I would test. The other structural point: the README describes the wallet as self-custody, with the key never leaving the machine, so BlockRun cannot move your funds. That also means nobody can recover them for you.
Generative UI and where it only half applies
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 renders as a panel with balances, a QR code and card top-up. This is MCP Apps territory, and it is a meaningfully different experience from reading JSON in a terminal. The limitation is that it is client-dependent. The README lists four clients where it works. It does not claim it works everywhere, and the fallback for other MCP clients is presumably the text tool output. If your team runs agents headlessly, or through a client not on that list, budget for the order card not existing and plan how a human approves a trade without a button to press. That is not a defect in the project so much as a boundary of the MCP Apps surface, but it changes who can safely use the trading tool.
The alternative: per-vendor keys and a normal bill
The obvious alternative is the one the README positions against: raw provider APIs, or a single-vendor MCP server that wraps one of them. The difference in approach is not the data, it is the credential and the billing relationship. A raw provider API gives you an account, a key in .env, a monthly invoice, and a human who can rotate the key when it leaks. BlockRun MCP gives you a keypair and per-call settlement, which removes the signup step and the invoice but replaces them with a funded wallet and irreversible payments. For a solo developer running an agent that needs search plus market data plus on-chain reads, the wallet path removes three signups and three keys. For a company with a procurement process, a finance team, and a security policy about key rotation, account mode with a brk_live_ key is the closer analogue to what they already do, and the README acknowledges this by offering it. The comparison table in the README is truncated in the material available, so I cannot evaluate the specific claims it makes against single-vendor MCP servers.
Release cadence, licence and what to check before adopting
The release notes show a fast cadence: v0.47.0 through v0.49.0 landed within roughly a week in September 2026, with titles about account mode, key storage in a file, 429 retry hints, and error messages that say whether money moved. Fast iteration on error semantics and retry behaviour is a good sign for a payments-adjacent tool, because it suggests the maintainers are hitting and fixing the cases where an agent cannot tell what happened. It also means the surface is moving, and anything you pin today may behave differently in a month. The licence is MIT, which permits commercial use, modification and redistribution with the copyright notice preserved. That is permissive, and it also means no warranty and no support obligation from the authors; the README links a Telegram community rather than a support contract. If you are evaluating this for production, read LICENSE yourself rather than treating this paragraph as legal advice. The concrete things to verify first are the tool count discrepancy between 19 and 20, whether the trading tool ships enabled by default or only under --profile trading, and whether BLOCKRUN_CONFIRM_SPEND gates the Polymarket trade path. Each of those is answerable from the repository in a few minutes, and each of them changes whether this is a data tool or a spending tool.
Editorial conclusion
Adopt BlockRun MCP if your agent needs live market, search or on-chain data and you are willing to fund a self-custody wallet with USDC, or if a team needs an API key and prepaid credit instead of a keypair. Do not adopt it if you want per-vendor API keys with human signup, if you cannot accept that the tool definitions occupy context on every turn, or if you are not prepared to reason about irreversible USDC settlement. Before you install, verify three things in the repository: whether the trading tool is enabled by default or gated behind a profile, how BLOCKRUN_CONFIRM_SPEND applies to the Polymarket trade path, and what the current free-tier tool list contains, since the README's own tool count moved from 19 to 20 between sections.
Community notes