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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower, and the description still adds real behavior: results are unverified user submissions, active is the default scope, and history results are appended after active ones. The trailing wrapper instructions ('Follow its required fields and exact choices', 'Do not pass the REST calculator field') add little behavioral value.

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, filters and scope defaults are front-loaded efficiently in the first three sentences. The remaining four sentences are boilerplate plumbing instructions that dilute the signal, though the 'put tool fields inside inputs' note is genuinely useful given the nested schema.

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?

An output schema exists and annotations cover the safety profile, so the description only needs to cover invocation semantics, which it does: required state, optional refinements, scope default and ordering. It omits result limits or pagination and leaves the exact meaning of the mile-radius search implicit.

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?

With 0% schema description coverage and a nested inputs object, the description carries the load and mostly does: it marks state as the search basis, presents route/direction/mile as optional refinements, explains the one-mile tolerance, and defines the active-vs-history meaning of scope. It is slightly inaccurate in referencing a 'units' field that does not appear in the schema.

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 opening sentence names a specific verb and resource ('Find user-reported, unverified road closures') and qualifies the data source, which is enough for an agent to distinguish it from siblings like bridge_screen or fuel_stops. It stops short of explicitly contrasting itself with any named alternative.

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 states the primary search axis (state) and the optional narrowing fields (route, direction, mile within one mile), and it explains the scope choice: default is active reports, history adds expired records sorted after active ones. No exclusions or sibling routing are given, so it is clear context rather than full when/when-not guidance.

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