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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered externally. The description adds genuine context by disclosing the 12-month rolling aggregation and the underlying dataset, but says nothing about whether counts are provisional/final, coverage limits, or result volume behavior.

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 fragments, purpose and source first, dataset ID second, use case last. There is no filler, though the closing research-framing sentence is the weakest-earning element rather than core invocation information.

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?

A read-only query tool with a four-hint annotation block, fully described parameters, and no output schema to explain. The description supplies the dataset, the aggregation window, and the analytic niche, which is everything an agent needs to select and call it correctly.

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 limit, indicator, and state_name, including an indicator value example. The description's mention of 'by state and indicator' confirms the slicing dimensions but adds no syntax or accepted-value detail beyond the schema, so the baseline 3 applies.

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?

Names a specific resource (CDC drug overdose deaths), the two dimensions it is sliced by (state and indicator), the source dataset ID (9j2v-jamp), and the metric form (12-month rolling counts). It does not explicitly distinguish itself from close siblings such as cdc_weekly_deaths_by_state or the generic cdc_dataset_query, which keeps it out of 5 territory.

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?

'Useful for opioid/fentanyl/stimulant policy research and treatment-program siting' gives an audience and a downstream use, implying when the tool applies. However, it never states when NOT to use it, nor points to the sibling that should be used instead (e.g. cdc_dataset_query or cdc_weekly_deaths_by_state), so the routing guidance is only implied.

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