world_index_history

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description says 'Get' which implies read-only, but the return format, any rate limits, supported index universe, or how data might differ from stock_history (e.g., normalization, currency) are not disclosed. This is a bare minimum description for a data-retrieval tool.

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 efficient sentence with zero waste. It is appropriately concise, though it could have leveraged the space to add distinguishing context rather than remaining purely generic.

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?

An output schema exists and schema coverage is 100%, which reduces the burden. However, for a financial data tool among many similar history tools, the description should clarify the index universe supported, how it relates to stock_history, and any notable behavior differences. It's minimally adequate but not rich enough given the sibling-tool complexity.

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 the schema already documents all 4 parameters well. The description itself adds nothing beyond 'historical data' framing, but the schema fully covers semantics including defaults, formats, and example symbols. The baseline of 3 for high coverage is marginally exceeded because the schema provides rich examples like DJI/IXIC/GSPC mappings.

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 'Get world market index historical data' uses a clear verb+resource but is generic and doesn't differentiate from sibling tools like stock_history, fx_history, or crypto_history which all provide historical data. It lacks specificity about which indices are covered or how it differs from other history tools.

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?

No guidance is provided on when to use this tool versus alternatives like stock_history or other history tools. The description doesn't clarify that this covers market indices specifically, nor when to choose it over stock_history for index-related queries. No exclusions or alternatives are mentioned.

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