Robinhood Chain

mcp-server-robinhood-chain

Agent Intelligence Gateway (new in 0.15.0, opt-in). Set MADEONSOL_AGENT_GATEWAY_ENABLED=on together with a paid (PRO or higher) MADEONSOL_API_KEY to add six research tools fixed to robinhood-chain: discover_opportunities, evaluate_token, inspect_wallet, inspect_deployer, evaluate_signal and changes_since. They call POST /api/v1/agent-gateway/actions with your key and never sign or pay an x402 request. RHC limits are explicit: evaluate_signal reports the Signal Scorecard as unsupported on Robinhood Chain (there is no verified RHC equivalent), and changes_since covers three curated KOL/deployer event families, not every swap. Without the opt-in the tool inventory is unchanged. A hosted endpoint is also available at https://madeonsol.com/api/agent-gateway/mcp (Bearer msk_ key, no MCP OAuth). Gateway contract.

The hosted /api/agent-gateway/mcp transport uses per-request account keys and custom Authorization headers. It does not implement MCP OAuth; do not expose this package's private loopback HTTP adapter as a public service.

[npm version] [npm downloads] [MCP] [License: MIT]

📚 API docs · 🤖 Robinhood Chain · 💰 Free API key

Robinhood Chain MCP server — EVM-native on-chain trading intelligence for AI agents, chain id 4663.

Give Claude, Cursor, or any MCP client direct access to Robinhood Chain (an Arbitrum Orbit L2) trading data from our self-hosted RHC node: real-time KOL trades plus coordination and first-touch discovery signals, the full Uniswap v2/v3/v4 DEX trade tape, token discovery with launch-bundle + early-buyer-quality detection (single and batch), 1-minute OHLC candles, deployer reputation across 99k+ ranked deployers (leaderboard, alerts, trajectory, per-deployer launch history), and smart-money wallet ranking — plus full CRUD over the RHC rule engines: copy-trade rules, market-cap dip/recovery price alerts, KOL-coordination alerts and first-touch push subscriptions, all with per-chain quotas. Every tool is EVM-native — lowercase 0x addresses, eth_amount, tx_hash, block_number, net_flow_eth. The KOL→EVM mapping is recovered by tracing each Solana KOL's bridge deposits (deBridge / Relay / Mayan / Wormhole), a dataset unique to MadeOnSol.

RHC coverage is bundled into every tier at no extra cost. Get a free API key (200 req/day, no card) at madeonsol.com/pricing.

0.8.1 — version alignment with the wider RHC SDK release: WebSocket stream tokens (POST /api/v1/stream/token) never expire since 2026-08-27 — the same token comes back on every call, expires_at / next_refresh_at are always null, and only an explicit {"rotate": true} replaces one. This MCP server exposes REST tools, not WebSocket channels, and has no stream-token tool, so no tool behavior changed.

0.5.0 — version alignment with the wider RHC SDK release: the stream channel names were corrected in the TS/Python/Rust SDKs (the RHC firehose channel is rhc:dex_trades; the server accepts rhc:trades only as a deprecated alias of it). This MCP server exposes REST tools, not WebSocket channels, so no tool behavior changed — the rhc_trades tool (the GET /rhc/trades tape) is unaffected.

Key-mode only. Authenticate with an msk_ Bearer API key (MADEONSOL_API_KEY). Robinhood Chain does have a keyless x402 pay-per-call rail — now 10 endpoints (grew from the original 6), documented at madeonsol.com/robinhood/x402 — but it is not part of this server.

Server update 2026-10-04 (no package change needed): RHC copy-trade rules follow any valid source wallet. source_wallets no longer have to be tracked KOL wallets (/rhc/kol/wallets): any valid 0x wallet fires, KOL membership is optional enrichment, and copy-trade sources do not use Wallet Tracker quota. Each rule reports source_admission (any_wallet) and operational_state (eligible, or an infrastructure state monitoring_pending / monitoring_unavailable / source_capacity_unavailable). source_wallets_tracked / source_wallets_untracked, no_tracked_sources and the untracked_source_wallets warning are legacy, still filled. Existing rules work without editing. Limits are unchanged: PRO 3 rules × 5 wallets, ULTRA 20 × 50, BUSINESS 100 × 250.

New in 0.16.1: the family hint on the token lock tools lists stonkbrokers-vesting (StonkBrokers Safety Deposit Box vesting), accepted by the API since 2026-10-19. Hint only, no tool change.

New in 0.16.0: bundles over time, bundled-now share, KOL trades per token, scout leaderboard, developer activity (73 tools total). Five new read-only tools. rhc_token_bundles (GET /rhc/tokens/{address}/bundles) lists every coordinated buy cluster on a token, launch and later, with held-now and, for followed clusters, exit progress. rhc_token_bundle_share (GET /rhc/tokens/{address}/bundle-share) gives the share of total supply held right now by every bundle account, from balanceOf on our node; null with a reason unless every account was read. rhc_token_kol_trades (GET /rhc/tokens/{address}/kol-trades) returns every tracked-KOL trade on one token. rhc_kol_scout_leaderboard ranks KOLs that are first into tokens other KOLs then follow. rhc_deployer_activity (GET /rhc/deployer-hunter/{address}/activity) is a developer's launch, dev-buy and dev-sell timeline with exact raw amounts. New opt-ins on existing tools: include_balances (rhc_token_bundle, rhc_token_buyer_quality), verify_current_balances + include_scout_scores (rhc_token_early_buyers), include_wallet_flags (rhc_token_holders), include_launches_24h (rhc_deployer_tokens), include_performance (rhc_kol_profile), sort + min_closed (rhc_kol_leaderboard). Additive only.

New in 0.13.0: token lock provenance. Tool descriptions: Token lock rows carry provider (identity decided by the locker contract address: verified only for known provider deployments; compatible = ABI match, operator not identified, no id / website / lock_url), explorer (Blockscout links), price_usd, seconds_until_end, seconds_until_next_unlock (server 2026-10-02). RHC withdrawals stay untracked (withdrawn null); LP rows never get usd / price / %. Additive only. rhc_token_locks accepts cursor (strict keyset paging).

New in 0.11.0 — BREAKING: HTTP mode now requires a separate token (security fix, SEC-02). If you run this server with MCP_TRANSPORT=http, you must now also set MCP_HTTP_TOKEN (a random secret you generate) and send it as Authorization: Bearer <token> on every request, including GET /health and the server-card endpoint — previously, anything that could reach the bound port could call every tool using the operator's own credentials with no authentication at all. HTTP mode is now hard-restricted to literal loopback (127.0.0.1 / ::1), rejects Origin/X-Forwarded-* headers and duplicate Authorization/Host headers outright, exposes only POST /mcp plus the two GET routes, and refuses to start if a wallet/payment credential is configured. If you use the default stdio transport (Claude Desktop, Cursor, most MCP clients), nothing changes — no action needed. This is a single shared-operator-token fix, not a new multi-user or OAuth system. Full writeup: docs/audit/SEC02_PRIVATE_HTTP_MCP.md.

New in 0.10.1 — the server now reports MCP instructions. The initialize response's instructions field (operational guidance for the calling agent — distinct from this README/package description) was never set; directories that introspect the live server (Glama) reported "no recorded MCP instructions." No new tools; still 68 total.

New in 0.10.0 — token locks & vesting (68 tools total at the time). Three new tools, shipped 2026-09-15 and only now documented here (the code shipped without a version bump or a changelog line, so this README kept saying 65 while the server had actually registered 68 — checked going forward by scripts/verify-mcp-tool-counts.mjs in the main repo). rhc_token_locks (PRO+) is the newest-first feed of lock/vesting contracts created across every token — PinkLock-compatible, HoodLock, Team Finance-compatible, Titan, UNCX-compatible LP lockers and Sablier v4, decoded from our own node. rhc_token_lock_summary (PRO+) rolls every lock on ONE token into a live "did the team lock, how much, until when, can they cancel" view. rhc_token_unlocks (PRO+) lists upcoming unlock events chain-wide inside a 1h–90d window. All three are create-only: withdrawals and cancels are not tracked by any RHC locker's on-chain events, so withdrawn is always null (unknown), never 0 — never present a lock as "still held" beyond what the schedule says.

New in 0.9.0 — early buyers (65 tools total at the time). rhc_token_early_buyers (GET /rhc/tokens/{address}/early-buyers, PRO+) — first buyers of a token, ranked, with still-holding status. Found by an internal agentic-infra coverage audit as the one RHC capability unreachable from every agent surface, not just this one.

New in 0.8.0 — tokenized equities + the liquidity-removals feed. Two new tools. rhc_equities (GET /rhc/equities, BASIC) lists every official Robinhood tokenized stock and ETF (NVDA, SPY, AAPL, …) with live price / MC / liquidity and 24h trades, ETH volume and buyer-seller split, sortable by volume / trades / market_cap / last_trade / symbol, filterable by exact symbol or substring q. Identity is the issuer beacon, never the name: a token is listed only if its contract is an EIP-1967 beacon proxy on Robinhood's issuer beacon 0xe10b6f6b…151b00, read from our own node — on ship day there were 20 fake "GameStop • Robinhood Token" contracts and 8 fake NVDAs with the exact official suffix, and none of them appear. rhc_lp_events (GET /rhc/lp-events, PRO+) is the rug signal: Uniswap v2/v3 Burn and v4 ModifyLiquidity with a negative delta on tracked pools, from our node's log subscription, filterable by token / pool / provider / dex and cursor-paginated on next_before. Removals only — adds are not persisted (the response's coverage block says adds_persisted: false), amounts are raw uint256 strings, v4 rows carry liquidity only, and provider_is_token_deployer is the classic rug tell. Data since 2026-08-05.

New in 0.7.0 — holder_growth: who arrived and who left. The rhc_token_holders tool now returns holder_growth on GET /rhc/tokens/{address}/holders: { "1h", "24h", "7d" } × { cutoff_block, entered, entered_still_holding, exited, net }. entered = addresses whose first Transfer of the token landed at-or-after the window's cutoff block (any current balance); entered_still_holding = those still non-zero; exited = pre-existing holders whose last movement in the window left them at zero; net ≈ the change in holder_count. Pools and burn addresses are excluded from every count. This exists because RHC balances are folded from ERC-20 Transfer logs on our own node — the fold keeps first-seen and last-moved blocks per address and retains zero-balance rows — so it is a direct read, not an estimate; the Solana census is a point-in-time ledger scan with no history and cannot answer this. A window is null (never 0) only when the chain had no ingested trades in it; the whole block is null only if the growth read failed. Sanity check from ship day: a token launched that morning showed 593 entered / 560 still holding over 24h, and holder_count was exactly 560.

New in 0.6.0 — wallet intelligence. Ten new operations covering the Robinhood Chain wallet surface, which had no SDK binding at all until now: rhc_wallet, rhc_wallet_pnl, rhc_wallet_positions, rhc_wallet_trades, plus the watchlist tools — rhc_wallet_tracker_list, rhc_wallet_tracker_add, rhc_wallet_tracker_remove, rhc_wallet_tracker_relabel, rhc_wallet_tracker_trades and rhc_wallet_tracker_summary. Everything is ETH-denominated, and cost basis is FIFO over a rolling 90-day window — cost_basis_observable_from names the date the window opens, so a position opened before it reads as a sell with no matching buy. The profile / PnL / positions trio shares ONE snapshot cache server-side, so calling all three on an address costs roughly one computation rather than three; cache_hit says which call paid for it. Watchlist quotas are per chain (PRO 50 / ULTRA 250 / BUSINESS 1,000 RHC wallets), independent of your Solana list.

Install & configure

Add to your MCP client config (Claude Desktop, Cursor, Claude Code). No install step — npx fetches it on first run:

{  "mcpServers": {    "robinhood-chain": {      "command": "npx",      "args": ["-y", "mcp-server-robinhood-chain"],      "env": {        "MADEONSOL_API_KEY": "msk_your_api_key_here"      }    }  }}

Then ask your agent things like "What are tracked KOLs buying on Robinhood Chain right now?" or "Score the early-buyer cohort for token 0x… on chain 4663."

Transports

• stdio (default) — for local clients (Claude Desktop, Cursor, Claude Code).
• http — optional private, API-key-only adapter for one trusted operator on loopback. See the access requirements below; public hosting is unsupported.

Private HTTP transport (SEC-02)

Stdio remains the default for Claude Desktop, Cursor and other local MCP clients. HTTP now requires an explicit private-operator configuration; previously unauthenticated HTTP launch settings will fail closed.

1. Set MADEONSOL_API_KEY to the operator's msk_ key.
2. Generate a separate random access token, for example node -e "console.log(require('node:crypto').randomBytes(32).toString('base64url'))", and store it as MCP_HTTP_TOKEN. Do not reuse the upstream API key or put either credential in a URL.
3. Set MCP_TRANSPORT=http, HOST=127.0.0.1 (default, or ::1) and optionally PORT (default 3100). Non-loopback bindings, missing credentials and any SVM_PRIVATE_KEY or RHC_PAYER_KEY are refused before startup. Solana wallet/x402 mode remains available through stdio.
4. Connect to http://127.0.0.1:3100/mcp with Authorization: Bearer <MCP_HTTP_TOKEN> on every request, plus the normal MCP Content-Type and Accept headers. Use stdio if the client cannot attach headers. The local token is checked by the MCP adapter; only MADEONSOL_API_KEY is sent upstream.

Only POST /mcp, GET /health and GET /.well-known/mcp/server-card.json are exposed, all authenticated. / and arbitrary paths are no longer MCP endpoints. The adapter is stateless: it does not issue session IDs, rejects supplied Mcp-Session-Id, and returns 405 for GET/DELETE on /mcp. Host must be the selected loopback literal with its port, or localhost with that exact port. Browser Origin headers, forwarded/proxy headers and cross-origin requests are rejected; no CORS access is granted.

Limits: 256 KiB uncompressed JSON bodies, 8 KiB headers, a 10-second body-upload deadline, and 16 active authenticated requests. Oversized or malformed inputs are rejected before tool dispatch. This is not an overall tool-execution deadline; an upstream action already submitted may continue after a disconnect.

Everyone holding the local token acts as the same operator, including access to that operator's mutation tools. This is not a multi-user/OAuth server: do not put it behind a public proxy, share it with untrusted users or expose a funded signer. Separate users require isolated processes/credentials or a future transport that authenticates each principal and maps their own credentials. Restart with a new MCP_HTTP_TOKEN to rotate access.

The Docker image uses the same loopback restriction and requires both environment credentials. Its healthcheck authenticates without putting the token in the URL. It does not support a publicly published Docker port; use stdio or a client in the same trusted network namespace.

Tools — all 64 Robinhood Chain routes

Each tool maps 1:1 to a Robinhood Chain v1 API route. 49 are reads (GET, plus the two batch tools which POST an address list only because it is too long for a query string) and 15 genuinely write (POST / PATCH / DELETE on the rule engines, plus the three wallet-watchlist mutations) — those are marked ✍️ / 🗑️ below and carry non-readOnly MCP annotations, so a well-behaved client will not call them speculatively. Fields are EVM-native.

Reads

Writes — rule engines

These mutate server state, consume per-tier quota and fire webhooks. They are annotated readOnlyHint: false; the deletes additionally carry destructiveHint: true. Creates are not idempotent — calling one twice makes two rules and can hit the cap with a 409.

Rule-engine quotas are PER CHAIN. A full set of Solana copy-trade rules, price alerts, coordination rules or first-touch subscriptions does not consume your RHC allowance, and vice versa.

BASIC works with any valid key. PRO+ tools return HTTP 403 on a BASIC key — upgrade at madeonsol.com/pricing.

Five things agents get wrong

• RHC price alerts fire within a few seconds, not sub-second. Since 2026-09-15 they are evaluated as trades land on the chain trade feed (rhc:dex_trade), with price-table polls (5 s / 60 s) and a trade-tape replay as safety nets; the floor is the chain trade flush (about 2 s). Do not promise parity with the Solana price alerts, which are sub-second. The create response's evaluation block reads mode: "event_driven". fired_at on an event is when the evaluator observed the move, not the on-chain moment.

• RHC copy-trade has no market-cap band. There is no min_mc_usd / max_mc_usd on a copy-trade rule, unlike the Solana engine, because the RHC KOL trade event carries no market cap — the filter would need a per-event DB read on a ~3.3M-trades/day chain, or it would silently never match. Filter on min_trade_eth and only_action instead.

• trader_eoa is not simply tx.from. It is the effective trading account: tx.from on an ordinary transaction, but the ERC-4337 userOp sender (UserOperationEvent) when the trade was bundled — never the bundler that relayed the batch, and never the router. It is still an EOA either way; on Robinhood Chain a userOp sender is an ordinary EOA carrying an EIP-7702 delegation, not a smart-contract wallet. Attribute trades and rank wallets on trader_eoa; the separate trader field is only the swap-log recipient, which is the router on aggregated swaps.

• rhc_deployer_alerts filters for tradability by default. Alerts on tokens with liquidity_usd under $100 (including unknown liquidity) are dropped — a $45K-MC alert on a drained $68 pool is not a signal. Pass include_untradeable: true for the raw tape; the response always echoes the active tradability_filter. The alert's tier is resolved from the live reputation view at read time, so it can never advertise a reputation the deployer has since lost — the snapshot taken when the alert fired is returned separately as tier_at_alert, with tier_is_stale flagging the drift.

• graduation_rate no longer sets the tier. It still means the $40K peak-MC bar and is still returned everywhere, but elite/good are earned on runner_rate ($100K) plus 24h of deployer history. Ranking deployers by graduation_rate is ranking them on a metric the tier ignores.

Why Robinhood Chain

Robinhood Chain is dual-natured — launchpad memecoins (pons / flap / clanker / hood.fun / virtuals) alongside tokenized stocks and stablecoins. Most launchpads are direct-to-DEX (no bonding curve), so "graduation" is a market-cap milestone: graduation_rate = share of a deployer's tokens that reached a $40K+ peak MC, runner_rate = share that reached $100K+. The elite/good tier rides runner_rate and requires 24h of deployer history (elite = 5+ tokens, 24h+ old, runner_rate >= 0.50; good = >= 0.25) — graduation_rate is still reported but no longer sets the tier, since the $40K bar proved farmable; only spammer still keys off it (20+ tokens, graduation_rate < 0.05). Because it's an Arbitrum Orbit L2 with no atomic multi-signer transaction, a detected launch bundle is same_block (there is no atomic_tx).

Links

• 🤖 Robinhood Chain overview — https://madeonsol.com/robinhood
• 💰 Pricing & free API key — https://madeonsol.com/pricing
• 📚 API docs — https://madeonsol.com/api-docs

License

MIT © MadeOnSol