List Robinhood Stock Tokens
rwa_list_assetsList authoritative Robinhood Chain Stock Token assets, optionally filtered by symbol.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No |
rwa_list_assetsList authoritative Robinhood Chain Stock Token assets, optionally filtered by symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile needs no restating. The description's only added behavior is that results come from an 'authoritative' source and constitute the canonical asset list, which is modest value beyond the 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 with the resource and the optional filter front-loaded; nothing is extraneous and nothing important is buried.
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 no output schema, the description should hint at what an 'asset' record contains (address, chain, symbol, metadata) and whether the unfiltered call returns the full set. It establishes scope but not the return shape, which is the main missing piece for a discovery 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 description coverage is 0%, so the single 'symbol' parameter has no documented matching semantics. The description clarifies that filtering is optional and keyed on symbol, but says nothing about exact vs. partial matching, case sensitivity, or the effect of an unmatched symbol — leaving a real gap for the only input.
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 and resource ('List ... Stock Token assets') with a named data source ('Robinhood Chain', 'authoritative'), which separates it from analysis siblings like rwa_analyze_asset and rwa_compare_assets. It does not explicitly name those siblings, but the read/list scope is unambiguous.
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 'optionally filtered by symbol' implies the two call modes (full listing vs. single-symbol lookup), so usage is inferable. However, there is no explicit guidance on when to pick this over rwa_analyze_asset, rwa_market_snapshot, or the prediction listing tools.
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.