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

The description goes beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by explaining the evidence boundary of persisted registry rows, the grouping by source date, and the explicit absence of live-data fetching or trade placement. This adds meaningful behavioral context that annotations alone do not provide.

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 sentences front-load the core purpose, then enumerate parameters briefly and conclude with behavioral guarantees. No wasted words; it is appropriately sized for a read-only query tool with seven parameters.

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 purpose, parameter setup, behavioral boundaries, and return grouping. An output schema exists, so detailed return-value documentation is not needed. The mention of evidence boundary adds completeness for a registry-retrieval context, and annotations cover the safety profile.

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%, but the description adds value by clarifying that source_date and source_date_from/to are alternative date filter styles, and by enumerating mode values (compact|full). It also highlights that product is required. This supplements the schema's individual field descriptions without being redundant.

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 uses a specific verb ('retrieve') with a defined resource ('persisted constituent registries') and scopes it to 'one Coinbase thematic or index perp product' with concrete examples. It also distinguishes itself from live exchange-native constituent APIs, which separates it from sibling tools like deltasignal_coinbase_perp_factors or market_spectra.

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?

The description clearly states this returns persisted registry rows rather than live exchange-native constituent APIs, and explicitly lists what it does not do (fetch live data, place trades, mutate recorder state). While it does not name alternative sibling tools, the exclusion of live data and the emphasis on read-only retrieval gives strong contextual guidance for when to use this tool.

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