RobinX MCP
A language model without tools is a rumour engine. It can describe a blockchain beautifully and it cannot read one. RobinX MCP is the layer that closes that gap: it hands Bugglo live hands on Robinhood Chain — token state, rug verdicts, deployer history, launches as they land — and lets the agent decide for itself which of them to reach for. This page is the whole story: what it does today, what stops it doing harm, and how far we intend to take it.
What RobinX MCP actually is
The Model Context Protocol is an open standard for handing a model tools. Publish a capability once as an MCP server and any MCP-capable client — Claude Desktop, Cursor, your own agent — can call it without a bespoke integration. It is a port, not a plug: the thing you build against once instead of rewriting for every model that ships next quarter.
RobinX MCP is that port for Robinhood Chain.It takes a chain — an append-only ledger that answers only the questions you already know how to ask — and turns it into something an agent can interrogate. Not an endpoint the app calls on the user's behalf. A tool the model calls, on its own initiative, mid-thought, because it decided the answer required it.
Is 0x7f3a…c9d2 safe to ape?
Nobody wired that sentence to a function. The agent read it, decided it needed the contract contract code, ownership, DEX liquidity, privileged powers, and deployer history, called the tools that could measure them, marked the missing checks as unknown, and said so. That is the entire difference between a search box and an agent, and RobinX MCP is what makes the second one possible.
The loop is the product
Any model can call one tool. What makes Bugglo dangerous is that it refuses to stop at one. Every question runs through a six-phase protocol before an answer is allowed out — and the phase most agents skip is the fifth.
Observe
What is being asked, what is already known, and what is missing. The agent names the gap before it moves to fill it.
Analyze
Patterns, anomalies, risks, opportunities. The shape of the question decides which tools are even worth calling.
Plan
Which tool first, in what order, and — the part most agents skip — what to do when one of them fails.
Act
Call the tools. Collect the data. RobinX MCP and the rest of the fleet are hit in the order the plan chose, not the order they were registered.
Verify
Cross-check every claim against an independent source and report where they disagree. A clean verdict from one source is worthless.
Refine
What was missed, what to ask next, what to carry into the next question. The loop closes, or it runs again.
Cross-examination, not citation
One source saying a token is clean tells you one source has been fooled. The agent checks market data against chain-readable contract state, compares ownership powers against bytecode, separates measured signals from unknowns — and reports the contradiction rather than laundering it into a confident average.
It reroutes when a tool dies
Blockscout goes down; Etherscan answers instead. A paid tool returns a price probe; the agent says so rather than inventing the number it wanted. The plan survives its own tools failing, because on-chain tools fail constantly and an agent that cannot survive that cannot be trusted.
The loop runs up to four iterations in Auto and Fast, and up to six in Deep — each iteration free to call more tools based on what the last one returned. Depth is a dial, not a marketing word.
What RobinX MCP hands the model
Six tools, all live in production, all read-only. Each one is a question a trader asks out loud at three in the morning with money already on the line.
robinx_verdictIs this safe? The composite rug-check. Contract code, ownership, proxy state, privileged powers, DEX liquidity, and explicit unknowns — folded into one verdict with the evidence still attached to it.
Liverobinx_tokenWhat is this token, really? Token metadata and live DEX liquidity for contracts on the chain. Holder spread and lock state are not claimed unless a real source can measure them.
Liverobinx_deployerWho is behind it? The address that shipped the contract, and the thread back to everything else it has ever touched. Tokens do not rug. People do.
Liverobinx_statsHave they done this before? Deployer reputation across the history the connected tools can actually resolve, with gaps called out instead of filled in.
Liverobinx_feedWhat just landed? The live launch feed — what deployed in the last hour, with the liquidity actually attached to it rather than the liquidity promised in the announcement.
Liverobinx_leaderboardWhat is moving? Ranked movement across the chain. Volume next to liquidity, because volume without liquidity is a trap with a chart on it.
LiveThe model never sees a tool that is not on this list. It is an allowlist, not a filter applied after the fact — an unlisted tool is invisible, which means the model cannot be talked into calling it. Set ROBINX_ALLOWED_TOOLS to narrow it further.
RobinX does not work alone
RobinX MCP is the native tool layer for Robinhood Chain. Around it, mcp.json mounts a fleet of independent MCP servers — each one a different way of being right, and a different way of being wrong. The agent plays them against each other. Add a server to that file and the agent can use it on the next boot; no code change, no redeploy of the model.
| Server | What it is for | Transport | State |
|---|---|---|---|
dexscreener | Price, volume, liquidity, pair-level market data | stdio | On |
boo-crypto | Rug-check, honeypot behaviour, sanctions screening | stdio | On |
boar-basic | General chain intelligence — the cheap first pass | streamable-http | On |
boar-advanced | Deeper forensics when the first pass finds something | streamable-http | On |
fuse | Cross-chain context for anything with a bridge in its past | streamable-http | On |
hooddomains | .hood name resolution, so wallets have names | stdio | On |
etherscan | Contract source and ABIs — needs an Etherscan API key | stdio | Needs key |
whale-intel | Holder analysis, whale tracking, wallet clusters | streamable-http | Needs key |
blockscout | Contract source, ABIs, transactions, deployer trail | streamable-http | Not answering |
hoodpocket | Wallet operations — deliberately switched off | stdio | Off |
hoodpocket is a wallet server, and it is switched off on purpose. It is listed here rather than quietly deleted, because a fleet you are asked to trust should show you what it chose not to load.
{
"mcpServers": {
"your-stdio-server": {
"command": "npx",
"args": ["-y", "your-mcp-server@1.0.0"],
// Only these env vars reach the child process. Not your whole environment.
"envFrom": ["YOUR_API_KEY"],
// Optional. Without it, state-changing tools are dropped automatically.
"allowedTools": ["your_read_tool"]
},
"your-remote-server": {
"url": "https://example.com/mcp",
// "streamable-http" (or "http") | "sse". Omit it and we try streamable
// HTTP first, then fall back to SSE.
"transport": "streamable-http",
// Header name -> the ENV VAR holding its value. Never the value itself:
// this file is committed, and a token in a committed file is a leaked token.
"headersFrom": { "Authorization": "YOUR_SERVER_TOKEN" }
}
}
}Why this is a weapon and not a liability
An agent that can call arbitrary tools over untrusted data is, by default, a security incident with a chat interface. Four things stop that, and all four are enforced in the server, outside the model's reach — because a guardrail the model can talk its way past is not a guardrail, it is a suggestion.
Mutating tools are stripped on sight
Every tool a server advertises is matched against a deny-pattern — send, transfer, sign, approve, swap, deploy, withdraw and their relatives. A matching tool is dropped before the model is told it exists. A server that wants one has to opt in by name in allowedTools.
MCP servers get a starved environment
Servers run as child processes and their output is untrusted. They never receive the whole process environment — no ROBINX_ENGINE_KEY, no AUTH_SECRET. Each server is handed only the variables it explicitly declared, on top of a minimal safe default. The one exception is deliberate and worth naming: if ROBINX_WALLET_KEY is set, it is declared by the robinx server and forwarded to it, because that is the process that settles x402 payments.
The agent holds no key of yours
Wallet login is a message signature and nothing else — no transaction, no gas, no allowance. When write and trade tools land, they will compile to an unsigned transaction that your wallet signs; there is no path by which Bugglo can move your funds.
Bugglo can operate one hot key of its own: ROBINX_WALLET_KEY pays for x402 tools in USDC. It is optional and off by default — the public deployment runs without it, which /api/health reports as paidToolsEnabled: false. Where it is enabled it should be a dedicated, low-balance wallet used for nothing else, because a key on a server is a key that can be stolen from that server.
A ceiling on what a thought may cost
Paid tools settle in USDC over x402. ROBINX_MAX_USD_PER_CALL bounds what any single call may spend. Leave the wallet key out entirely and a paid tool returns a price probe instead of data — it cannot spend money you did not hand it.
ROBINX_ENGINE_KEY=... # all three turn live mode on together;
ROBINX_ENGINE_URL=<base URL> # none has a default, so missing any one
ROBINX_ENGINE_MODEL=<model id> # missing any one makes chat unavailable
CHAT_TIMEOUT_MS=25000
ENGINE_USER_USD_PER_DAY=0.25 # the engine bills per token, so /api/chat
ENGINE_GLOBAL_USD_PER_DAY=5 # is metered — over a cap it returns 429
ROBINX_ALLOWED_TOOLS=robinx_verdict,robinx_token,robinx_deployer
ROBINX_WALLET_KEY=0x... # optional — enables paid tools
ROBINX_MAX_USD_PER_CALL=0.10 # the ceiling on any single callAnd when it breaks, the failure stays honest: a dead MCP fleet is marked tools offline, while a dead production engine returns unavailable instead of fabricated chain data.
An agent that buys its own data
Some RobinX tools are paid, settled in USDC over x402, mid-thought, without a human in the loop. The agent decides the forensics are worth ten cents and buys them. This is a small detail with a very large shadow: the moment an agent can pay for information, the price of an answer becomes a thing it can reason about — and the moment it can be paid, its answers become a thing other agents can buy.
We run the first half today. The second half — RobinX selling its verdicts to other agents, priced per call — is the machine economy this whole thing is pointed at, and it is in the research column below, where honest people put the things they have not built yet.
The ladder: read, then write, then act
Reading a chain is the floor, not the ceiling. The endgame is an agent you give an outcome to instead of an order — one that researches, decides, and executes inside a single loop, behind limits it physically cannot exceed.
Every rung below carries an honest status. Nothing here is dressed up as further along than it is, because the fastest way to kill a promise is to fake having kept it.
- TodayLive
Read — the chain, cross-examined
Six RobinX tools and an external MCP fleet, planned across by the model and checked against each other. This ships, right now, in production. Everything below is built on it.
Rug-check, deployer forensics, launch feed, leaderboard, token metadata, DEX liquidity.
- NextBuilding
Forensics — the lies a chart cannot tell
Holder clustering by funding path, bundler and sniper detection, wash-trade detection. Wallets funded from one source right before launch are not independent buyers, and early blocks expose patterns a chart hides.
chain_holder_graph, chain_bundle_scan, chain_wash_scan
- ThenPlanned
Write — launch from one sentence
Describe the token, pool, lock, and ownership policy. The agent assembles one reviewable bundle with verified source, simulates it, and hands it to your wallet. It never holds a key. It proposes; you sign.
token_deploy, token_lp_seed, token_lp_lock, token_ownership
- ThenPlanned
Trade — close the loop
Research and execution stop being two tabs. Quote the route, state the price impact, dry-run it against live chain state, show exactly what leaves the wallet — and only then offer it for signature. Nothing auto-fires.
trade_quote, trade_simulate, trade_swap, trade_approvals
- The betPlanned
Standing agents — a prompt that outlives the tab
"Watch this deployer. Wake me the second he launches again." The agent holds the watch after you close the laptop and pushes you the moment its condition trips. This is the line between a chatbot and something that works for you while you sleep.
Persistent intents, push delivery, condition triggers.
- The betPlanned
RobinX MCP as a server anyone can call
Flip the arrow. Today Bugglo is an MCP client that consumes tools. The prize is being the tool: point Claude Desktop, Cursor, or your own agent at RobinX MCP and call rug-check, deployer history, and chain state as primitives inside whatever you are building. Every agent that plugs in makes the chain more legible to every other one.
Public MCP endpoint, scoped keys, per-tool metering.
- ResearchResearch
Execution behind a ceiling the agent cannot argue with
"You may trade. You may not lose more than $200." An environment variable is not a guarantee — it is a suggestion enforced by the same process the agent runs in. A real ceiling is a number on-chain that the agent physically cannot exceed. That is a contract we have to write and have audited, and autonomous execution does not ship until it exists.
Spend-cap vault. Audited, or not shipped.
- ResearchResearch
Agent pays agent
x402 already lets the agent buy the premium forensics it needs mid-thought. Run it in reverse and RobinX sells its own verdicts to other agents, priced per call, settled in USDC. A machine economy where the unit of trade is a well-researched answer and the currency of reputation is being right in public.
x402 in both directions, on-chain verdict history.
The through-line: every rung makes the one above it safer to climb. You do not get to let an agent trade until it can read a launch well enough to know it is a trap, and you do not get to let it trade unsupervised until the worst case is a number on-chain rather than a promise in a config file. That order is not caution. It is the only order that works.
The six people actually ask
What is RobinX MCP?
RobinX MCP is a Model Context Protocol server that exposes Robinhood Chain as a set of tools an AI agent can call directly — token data, rug verdicts, deployer reputation, launch feeds, and leaderboards. Bugglo connects to it over stdio and lets the RobinX engine decide, on its own, which of those tools to call and in what order.
What is the Model Context Protocol?
The Model Context Protocol (MCP) is an open standard for connecting AI models to external tools and data. Instead of writing a bespoke integration for every model and every data source, a tool is published once as an MCP server and any MCP-capable client can call it. It is the difference between a model that talks about a blockchain and a model that can query one.
How is this different from a chatbot with a crypto API bolted on?
A chatbot calls one endpoint and repeats the answer. The agent plans a route across ten independent sources, executes it, cross-checks each claim against a second source, reports where they disagree, and reroutes when a tool fails. A clean verdict from a single source is worthless — the cross-examination is the product.
Can the agent move my funds?
No. Bugglo is a read-only intelligence agent today. Tools whose names imply a state change — send, transfer, sign, approve, swap, deploy — are stripped out before the model ever sees them, and the model can only see tools that appear on an explicit server-side allowlist. Write and trade tools, when they ship, will return an unsigned transaction that your wallet signs. The agent proposes; you sign.
Do RobinX MCP tools cost money?
Some tools are paid through x402 in USDC. Without a wallet key configured, a paid tool returns a price probe instead of data rather than silently spending anything. When a wallet key is configured, a per-call ceiling bounds what any single call may cost, enforced server-side and outside the model's reach.
Can I point my own agent at RobinX MCP?
Not yet — that is on the roadmap. Today Bugglo is an MCP client that consumes tools. Exposing RobinX MCP as a public server that Claude Desktop, Cursor, or your own agent can call is a planned capability, not a live one.
Point it at something
The tool surface, the reply contract, and the setup for live mode are in the main documentation. The capability ladder — written as the sentences you would actually type — is on the intro page. Or skip both and go ask it something with money on the line.