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

With no annotations supplied, the description carries the full behavioral burden and does so: records self-expire 'within minutes', they rank below official closures and never retract one, the tool is feature-gated (SN_CAMERA_INCIDENTS_ENABLED, 501 when unarmed), and it requires GATEWAY_URL + GATEWAY_API_KEY. This is unusually rich disclosure for a read tool.

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 front-loaded with the core claim and every sentence carries information, but the single dense run-on paragraph mixes filter mechanics, record contents, caveats, and gating, making it harder to scan than a short structured form.

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?

For a gated, credential-requiring tool this covers what an agent needs: how to scope the query, what each record asserts and includes, expiry behavior, the coverage_note caveat, and attribution requirements. An output schema exists, yet the description still usefully summarizes record contents.

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 baseline is 3. The description restates the near/radius_m and shape/buffer_m defaults that the schema already documents and omits min_confidence and include_recently_expired entirely, adding little semantic value beyond the structured fields.

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 clause names the specific resource and its provenance (road incidents a traffic camera saw and a vision model confirmed, in force now), and the 'rank below official closures' line implicitly separates it from sibling closure/observation tools. An agent can tell what this returns without opening the 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 an explicit selection rule for the spatial inputs ('Give exactly one' of near/bbox/shape) with defaults, warns that an empty list never means a clear road, and states the deployment gating ('Off unless the deployment arms camera incidents... an unarmed gateway answers 501'). Conditions for use and non-use are both covered.

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