Fund managers

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds real behavioral value by disclosing that avg_annual_return_pct only covers funds older than one year, a data-quality caveat unavailable anywhere else. It does not discuss ordering ties or result volume, which keeps it from a 5.

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?

Three short sentences, each earning its place: what it returns, when to use it with the follow-up call, and one data caveat. The core purpose is front-loaded and nothing is redundant.

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 names the returned fields (AUM, fund count, typical return), which is the key omission it needed to fill. Only minor gaps remain, such as default/max result count and tie-breaking in the ranking.

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 'limit' (managers to return, 1-40) and 'query' (partial name filter with an example) are already documented in the schema. The description adds the downstream handoff of a manager name to fp_search_funds, but says nothing about limit behavior beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 ('Rank fund management companies by total assets under management') and names the exact fields returned (fund count, typical return). An agent can distinguish it from fp_search_funds, which searches individual funds, without opening either schema.

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?

Gives a concrete triggering question ('which companies run the most funds') and an explicit chaining instruction: 'Pass a manager name from here to fp_search_funds(manager=...)'. It stops short of naming exclusions or the other siblings (fp_fund_types, fp_compare), so it is strong but not complete routing guidance.

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