Integrates Chainlink price feeds to provide stock quotes and premium/discount data for tokens on Robinhood Chain.
Provides tools to interact with Robinhood Chain: query stock tokens, memecoins, chain stats, portfolio, trending coins, recent launches, and perform guarded trades (swaps, transfers) via Uniswap with spend caps and confirm gates.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hood-mcp what are the trending coins?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol servers for Robinhood Chain (chain ID 4663).
Two servers, one package: a zero-config data server any MCP client can add in one line, and
an explicitly opt-in trading server for wallets that want to act. Built on
hoodchain, the TypeScript SDK for the chain.
Docs: https://nirholas.github.io/robinhood-chain-mcp/
Robinhood Chain has two other MCP servers today, both zero-star, days-old, read-only hobby projects. This is the productized one: a full data surface (Stock Tokens, memecoins, launches, chain stats) plus a guarded trading surface with hard spend caps and a confirm gate — built to the standard three.ws holds its agent tooling to.
Related MCP server: robinhood-chain-mcp
claude mcp add hood-mcp -- npx -y hood-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"hood-mcp": {
"command": "npx",
"args": ["-y", "hood-mcp"]
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"hood-mcp": {
"command": "npx",
"args": ["-y", "hood-mcp"]
}
}
}npx -y hood-mcpNo API key, no wallet, no config. It talks to the public Robinhood Chain RPC and starts answering tool calls immediately.
hood-mcp — data server (zero-config, read-only)stdio by default; pass --http (or HOOD_MCP_TRANSPORT=http) for Streamable HTTP on
HOOD_MCP_PORT (default 8730), serving POST /mcp and GET /health.
Tool | What it does |
| Latest block, gas price, TVL, network totals. |
| The 95-token Stock Token registry (ticker, name, contract, feed). |
| Chainlink price + Uniswap DEX price + premium/discount + share price for a ticker. |
| Multiplier-correct Stock Token portfolio + USDG balance for any address. |
| Price/volume/liquidity/holders for any token by address (memecoin or Stock Token). |
| The chain's trending pools right now. |
| Recent NOXA + The Odyssey launches, scanned from on-chain logs. |
| Watch live for new launches for up to 120s. |
| Find a token by ticker, name, or address. |
HOOD_MCP_NETWORK=mainnet # or testnet — default mainnet
ALCHEMY_KEY= # optional: private RPC instead of publichood-mcp-trading — wallet server (explicitly opt-in)Separate binary, stdio only, refuses to start unless both are set:
HOOD_MCP_ENABLE_TRADING=1
ROBINHOOD_CHAIN_PRIVATE_KEY=0x...{
"mcpServers": {
"hood-mcp-trading": {
"command": "npx",
"args": ["-y", "hood-mcp-trading"],
"env": {
"HOOD_MCP_ENABLE_TRADING": "1",
"ROBINHOOD_CHAIN_PRIVATE_KEY": "0xYOUR_KEY"
}
}
}
}Tool | What it does |
| This wallet's ETH, USDG, and Stock Token positions. Read-only. |
| Quote a Uniswap swap without signing. Read-only. |
| Guarded. Preview → |
| Guarded. Preview → |
See Safety model for the full guard design. Summary:
Kill switch — the server process itself refuses to start without HOOD_MCP_ENABLE_TRADING=1.
Eligibility gate — buying a tokenized Stock Token requires HOOD_MCP_ACKNOWLEDGE_ELIGIBILITY=1
(Stock Tokens are barred to US/Canada/UK/Switzerland persons — see below).
Spend caps — every mutating call is valued in USD and checked against
HOOD_MCP_MAX_SPEND_USDG (per-call) and HOOD_MCP_MAX_SESSION_USDG (per-session,
in-memory, resets on restart) before anything is signed.
Confirm gate — the first call to execute_swap / transfer_usdg always returns a
simulation (recipient, amount, token, min-received) and signs nothing. Only a second call
with confirm: true and identical arguments broadcasts.
HOOD_MCP_MAX_SPEND_USDG=25 # default 25 — per single call
HOOD_MCP_MAX_SESSION_USDG=100 # default 100 — cumulative for the process lifetime
HOOD_MCP_ACKNOWLEDGE_ELIGIBILITY=0 # set to 1 ONLY if eligible to hold Stock TokensStock Tokens are tokenized debt securities (issuer: Robinhood Assets (Jersey) Ltd) and may
not be offered, sold, or delivered to US persons (additional limits: Canada, UK, Switzerland).
The restriction is legal/front-end enforced, not contract-level — execute_swap throws unless
the operator has explicitly acknowledged eligibility. Memecoins are unrestricted.
See .env.example for the full annotated list. Nothing is required for the
data server; the trading server requires the two kill-switch variables above.
The HTTP transport has a documented seam (src/x402-seam.ts) to paywall future metered tools
(deep history, firehose) via the sibling hood402 USDG-on-Robinhood-Chain x402
rail once it exists. Every tool this package ships today stays free regardless.
npm install
npm run build # tsup → dist/
npm run dev:data # tsx src/data-server.ts (stdio)
npm run dev:trading # tsx src/trading-server.ts (stdio, needs env)
npm test # hermetic: schema + guard tests (real network reads, no wallet funds)
npm run test:live # live: every data tool against real mainnet 4663 data
npm run test:swap # live, gated: a REAL testnet swap through execute_swap (needs a
# faucet-funded ROBINHOOD_CHAIN_PRIVATE_KEY — see the test file)Depends on hoodchain from npm; for local development against an unpublished SDK checkout:
npm i ../robinhood-chain-sdk.
Metadata is prepared, not submitted — publishing to a registry is a one-way, attributed action the owner should take:
modelcontextprotocol registry — server.json in this repo validates against the
official schema.
Submit with the mcp-publisher CLI once
hood-mcp is live on npm.
Smithery — their current flow publishes a running server URL or an .mcpb bundle
(smithery mcp publish <url> -n <org/server>), not a static config file. Deploy the HTTP
transport (hood-mcp --http) somewhere public, then run
smithery mcp publish https://your-deployment/mcp -n nirholas/hood-mcp.
All rights reserved. See LICENSE.
Live Robinhood Chain overview: latest block, gas price, TVL, and network totals (blocks, addresses, transactions, block time). No inputs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and live-data aspects. The description adds that the data is 'live' and lists the metrics, but does not disclose any further behavioral traits such as rate limits or potential delays. For a simple zero-input read-only tool, this level of additional context is modest but not deficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the primary purpose ('Live Robinhood Chain overview') followed by a concise enumeration of included data points. Every phrase contributes meaning, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no inputs, no output schema, and minimal annotations, the description fully covers the necessary context. It explains exactly what data is returned and emphasizes the live nature. Nothing essential is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema's empty properties already indicate no inputs. The description reinforces this with 'No inputs,' which is a small but helpful confirmation. Per the rubric, a baseline of 4 applies for zero parameters, and no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('get') and resource ('chain stats') with a detailed list of included metrics (latest block, gas price, TVL, network totals). It clearly distinguishes itself from sibling tools focused on tokens, quotes, and launches by targeting a chain-wide overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: whenever an agent needs a live Robinhood Chain overview or network-level statistics. It does not explicitly name alternatives or exclusions, but given the zero-input nature and unique scope, the context is sufficiently clear. Lacking explicit 'when-not-to-use' guidance, it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detail for any Robinhood Chain token by contract address: price, 24h volume, liquidity, FDV, holder count, and whether it is a registered Stock Token.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Token contract address (0x…40 hex). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent: it is a read operation for any token. The description adds transparency by listing the exact return fields (price, 24h volume, liquidity, FDV, holder count, registered Stock Token), which is valuable behavioral context given no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the purpose and enumerates the specific data points. No redundancy or filler; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with strong annotations and no output schema, the description is complete. It specifies the input condition (contract address) and enumerates the return fields, covering the essential information an agent needs to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'address' is already described as 'Token contract address (0x…40 hex)'. The description merely reiterates 'by contract address' without adding new constraints, format requirements, or examples. Baseline 3 is appropriate when the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns comprehensive detail for any Robinhood Chain token by contract address, listing specific data fields (price, volume, liquidity, FDV, holder count, stock token status). This distinguishes it from sibling tools like search_token or get_stock_quote, as it is address-based and returns a full detail profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by contract address' provides a clear usage context, indicating this tool is the address-based lookup for token details. It does not explicitly name alternatives (e.g., using search_token to find the address first), so it lacks an explicit when-not or alternative recommendation, but the primary use case is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiplier-correct Stock Token portfolio for any address: per-position token balance, ERC-8056 share-equivalent, USD value, plus the USDG cash balance. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address (0x…40 hex) to value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, and the description reinforces 'Read-only.' It adds useful behavioral context beyond annotations by specifying the exact output components (token balance, share-equivalent, USD value, USDG cash balance) and the 'Multiplier-correct' aspect, which is not derivable from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the core purpose and then efficiently lists the portfolio components. Every word earns its place; no filler or repetition beyond the useful 'Read-only' safety confirmation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with no output schema, the description adequately covers what the agent will receive: per-position balance, share-equivalent, USD value, and cash balance. It does not mention empty-address behavior or error cases, but these are minor gaps for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the address parameter clearly described as 'Wallet address (0x…40 hex) to value.' The description adds no new parameter format or syntax, only rephrases 'any address,' which is redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') and resource ('Stock Token portfolio'), and details exactly what is included: per-position token balance, ERC-8056 share-equivalent, USD value, and USDG cash balance. It distinguishes itself from siblings like get_stock_quote and list_stock_tokens by focusing on a full address portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'for any address' and a list of returned components, making it obvious when to use this tool for wallet portfolio holdings. It does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recently launched tokens on Robinhood Chain launchpads (NOXA and The Odyssey), newest first, scanned from on-chain logs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max launches to return (default 25). | |
| launchpad | No | Restrict to one launchpad. | |
| lookbackBlocks | No | Blocks to scan back (~30k ≈ 1h; default 30000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds that data is scanned from on-chain logs and ordered newest first, which is useful context. However, it does not disclose potential delays, pagination, or specific data source caveats. This is a modest addition beyond the annotations, consistent with a score of 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the main purpose, scope, ordering, and data source. It is front-loaded with the core action and resource, and every word adds value. No verbose or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (3 optional params, no output schema), the description is quite complete: it states what is returned (recently launched tokens), the launchpads, the ordering, and the data source. While it does not explicitly describe the response format or behavioral limits, the description combined with schema and annotations is sufficient for a list-style read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter (limit, launchpad, lookbackBlocks) having a clear description. The tool description does not need to repeat parameter details, and it doesn't. It does add a note about launchpad names aligning with the enum, but that is already in the schema. Baseline of 3 is appropriate since the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving recently launched tokens on Robinhood Chain launchpads, with specific launchpads named (NOXA and The Odyssey). The verb 'get' plus the resource 'recent launches' and scope 'from on-chain logs' is specific and distinguishes it from more generic token listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking recent launches, but it does not mention alternative tools or exclusion criteria. The sibling tool 'watch_launches' likely serves a different (live monitoring) purpose, but this is not stated. No explicit 'when to use vs. alternatives' guidance is provided, only an implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price a Stock Token by ticker: the Chainlink oracle price, the on-chain Uniswap DEX mid price, the premium/discount between them, and the ERC-8056 multiplier (so you also get the underlying share price).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker, e.g. "AAPL" or "TSLA" (case-insensitive). | |
| maxAgeSeconds | No | Reject the Chainlink answer if older than this (default 3 days; 24/5 feeds). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given readOnlyHint and openWorldHint annotations, the description adds useful behavioral context by detailing the types of prices returned (oracle vs DEX, premium/discount, multiplier) and the underlying share price. It does not mention error states or data provenance beyond the oracle, but annotations already cover the read-only safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then uses a colon to list output components. Every phrase adds value, with no redundant or promotional language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description compensates by listing the key return fields (oracle price, DEX mid, premium/discount, multiplier, share price). It does not mention possible errors or currency, but for a read-only quote tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter descriptions (e.g., symbol is a ticker, maxAgeSeconds rejects stale Chainlink answers). The description only reinforces 'by ticker' and adds output semantics, not new parameter meaning, so it does not exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Price' and resource 'Stock Token by ticker', and enumerates the exact price components (Chainlink oracle, Uniswap mid, premium/discount, ERC-8056 multiplier, underlying share price), clearly distinguishing it from siblings like get_coin or list_stock_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for pricing a single stock token by ticker, and the mention of tickers and price details sets the expected context. However, it does not explicitly contrast with alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The registry of tokenized-equity Stock Tokens on Robinhood Chain (ticker, name, contract, Chainlink feed). Set pricedOnly to return only tokens with a live feed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries (default all). | |
| offset | No | Skip this many (pagination). | |
| pricedOnly | No | Only tokens with a Chainlink price feed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint annotations already covering safety, the description adds meaningful context about the data returned (ticker, name, contract, Chainlink feed) and the pricedOnly filter behavior. It does not disclose pagination or ordering, but the annotation lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes a useful filtering tip. No fluff or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential return fields and the main filter. It does not explicitly state that all tokens are listed by default, but this is implied by 'registry' and the optional schema parameters. For a simple read-only list tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description reiterates pricedOnly's function without adding new meaning, and limit/offset are fully covered by their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the registry of Stock Tokens on Robinhood Chain, listing key fields (ticker, name, contract, Chainlink feed). This distinguishes it from sibling search/quote tools, and the title reinforces the list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a filtering guideline (pricedOnly) but does not explicitly compare to alternatives like search_token or get_stock_quote. Usage context is implied rather than stated, making it only marginally helpful for choosing between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The trending pools on Robinhood Chain right now (memecoins and stocks) with price, 24h volume, price change, and liquidity — the pulse of the chain.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many (default 10, max 30). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds useful behavioral context by specifying the returned data (price, volume, change, liquidity) and emphasizing the real-time 'right now' nature, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence that clearly identifies the resource and scope. The parenthetical clarifies asset types, and the field list adds value without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, read-only tool with one optional parameter, the description adequately covers purpose and returned fields. Since there is no output schema, the field list provides the necessary insight, though it could optionally mention ordering or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional 'limit' parameter, including default and max values. The description adds nothing about parameters, so it relies appropriately on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists trending pools on Robinhood Chain with specific data fields (price, 24h volume, price change, liquidity). It distinguishes itself from siblings like list_stock_tokens and get_chain_stats by focusing on trending memecoins/stocks as the chain's pulse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'right now' and 'the pulse of the chain' clearly indicate when to use this tool: to gauge current trending activity. It doesn't explicitly name alternatives or exclusions, but the context is clear and sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tokens on Robinhood Chain by ticker, name, or contract address — searches the Stock Token registry and the Blockscout index together.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20). | |
| query | Yes | Ticker, name fragment, or 0x address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint and openWorldHint annotations by explaining that the search spans two distinct indexes, which implies broader coverage. It also clarifies the acceptable input types. There is no mention of rate limits or pagination behavior, but given the annotations already indicate a safe read-only operation, this additional context is meaningful and not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that is front-loaded with the core purpose ('Find tokens...'), then provides additional scope information. Every phrase is useful: the target chain, search methods, and the two sources. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and no output schema, the description is quite complete. It explains what is searched and how, and the limit parameter covers pagination. The only missing piece is what the response contains (e.g., token objects), but that is not critical for a search tool and may be inferred from the sibling tool names. Overall, it provides enough context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions (100% coverage). The description reinforces the semantics of 'query' by explicitly stating that searches are by ticker, name, or contract address, and adds the detail of searching two registries together. This goes beyond the schema by clarifying the combined scope of the search, earning a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find tokens on Robinhood Chain by ticker, name, or contract address.' It identifies the resource (tokens), the action (find), and the specific search criteria, while also mentioning the combined search over two registries. This distinguishes it from sibling tools like list_stock_tokens or get_coin, which suggest listing or fetching specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: whenever a user needs to locate a token by ticker, name, or contract address. It implies a comprehensive search across both Stock Token registry and Blockscout, which helps set expectations. However, it does not explicitly contrast with alternatives or state when not to use it, though the context itself is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watch NOXA + The Odyssey live for new token launches, blocking up to waitSeconds (or until limit launches are seen), then returns what appeared. Falls back to the most recent launch if none fire in the window.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Stop early after this many (default 20). | |
| launchpad | No | Restrict to one launchpad. | |
| waitSeconds | No | How long to watch (default 20, max 120). | |
| includeRecentIfEmpty | No | If nothing launches in the window, return the latest recent launch (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds critical behavioral details: blocking up to waitSeconds, early stop at limit, and fallback to a recent launch when nothing appears. This is significant context that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with no fluff. Key information (live watching, blocking, fallback) is front-loaded and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a blocking watcher with no output schema. The description covers behavior, fallback, and parameters sufficiently for an agent to know how to invoke it. Minor gap: it does not describe the return format (e.g., what 'returns what appeared' looks like), but the openWorldHint and sibling context partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds value by explaining how waitSeconds and limit interact (blocking, early termination) and the includeRecentIfEmpty fallback behavior, which is not fully expressed in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool watches NOXA + The Odyssey live for new token launches, using a specific verb ('watch') and resource scope. It distinguishes from siblings like get_recent_launches by emphasizing the live/blocking behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys real-time usage with blocking and early-exit semantics, but does not explicitly name alternatives or say when to prefer this over get_recent_launches. Context is clear but no exclusions or alternative pointers are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1get_chain_statsget_coinget_portfolioget_recent_launchesget_stock_quotelist_stock_tokenslist_trending_coinssearch_tokenwatch_launchesScored across 9 tools
Most tools target distinct actions (network stats, portfolio, search, quote, launches), but get_coin and get_stock_quote both return price data, and search_token overlaps with get_coin for finding token info. Still, descriptions clarify inputs and outputs well enough to avoid major confusion.
All tool names follow a consistent verb_noun pattern using lowercase with underscores (get_*, list_*, search_*, watch_*). No mixed conventions or vague verbs.
With 9 tools, the server is well-scoped for a blockchain data API. Each tool covers a distinct area of the domain (stats, portfolio, tokens, quotes, launches) without unnecessary bloat or thinness.
The toolset covers the core read-only needs: network stats, portfolio, token lookup, pricing, trending, and launches. Minor gaps exist (e.g., no historical price data or transaction-level queries), but these are not obvious dead ends for typical agent workflows.
Read-only MCP server for Robinhood Chain token discovery, research, and due diligence via GMGN.
On-chain honeypot/rug scanner, market data, and launch tools for Robinhood Chain (EVM 4663).
The only x402 MCP server for Robinhood Chain (chainId 4663) - 147 onchain, trading & AI tools.
Non-custodial limit, stop-loss and DCA trading on Epsilon (Robinhood Chain) for AI agents
