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.

📚 [API docs](https://madeonsol.com/api-docs) · 🤖 [Robinhood Chain](https://madeonsol.com/robinhood) · 💰 [Free API key](https://madeonsol.com/pricing)

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