The weapon

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.

6 tools
RobinX MCP, callable in production today.
9 servers
External MCP fleet, cross-checking each other. Not all are answering — the table below says which.
0 keys held
Read-only. The agent has nothing to sign with.
The idea

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 source, the liquidity lock, the holder concentration, and the deployer's history, called four different tools to get them, noticed that two of them disagreed, 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.

How it thinks

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.

01

Observe

What is being asked, what is already known, and what is missing. The agent names the gap before it moves to fill it.

02

Analyze

Patterns, anomalies, risks, opportunities. The shape of the question decides which tools are even worth calling.

03

Plan

Which tool first, in what order, and — the part most agents skip — what to do when one of them fails.

04

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.

05

Verify

Cross-check every claim against an independent source and report where they disagree. A clean verdict from one source is worthless.

06

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 DexScreener's liquidity against the chain's own balance, the honeypot flag against an actual transaction trace, the holder graph against the deployer's funding trail — 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 is a demo.

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.

The tools

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_verdict

Is this safe? The composite rug-check. Contract source, honeypot behaviour, LP lock state, and the powers ownership still holds — folded into one verdict with the evidence still attached to it.

Live
robinx_token

What is this token, really? Supply, liquidity, holder spread, and lock state for any token on the chain. The numbers a chart is drawn on top of, before anyone has drawn the chart.

Live
robinx_deployer

Who 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.

Live
robinx_stats

Have they done this before? Deployer reputation across their full deployment history. Six launches, one honeypot, and a pattern you can see before you are inside it.

Live
robinx_feed

What 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.

Live
robinx_leaderboard

What is moving? Ranked movement across the chain. Volume next to liquidity, because volume without liquidity is a trap with a chart on it.

Live

The 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.

The tools

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.

ServerWhat it is forTransportState
dexscreenerPrice, volume, liquidity, pair-level market datastdioOn
boo-cryptoRug-check, honeypot behaviour, sanctions screeningstdioOn
boar-basicGeneral chain intelligence — the cheap first passstreamable-httpOn
boar-advancedDeeper forensics when the first pass finds somethingstreamable-httpOn
fuseCross-chain context for anything with a bridge in its paststreamable-httpOn
hooddomains.hood name resolution, so wallets have namesstdioOn
etherscanContract source and ABIs — needs an Etherscan API keystdioNeeds key
whale-intelHolder analysis, whale tracking, wallet clustersstreamable-httpNeeds key
blockscoutContract source, ABIs, transactions, deployer trailstreamable-httpNot answering
hoodpocketWallet operations — deliberately switched offstdioOff

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.

mcp.json — adding a server
{
  "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" }
    }
  }
}
The guardrails

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 process environment — no ROBINX_ENGINE_KEY, no AUTH_SECRET, no wallet key. Each server is handed only the variables it explicitly declared, on top of a minimal safe default.

The agent holds no keys

Read tools run server-side. When write and trade tools land, they compile to an unsigned transaction that your wallet signs. There is no custody path, which means there is no key here to steal.

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.

.env.local — the whole live-mode surface
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>        # leaves the route on the demo agent
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 call

And when it breaks — a dead server, a timeout, a malformed reply — the response degrades to the demo agent rather than to a stack trace. The user gets a worse answer. Never a broken page.

The strange part

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.

Where this goes

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.

Live callable todayBuilding half-wired, landing soonPlanned designed, not startedResearchneeds primitives that don't exist yet
  1. 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, holder spread, honeypot behaviour.

  2. NextBuilding

    Forensics — the lies a chart cannot tell

    Holder clustering by funding path, bundler and sniper detection, wash-trade detection. Forty independent buyers who all took gas from one wallet six minutes before launch are not forty buyers — they are one entity wearing forty hats, and the first three blocks of a launch cannot lie about it.

    chain_holder_graph, chain_bundle_scan, chain_wash_scan

  3. ThenPlanned

    Write — launch from one sentence

    "Launch MYTOKEN, 1B supply, LP locked 12 months, ownership renounced." The agent assembles the deploy, the pool, the lock, and the renounce into 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

  4. 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

  5. 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.

  6. 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.

  7. 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.

  8. 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.

Questions

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.

Try Bugglo