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 safety profile is covered. The description adds genuinely useful context beyond that: corpus size (~139 investigations), the nature of the records (independent root-cause investigations), and the relationship to the broader EPA RMP accident dataset. It does not discuss return shape or result ordering, but that is a minor omission against the annotation coverage.

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 verb and resource, with the supporting context (corpus size, examples, dataset layer) packed into the second. No filler or restated boilerplate.

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 simple two-parameter search with no output schema, the description gives enough to call it correctly: what corpus is searched, what the query accepts, and what scale of result to expect. A brief note on what a result record contains would fully close the gap, but nothing essential 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%, and the description's 'by company, location, or keyword' largely restates the schema's 'Company / location / keyword' for q. The named example entities (BP Texas City, West Fertilizer, DuPont) give marginal help in shaping queries, but the description adds little parameter meaning beyond the schema, so the baseline of 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?

States a specific verb (Search), a specific resource (U.S. Chemical Safety Board investigations), and the domain (major chemical incidents — explosions, toxic releases, fires) with concrete example cases. It even positions itself in the corpus hierarchy ('the deep-investigation layer over EPA RMP chemical accidents'), which implicitly distinguishes it from the sibling chemical_accident_search.

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?

Usage is implied: an agent can infer this tool is for CSB root-cause case investigations rather than general chemical accident data. However, it never explicitly says when to prefer this over chemical_accident_search or chemical_accident_worst, nor does it state exclusions. The 'deep-investigation layer over EPA RMP' phrase hints at the boundary without naming the alternative.

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