list_indices

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It adds some behavioral context like base_date resolving backwards to a trading day and ordering by most-tracked first. However, it does not explicitly state that the operation is read-only or mention any potential side effects, permissions, or error conditions. Still, the verb 'list' implies a safe read operation.

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 well-structured: a one-sentence purpose, a usage note, and a compact bulleted list of parameters. Every sentence is informative and there is no redundant or filler content.

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 tool's purpose, usage guidance, and all parameters thoroughly. There is an output schema, so return structure is already specified. It could be more complete by mentioning behavior when no indices match or edge cases, but for a list tool with well-documented inputs, this is largely sufficient.

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%, but the description fully compensates by explaining each parameter's meaning: query as substring filter with an example, min_etf_count as a threshold, base_date's format and backward resolution, and limit's ordering. This adds significant value beyond the raw 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?

The description clearly states the tool's action ('List underlying indices and how many ETFs track each') and its role in the broader system as a 'map of the market' to find exact index_name strings. This specific verb+resource+scope distinguishes it from sibling tools like search_etf and find_similar_etf.

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?

It explicitly instructs when to use this tool: 'use it to find the exact index_name string that search_etf and find_similar_etf expect.' This provides a clear use case and directs the agent to related tools, fulfilling the 'explicit when' criterion without ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.