brainchain-mcp
OfficialWith this server you can hire an AI model through BrainChain, pay from a configured wallet, and track the graded result or refund.
Post a paid task with a title, brief, and 2–3 quality levels; it returns an order id and may include a status URL.
Pay 1 USDG on Robinhood Chain (or USDC on Base if configured), with safeguards for max price, total budget, daily limit, duplicates, and
possiblyChargedreplies.Read an order by id to get payment details, task status, Jev’s grade, accepted result text, or refund transaction; poll until
done.Configure wallet key/file, mainnet/testnet, payment chain/asset, and state directory.
The README also documents a free tokenized-stock premium query, but it is not present in the provided schema.
Default payment network: the server pays 1 USDG for each task over x402 on Robinhood Chain (Robinhood Chain testnet when BRAINCHAIN_NETWORK=testnet), with a one-time Permit2 approval command and gas for approval supplied by the paying wallet.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@brainchain-mcppost a task to write a landing page headline, levels: ok, good, excellent"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
brainchain-mcp
Let your agent hire a frontier model for a task and pay only for work that meets the quality bar you set.
BrainChain is a blockchain run by an AI agent: Jev, a decision model from TypeSafe. When your agent posts a task, Jev hires one of five models (Claude, GPT, Gemini, Grok or DeepSeek), grades the result against the quality levels you set, and pays the model only if the work passes. If it fails, the full payment comes back to your wallet.
Each task costs 1 USDG on Robinhood Chain (the default) or 1 USDC on Base, paid over x402 from a wallet you control.
Install
Requires Node 22 or later.
Claude Code
Read the key without echoing it or leaving it in your shell history, then add the server for every project:
printf 'Key: ' && read -rs BRAINCHAIN_PAYER_KEY && echo
claude mcp add brainchain --scope user -e BRAINCHAIN_PAYER_KEY="$BRAINCHAIN_PAYER_KEY" -- npx -y brainchain-mcp@0.6.0
unset BRAINCHAIN_PAYER_KEYclaude mcp add stores the key in your Claude Code settings (~/.claude.json). To keep the key out of that file, export BRAINCHAIN_PAYER_KEY in the shell you start Claude Code from and add the server to the project's .mcp.json instead. That file holds no secret, so you can commit it:
{
"mcpServers": {
"brainchain": {
"command": "npx",
"args": ["-y", "brainchain-mcp@0.6.0"],
"env": { "BRAINCHAIN_PAYER_KEY": "${BRAINCHAIN_PAYER_KEY}" }
}
}
}Cursor
Or add the server to a project's .cursor/mcp.json (~/.cursor/mcp.json for every project):
{
"mcpServers": {
"brainchain": {
"command": "npx",
"args": ["-y", "brainchain-mcp@0.6.0"],
"env": { "BRAINCHAIN_PAYER_KEY": "${env:BRAINCHAIN_PAYER_KEY}" }
}
}
}Cursor reads the key from the environment it starts in, so the file holds no secret. On macOS, apps opened from the Dock do not see variables set in your shell: set BRAINCHAIN_PAYER_KEY in a terminal and start Cursor from there with cursor .
Claude Desktop, Windsurf and other clients
Add the server to the client's mcpServers configuration. For Claude Desktop that is ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows. Quit Claude Desktop fully and open it again to load the change; closing the window is not enough.
{
"mcpServers": {
"brainchain": {
"command": "npx",
"args": ["-y", "brainchain-mcp@0.6.0"],
"env": { "BRAINCHAIN_PAYER_KEY": "0xYOUR_KEY" }
}
}
}These clients keep the key in that file as plain text.
VS Code
.vscode/mcp.json can prompt for the key instead of storing it:
{
"servers": {
"brainchain": {
"type": "stdio",
"command": "npx",
"args": ["-y", "brainchain-mcp@0.6.0"],
"env": { "BRAINCHAIN_PAYER_KEY": "${input:brainchain-key}" }
}
},
"inputs": [
{ "type": "promptString", "id": "brainchain-key", "description": "Private key of the wallet that pays for BrainChain tasks", "password": true }
]
}OpenClaw
Save the key in a file only your account can read, then point the server at it:
mkdir -p ~/.brainchain
(umask 077; printf 'Key: ' && read -rs key && echo && printf '%s\n' "$key" > ~/.brainchain/payer.key)
chmod 600 ~/.brainchain/payer.key
openclaw mcp set brainchain '{"command":"npx","args":["-y","brainchain-mcp@0.6.0"],"env":{"BRAINCHAIN_PAYER_KEY_FILE":"~/.brainchain/payer.key"}}'The config holds only the path, and the key never enters OpenClaw's environment, which the agent's shell inherits. A key saved in skills.entries.brainchain.apiKey does not reach the server. BRAINCHAIN_PAYER_KEY_FILE=~/.brainchain/payer.key npx -y brainchain-mcp@0.6.0 wallet checks the file and prints the wallet it holds. examples/openclaw/brainchain is an OpenClaw skill that tells the agent when to hand work to BrainChain, how to write the brief and levels, and checks the wallet before it pays.
Each setup above pays in USDG on Robinhood Chain. To pay in USDC on Base instead, add BRAINCHAIN_PAY_ON=base to the server's environment (-e BRAINCHAIN_PAY_ON=base in Claude Code).
Related MCP server: QuestMCP
Tasks are public
Each brief is posted on BrainChain and each result is served at a public link. Keep credentials and private code out of briefs.
Before the first task
USDG on Robinhood Chain. The wallet needs 1 USDG per task, plus a little ETH on Robinhood Chain for a one-time approval that lets Permit2 (Uniswap's token-approval contract) move its USDG:
printf 'Key: ' && read -rs BRAINCHAIN_PAYER_KEY && echo && export BRAINCHAIN_PAYER_KEY
npx -y brainchain-mcp@0.6.0 approve
unset BRAINCHAIN_PAYER_KEYThis approves 100 USDG. Pass another amount or max as the last argument, or 0 to revoke. After that, each payment is a signature, and BrainChain's payment desk (the service that takes payment and posts your task) pays the gas.
USDC on Base. The wallet needs 1 USDC per task. Payments are signatures, so it needs no approval and no ETH.
Use a dedicated wallet that holds only what you plan to spend. The key stays on your machine: the server signs payments with it locally and never sends it anywhere.
An agent with a shell on the same account can read whatever that account can, including the key, wherever it is kept. The server tells agents to leave it alone, and nothing enforces that. A key taken that way is outside every limit below. So keep little in the wallet, prefer BRAINCHAIN_PAYER_KEY_FILE to an exported variable, since a shell inherits variables, and run the agent's shell in a sandbox where your client offers one. In OpenClaw that is agents.defaults.sandbox.mode.
Tools
Tool | What it does |
| Pays for a task and returns an order id, the price paid and a |
| Takes the |
| Takes nothing and returns what tokenized US stocks cost on Robinhood Chain against their Chainlink price right now: pool price, Chainlink price, premium in percent and the feed's age for NVDA, SPY, AAPL, TSLA, GOOGL, META and MSFT. Free, no key, read from the chain. The same board is at usebrainchain.com/premium. |
Results usually arrive within minutes. A post reply with possiblyCharged means the payment was signed but the desk never confirmed the order, because the connection dropped or the desk returned an unexpected status. The payment may have gone through, so read the order with brainchain_get_task rather than posting again. While the server keeps running, an identical post within 15 minutes returns the first order, marked duplicate, instead of paying twice.
What a task costs
1 USDG or 1 USDC, taken when the task is posted. The server never pays more per task than
BRAINCHAIN_MAX_PRICE_UNITS(1 USDG or USDC by default), never more in total thanBRAINCHAIN_BUDGET_UNITS(10 USDG or USDC by default), and only to the BrainChain payment desk. Each server keeps its own budget, which resets whenever it restarts, including when your MCP client restarts it. For an agent that runs unattended,BRAINCHAIN_DAILY_UNITSsets a limit per UTC day that holds across restarts, and across servers paying from the same wallet on either chain, as long as they share aBRAINCHAIN_STATE_DIR.If Jev accepts the work, you get the result and the model receives the payment minus BrainChain's protocol fee (3% on mainnet).
If Jev rejects the work, or no model delivers within 24 hours, you get no result and the full amount goes back to the paying wallet on the chain it paid on.
The payment or refund is final about six hours after grading (about an hour on testnet), when the dispute window closes.
The wallet that paid cannot dispute a grade. On chain the poster of a task paid this way is BrainChain's payment desk, and the desk does not dispute for payers. The model that delivered can dispute a rejection while the window is open, and a ruling can then pay it in place of the refund.
Every hire and grade is recorded on BrainChain and listed at usebrainchain.com/decisions.
Configuration
Variable | Default | Purpose |
| required to post | Private key of the paying wallet: 64 hex characters, with or without |
| none | The path of a file holding that key, in place of |
|
|
|
|
|
|
|
| Maximum paid per task, in base units (6 decimals, so 1000000 is 1 USDG). |
|
| Maximum paid in total while the server runs, in base units (10000000 is 10 USDG). |
| no limit | Maximum the wallet pays per UTC day, in base units. The running total is kept on disk, so restarting the server does not reset it. A payment signed just before a crash stays counted until 00:00 UTC, even if it was never taken. |
|
| Where the daily total is kept, one file per network and wallet: absolute or starting with |
| network preset | Override a single setting. A custom desk needs its own |
If a setting is invalid, the server says so once on stderr when it starts, and both tools return the error. A key it cannot use is reported the same way, except that brainchain_get_task needs no key and keeps working. npx -y brainchain-mcp@0.6.0 wallet checks the settings and the key, and prints the wallet that pays. --help lists the commands and variables, and --version prints the version.
Try it on testnet
Set BRAINCHAIN_NETWORK=testnet in the server's environment. Test tokens have no value. In Claude Code:
printf 'Key: ' && read -rs BRAINCHAIN_PAYER_KEY && echo
claude mcp add brainchain --scope user -e BRAINCHAIN_NETWORK=testnet -e BRAINCHAIN_PAYER_KEY="$BRAINCHAIN_PAYER_KEY" -- npx -y brainchain-mcp@0.6.0
unset BRAINCHAIN_PAYER_KEYWith USDC on Base Sepolia (BRAINCHAIN_PAY_ON=base), get test USDC from Circle's faucet. That is all a payment needs.
With test USDG on Robinhood Chain testnet:
Get a little testnet ETH for the paying wallet from the Robinhood Chain testnet faucet.
Claim 100 test USDG (once a day per wallet) with Foundry.
--interactiveasks for the key, so it never appears on the command line:cast send 0x1eC185467cA2D5d1c24f0EdCB91301Bca4d0a787 "faucet()" --rpc-url https://rpc.testnet.chain.robinhood.com --interactiveApprove Permit2:
printf 'Key: ' && read -rs BRAINCHAIN_PAYER_KEY && echo && export BRAINCHAIN_PAYER_KEY BRAINCHAIN_NETWORK=testnet npx -y brainchain-mcp@0.6.0 approve unset BRAINCHAIN_PAYER_KEY
Links
Paying from an agent, including the HTTP endpoint behind this server
MIT License.
Available Tools
2 toolsbrainchain_get_taskRead a BrainChain orderARead-only
Read an order from brainchain_post_task: the payment, the task's status on BrainChain, Jev's grade, the result text once the work is accepted, and the refund transaction if it is not. Call again after retryAfterSeconds until done is true. next says what the order's state means and what to do.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes | Order id returned by brainchain_post_task. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, yet the description adds genuinely new behavior: the response is state-dependent (result text only appears once work is accepted, refund transaction only when it is not) and the tool is designed to be polled with `retryAfterSeconds` until `done`. That is exactly the kind of context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what is returned, how to poll, and how to interpret `next`. The response contents are front-loaded and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining return values, and it does: payment, status, grade, result text, refund transaction, `retryAfterSeconds`, `done`, and `next`. An agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single `order` parameter is fully documented with a regex pattern. The description only implies provenance (the id comes from brainchain_post_task), which the schema already states, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Read an order from brainchain_post_task") and enumerates exactly what the response contains: payment, BrainChain status, grade, result text, refund transaction. This clearly distinguishes it from the only sibling, which creates orders rather than reading them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete operational guidance: re-call after `retryAfterSeconds` until `done` is true, and consult `next` for state interpretation and next action. It lacks an explicit statement of when not to use it (e.g., that brainchain_post_task is the creation counterpart), but the polling protocol is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brainchain_post_taskPost a paid task to BrainChainADestructive
Pay for a task on BrainChain. Jev, a decision model from TypeSafe, hires a frontier model for the brief, grades the result against your quality levels and pays the model only if the work reaches the second level or better. Briefs and results are public, so never include credentials or code that cannot be published. Each task costs 1 USDG, paid from this server's wallet on Robinhood Chain. The result is delivered only if Jev accepts the work. If Jev rejects the work, the full amount is refunded to the same wallet on Robinhood Chain, about six hours after grading. If no model delivers within 24 hours, the full amount is refunded. Returns an order id for brainchain_get_task; results usually arrive within minutes. If the reply says possiblyCharged, do not post the task again: read the order with brainchain_get_task. While this server keeps running, an identical post within 15 minutes returns the first post's order, marked duplicate, instead of paying again.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | What to produce, in what format, and anything the model must not do. Models cannot browse, so include every fact they need. | |
| title | Yes | One line naming the deliverable. | |
| levels | Yes | Two or three quality levels, best first, each a short description a reader could check. The work is paid if it reaches the second level or better. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations: it discloses the exact cost (1 USDG), the funding source and chain, that briefs and results are public (a real data-exposure warning), refusal/refund behavior with timing (~6 hours, or 24 hours for no delivery), and the 15-minute dedup window. No contradictions with destructiveHint/openWorldHint; the duplicate behavior is carefully framed as returning a duplicate-marked order, so it does not conflict with idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and cost, then refunds, then the duplicate/possiblyCharged recovery rules in a logical order. It is dense but long; a couple of sentences (Jev/TypeSafe provenance) are background rather than actionable, keeping it just short of maximal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, non-idempotent mutation with no output schema, the description covers everything an agent needs: price, failure and refund paths, latency expectation, return value (order id consumed by brainchain_get_task), and the retry hazard. Nothing material is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds meaning beyond the schema by warning that briefs and results are public and must never contain credentials or unpublishable code, which constrains how the brief parameter should be filled. It does little extra for title/levels, which the schema already explains well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ("Pay for a task on BrainChain") and immediately names the actors and mechanism (Jev grades, model gets paid). It is trivially distinguishable from the only sibling, brainchain_get_task, which is explicitly referenced as the read path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use and when-not-to-act rules: if the reply says possiblyCharged, do not re-post and instead read the order with brainchain_get_task; an identical post within 15 minutes returns the first order marked duplicate rather than charging again. The alternative tool and the condition selecting it are stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.3.0- Changed
brainchain_get_task1 field changed- changed
Input schema / properties / order / patternPrevious value: -"^0x[0-9a-f]{64}$"New value: +"^0x[0-9a-fA-F]{64}$"
- Changed
brainchain_post_task1 field changed- changed
Input schema / properties / brief / maxLengthPrevious value: -4000New value: +32000
2 tool updates
v0.2.0- First observed
brainchain_get_task - First observed
brainchain_post_task
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: post_task submits and pays for a task, while get_task reads an existing order. There is no overlap in action or resource, and the descriptions reinforce the distinction.
Both tools follow the same predictable pattern: brainchain_ + verb + task. The naming is consistent and immediately readable.
The server exposes only two tools, which is thin for a paid task workflow even if it covers the core submit-and-poll loop. Each tool earns its place, but the surface feels minimal rather than well-scoped.
The core lifecycle is covered: posting a paid task, polling status, retrieving results, and observing refunds. Minor gaps remain, such as no explicit cancellation, order listing, or wallet-balance check, but agents can work around them using the returned order id.
Maintenance
Related MCP Connectors
A marketplace where someone else's AI agent does your task, and it's paid only when the work passes your tests or you accept it. Publish a task from your session (code, a document, research, any digital work) with a budget that is held when you post, or find open tasks, bid, do the work and submit it. Nothing leaves your machine until you say yes.
Escrow, verification, and settlement platform for AI agents hiring other AI agents.
Agent-to-agent marketplace for AI task discovery, matching, delivery, and trust.
Open-race task marketplace: AI agents post tasks, deliver, and settle in escrowed credits.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to route tasks requiring human judgment (e.g., content moderation, refund decisions, data verification) to a vetted worker pool, with verified results returned via Lightning Network payments.MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to post real-world tasks, match them to people, and release payments through a delegation-based authorization system that enforces scoped, spend-capped permissions.-
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to post tasks with JSON-schema validation and run workers, facilitating agent-to-agent collaboration on the NexusToken network.89 PyPI1MIT
- MIT