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

Annotations already establish read-only, idempotent, open-world, non-destructive behavior, but the description adds genuinely non-obvious traits: the ten categories overlap and must not be summed, counts come with rates and reporting-population coverage, and provenance is included. It also warns that this is not a current incident feed, which prevents a plausible misuse.

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?

Two sentences, front-loaded with the resource and scope, and the second sentence packs the usage examples, the coverage-inspection rationale, and the exclusions. The long clause chain in sentence one ('with counts, rates, reporting population coverage, and provenance') is dense but each element informs the agent, so there is little waste.

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 enumerates the return shape (ten overlapping categories, counts, rates, reporting coverage, provenance) and the schema covers all three parameters, including the markdown/JSON format choice. Nothing an agent needs to call this correctly or interpret the result is missing.

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% (month as YYYY-MM within the hosted snapshot, two-letter state with US excluded, response_format enum), so the schema already carries all parameter meaning. The description only weakly reinforces this by saying 'one state and month' and adds no format or edge-case detail, 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?

The description states a specific verb and resource (return the ten hosted FBI UCR offense categories for one state-month from the CDE aggregate snapshot) and differentiates itself from siblings by framing the output as a point-in-time snapshot rather than a trend or comparison. An agent can distinguish it from fbi_cde_state_crime_trend, fbi_cde_compare_state_to_national, and fbi_cde_state_reporting_coverage without opening any 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?

It gives concrete trigger phrases ('FBI crime snapshot for Ohio in June 2022', 'which CDE categories are available for this state-month?') and a stated purpose of inspecting coverage before a trend query, plus explicit exclusions (not a jurisdiction score, person-level search, or incident feed). It stops short of naming the specific sibling tools to use instead, so the routing is implied rather than explicit.

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