stocks_listList the tokenized stocks Robinhood issues on Robinhood Chain (about 100: AAPL, TSLA, NVDA...): symbol, name, token address, shares-per-token multiplier, which trading sessions they trade in, and whether a Chainlink price feed exists. Filter with query (symbol or name).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 200 | |
| query | No | Part of a symbol or company name, e.g. 'NVDA' or 'apple' |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, open-world profile, but the description adds real substance: approximate catalogue size (~100), scope (Robinhood Chain only), and the exact shape of each record including the shares-per-token multiplier and Chainlink feed flag. It omits any statement about limit/pagination behaviour, which matters since ~100 items can exceed a caller's expectation.
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 sentences, zero filler: the scope and record shape come first, the filtering affordance second. The long field list earns its space because none of it is derivable from the schema or annotations.
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?
With only two optional params, no output schema, and light annotations, the description does the necessary heavy lifting by describing the returned record shape and dataset size. The remaining gap is behavioural detail around the undocumented 'limit' default of 200 versus a ~100-item catalogue.
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%, so both parameters are already documented. The description's 'filter with query (symbol or name)' restates the schema's own example without adding format or matching rules, and the 'limit' parameter (default 200) is not addressed at all. Baseline 3 applies.
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?
States a specific verb ('List') and a precisely bounded resource ('tokenized stocks Robinhood issues on Robinhood Chain'), and enumerates the returned fields so an agent knows exactly what it gets. It does not name a sibling such as stock_quote to contrast against, so differentiation from the price-oriented tools is only implicit.
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?
'Filter with query (symbol or name)' gives an in-tool usage hint, and the enumeration of returned fields implies catalog/discovery use. However, there is no explicit when-to-use-this-vs-alternatives guidance — nothing says to follow with stock_quote for pricing or token_quote for market data, which is the most likely confusion given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.