Get token / memecoin detail

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.