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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds behavioral context those hints cannot carry: benchmarks are identical for everyone and never a recommendation, customisation requests and buy/sell advice are refused, and custom portfolio work is redirected to build_portfolio. That refusal semantics is actionable for an agent deciding whether to call at all.

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?

It is dense but front-loaded: definition first, then filter vocabulary, then usage routing, then exclusions and boundaries. Every clause carries information, though the opening sentence is a long run-on and the sibling-routing tail is packed into two heavy sentences that could be split.

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?

No output schema exists, so the description should ideally hint at the return shape (e.g. benchmark identifiers/names and families to feed into get_benchmark); it implies this via 'then get_benchmark for one' but never states what a listed item looks like. Otherwise it is complete for a read-only, zero-required-parameter listing 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 0% — neither 'band' nor 'family' is described in the schema — so the description must carry the load and does: family values are enumerated (strategic, tax-aware, factor, income, tactical, thematic) and 'band' is explained with concrete formats ('moderate', '60', or "all stocks"). This is meaning the agent could not derive from the bare string properties.

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 states a concrete verb+resource (listing ETFIQ benchmark definitions) and immediately characterizes what a benchmark is — 'published, rules-based yardsticks for model portfolios... a written rule over broad, low-cost ETFs'. It explicitly separates itself from sibling tools (get_benchmark for one entry, etf_profile for a fund's own benchmark, etfiq_methodology for how it is chosen), so an agent can route correctly without opening schemas.

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 gives an explicit trigger ('use when asked which benchmark measures a kind of model portfolio, then get_benchmark for one') and names the negative cases: a fund's own benchmark lives in etf_profile, methodology in etfiq_methodology, and custom portfolio construction in build_portfolio. When-to-use, when-not-to-use, and the successor tool are all spelled out.

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