hood-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation4/5
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.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase with underscores (get_*, list_*, search_*, watch_*). No mixed conventions or vague verbs.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.2/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Inno Setup License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![robinhood-chain-mcp MCP server](https://glama.ai/mcp/servers/nirholas/robinhood-chain-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nirholas/robinhood-chain-mcp)

Score Badge

Copy to your README.md:

[![robinhood-chain-mcp MCP server](https://glama.ai/mcp/servers/nirholas/robinhood-chain-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nirholas/robinhood-chain-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nirholas/robinhood-chain-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server