Skip to main content
Glama
arambarnett

robinhood-chain-mcp

by arambarnett
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

robinhood-chain-mcp

The intelligence layer for Robinhood Chain agents. An MCP server any Claude / agent can query against live Robinhood Chain (chain id 4663) data: tokens, wallets, Chainlink feeds, heat scores — and the one signal nobody else surfaces: live tracking error on tokenized equities.

Robinhood's official Trading MCP (agent.robinhood.com/mcp/trading) gives agents hands — portfolio reads and order placement on the brokerage. This server gives them eyes on the chain itself: what's hot on the L2, who holds it, and whether a tokenized stock is trading rich to its Chainlink feed. Different layer, same agent config — the eyes find the premium, the hands place the order, the human approves.

you  → "is NVDA on Robinhood Chain trading rich to the real stock?"
agent → entity_signals("nvda")
      → { market_price_usd: 202.62, feed_price_usd: 202.615, premium_bps: 0,
          feed_age_seconds: 15188, score: { value: 73, label: "hot" } }

Zero API keys. Read-only by construction — public Blockscout GETs and RPC eth_call only. No signing, no positions, no money.

Running in 5 minutes

git clone https://github.com/arambarnett/robinhood-chain-mcp
cd robinhood-chain-mcp && npm install && npm run build

# Claude Code
claude mcp add robinhood-chain -- node $(pwd)/dist/index.js

# or any MCP client (stdio)
node dist/index.js

# or remote (streamable HTTP, stateless, rate-limited)
MCP_TRANSPORT=http PORT=8080 node dist/index.js

Then ask your agent things like "what's hot on Robinhood Chain right now", "who are the top holders of tokenized TSLA", or "map the whole ecosystem" — the full-chain index (every ERC-20, risk-flagged and scored) is also served as a plain JSON API with a visual map at labs.arambarnett.com/demo/robinhood (/api/rhc-ecosystem).

Running it next to Robinhood's official Trading MCP closes the loop — intelligence from the chain, execution on the brokerage:

{
  "mcpServers": {
    "robinhood-chain": { "command": "node", "args": ["/path/to/robinhood-chain-mcp/dist/index.js"] },
    "robinhood-trading": { "url": "https://agent.robinhood.com/mcp/trading" }
  }
}

Related MCP server: rhc-mcp

The four tools

Tool

Question it answers

Example

lookup_entity

who/what is X?

"NVDA" → official tokenized equity, contract, price, holders, its Chainlink feed

entity_connections

what is X connected to?

token → chain, feed, underlying equity, top holders; wallet → holdings

related_markets

what moves with X?

"top" → the heat board; "ecosystem" (or "ecosystem:community") → the full-chain index; a token → its feed + category peers

entity_signals

is anything happening?

heat 0–100 with components + premium_bps vs the Chainlink feed

Receipts (live values, 2026-07-10)

  • Heat board: USDG 96/100 · Ethena USDe 90 · WETH 81 · Cash Cat (yes, a memecoin) 80

  • Tracking error: NVDA token +0 bps vs its onchain Chainlink feed — arbitrage-tight 9 days after launch

  • The chain: 762,748 addresses, 101ms blocks, average gas 0.11 gwei

  • Coverage: every ERC-20 on the chain resolves by contract address (RAS §7 — permissionless, no allowlist), ~100 kept warm in the 60s cache, 42 Chainlink USD feeds mapped — and the memecoin economy included: a token named 🪶 has a third of all addresses holding it

  • Onchain: BuildReceipt.sol deployed & source-verified on Robinhood Chain testnet — cast call 0x09B7764F47C682225d641c7144Ec82BFF436C934 "MESSAGE()(string)" reads this repo's URL back from the chain

How the score works

Heat 0–100, components always spelled out, never hidden: 24h volume (40) + holders (25) + market cap (20) + oracle-backed (15).

Freshness doctrine: every response carries as_of and stale_seconds. The token universe cache is 60s — answers are never more than a minute behind the chain and say exactly how far behind they are. Stock feeds run 24/5; off market hours the feed age is reported honestly (feed_age_seconds), not hidden.

Why premium_bps matters

Tokenized equities have two prices: the onchain market price (what the token trades at) and the Chainlink feed (underlying share price × Robinhood's corporate-action multiplier). The spread between them is the token's tracking error. Wide premium = demand outrunning mint capacity; wide discount = exits outrunning redemption. It's computed live, per query, from both sources.

Standard

This server is the reference read-plane implementation of the RHC Agent Schema — an open MIT standard for MCP agent tooling on Robinhood Chain (common entity types, object shapes, read-vs-execute separation, freshness and neutrality rules). Per the standard's §7: indexing is permissionless — any token on the chain resolves by contract address, no allowlist, and every score's components are disclosed. Build a conforming server (launch tooling, DEX routing, portfolio analytics…) and it composes with this one in the same agent toolbelt automatically.

Architecture

Everything domain-specific lives behind one interface (src/adapter.ts) — the MCP layer (tools, transports, rate limiting) is vertical-agnostic. This same server core fronts a prediction-market graph, a creator-matching graph, and an inbox relationship graph at Barnett Labs. A new vertical is ~150 lines. This repo's vertical is src/adapters/robinhoodChain.ts.

Data sources: Blockscout REST · rpc.mainnet.chain.robinhood.com · Chainlink AggregatorV3 proxies (source of truth).

contracts/ holds the Foundry toolchain-validation contract for the chain.

Not investment advice

Showcase infrastructure. Scores describe onchain activity, not asset quality.

Built by Barnett Labs — the lab takes two builds a quarter. MIT.

Available Tools

4 tools
entity_connectionsA

Get the typed relationship neighborhood of an entity: who it supplies, plays for, leads, owns, is allied with, etc. Each edge carries a relationship type, confidence score, and temporal validity. Use depth 2 to find second-order connections (the suppliers of the supplier).

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesCanonical entity slug from lookup_entity
depthNoTraversal depth (default 1, max 2)
limitNoMax connected nodes (default 25)

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that edges include relationship type, confidence score, and temporal validity, and mentions depth limits. Adequate for a read-only traversal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with main purpose, no filler. Every sentence provides essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema but description explains edge attributes. For a moderate-complexity tool with 3 params, the description is sufficiently complete without gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by explaining 'typed relationships' and providing a usage example for depth, going beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states the tool retrieves typed relationship neighborhood with concrete examples (supplies, plays for, etc.), clearly distinguishing from sibling tools like lookup_entity and related_markets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on using depth 2 for second-order connections. Lacks explicit when-not-to-use but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

entity_signalsA

Get the current signal picture for an entity: signal-quality score, sentiment across time windows, and recent high-impact events with impact scores. Use it to check whether something is moving before acting on a connection.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesCanonical entity slug from lookup_entity

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It implies read-only operation but does not disclose data freshness, pagination, or error handling. Lacks some behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with key information, no wasted words. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should detail return structure more. Lists components but lacks format details. Adequate but leaves some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear description for 'slug'. Description adds no extra meaning beyond the schema; baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Get the current signal picture for an entity' with specific components (signal-quality score, sentiment, events). It distinguishes from sibling tools like entity_connections and lookup_entity by focusing on signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use case: 'check whether something is moving before acting on a connection.' This helps with when to use, though it does not explicitly state when not to use or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_entityA

Resolve a name, ticker, or topic to a canonical entity in the knowledge graph. Returns entity type, category, tags, and key attributes with source provenance and confidence. Start here — other tools take the returned slug.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesEntity name, ticker, or topic — e.g. "Nvidia", "Donald Trump", "BTC"

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses return contents: entity type, category, tags, key attributes with provenance and confidence. No annotations exist, so description bears full weight; it covers essential behavioral aspects for a read-only lookup.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy. First sentence states purpose and output; second provides usage guidance. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully adequate for a simple one-parameter tool with sibling tools described. Provides entry point guidance and output overview despite no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a detailed example for the single 'query' parameter. The tool description reiterates the parameter purpose but adds no new semantic detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb and resource: 'Resolve a name, ticker, or topic to a canonical entity in the knowledge graph.' It also distinguishes from sibling tools by noting 'other tools take the returned slug.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to 'Start here — other tools take the returned slug,' indicating this tool is the entry point for entity lookups before using siblings like entity_connections.

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.

  1. 4 tool updatesv0.1.0
    • First observedentity_connections
    • First observedentity_signals
    • First observedlookup_entity
    • First observedrelated_markets
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: lookup_entity resolves entities, entity_connections retrieves relationships, entity_signals provides sentiment/events, and related_markets finds exposed markets. No overlap.

Naming Consistency4/5

All tool names are two-word descriptors with underscores, but the part-of-speech order varies (noun_noun for entity_connections, verb_noun for lookup_entity). Mostly consistent but not perfectly uniform.

Tool Count4/5

Four tools is reasonable for a read-only knowledge graph service focused on entity lookups, relationships, signals, and market exposures. Slightly thin but each tool earns its place.

Completeness4/5

The set covers the main capabilities: entity resolution, relationship exploration, signal monitoring, and market discovery. Minor gaps like historical data or advanced filtering are absent but not critical for the core use case.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • r0x-os

    nhevers
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to interact with Robinhood Chain via USDG payments, offering tools for balance, pricing, trading, and more.
    18
    63
    MIT

  • rhc-mcp

    jumpboxtech
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to read Robinhood Chain stock-token positions, quote swaps, and execute swaps through the Model Context Protocol, bridging on-chain assets that Robinhood's own off-chain MCP cannot reach.
    4
    MIT

  • loxcorp

    loxcorp
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides live, read-only access to Robinhood Chain and Lox Corp data, enabling AI agents to query chain stats, token launches, agent details, and more.
    10
    1
    MIT