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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that: it discloses the response shape (names the page, quotes the answering paragraphs, returns the page's text) and the no-topic behavior (returns the page list). It stops short of describing not-found or ambiguity handling.

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?

Purpose is front-loaded and the sentences are dense but each carries information (coverage, invocation, benchmark caveat, no-topic fallback). The long parenthetical listing desks and the embedded benchmark aside make the first sentence heavy, costing some readability, but there is no filler.

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 carries the burden of explaining returns, and it does so concretely (page name, quoted paragraphs, full page text). Combined with the coverage list and the no-topic mode, an agent has enough to call it correctly; only failure/ambiguity behavior is left unaddressed.

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% for the single parameter, so baseline is 3. The description adds meaning beyond the schema: it clarifies that topic should be free-form natural language ('the reader's question in their words') rather than a page identifier, and that omitting it switches the tool into a page-listing mode, which the schema does not state.

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?

Opens with a specific verb+resource: it retrieves the methodology page explaining how ETFIQ computes a figure, and enumerates the covered domains (flows, scores, categories, look-through, benchmarks). The scope is distinguishable from generic page tools, though it never names siblings like etfiq_page, find_page, or etfiq_list, so an agent must infer the boundary itself.

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 explicit invocation guidance: 'Pass topic, the reader's question in their words' and 'Call with no topic for the list of pages', which covers both the primary and degenerate call patterns. It also adds a routing rule that a single fund's own benchmark follows its desk's rule and 'never the model-portfolio benchmarks', implicitly steering agents away from get_benchmark/list_benchmarks for that question, but no alternative tool is named.

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