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

With annotations already covering readOnly/idempotent/non-destructive, the description goes well beyond them: it discloses what counts mean (share_of_kind is a share of reports, not a crash rate), that ADS/ADAS reporting regimes are never combined, that a DMV permit holder may be a different legal entity, that counts break at the June 16, 2025 amended order, and that confidential narratives are claims not determinations. It also states the return boundary (no people or narrative text) and that NHTSA caveats are echoed verbatim.

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?

The purpose is front-loaded in the first sentence, which is good, but the caveat block is a dense run-on that repeats the same ideas ('say nothing about responsibility' twice, 'not rates' and 'never normalised' restated). The warnings are genuinely useful but could be compressed or bulleted without losing content.

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?

There is no output schema, and the description compensates well by enumerating the returned fields (ADS/ADAS profiles, report and incident counts, severity, location, confidentiality index, investigations, recalls, permits) plus interpretive caveats. It is silent on multi-match behaviour, result limits, and empty-result handling, which matter given substring matching on an 80-character input.

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?

The single parameter is fully documented in the schema, so the baseline is 3, but the description adds real semantics: matching is against the 'published name' and that a DMV permit holder may be a different legal entity from the registered filer, which matters for interpreting a match. It does not say whether matching is a substring search returning multiple companies or how many results come back.

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: 'Find reporting companies in the MORVS Self-Driving Crash Register by published name or slug', and adds that it returns company-level profiles (ADS/ADAS, counts, permits) rather than individual reports. This implicitly separates it from the sibling self_driving_reports tool, but never names that sibling or explicitly says what this tool is not, leaving the differentiation to inference.

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 rather than stated: the description says 'No people or narrative text are returned', which hints that narrative/report-level lookups belong elsewhere, and the input restriction to a name or slug signals entity-level lookup. There is no explicit when-to-use, when-not, or named alternative (e.g. self_driving_reports), so an agent must infer routing.

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