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

Annotations already establish readOnly/openWorld/idempotent/non-destructive behavior, so the description only needs to add context. It does: NAI/VAI/OAI meanings and severity, worldwide coverage, and the FDA Data Dashboard (OII) source. It does not discuss pagination or sorting, but the schema's 'limit', 'since', and 'until' parameters plus the open-world annotation reduce that gap.

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 description is four sentences, each earning its place: what the data is, the classification meanings, search scope, and provenance. The first sentence front-loads the core purpose, and the final sentence adds a useful distinction without padding. It is richer than average but not bloated.

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 10-parameter read-only search tool with no output schema, the description covers the data domain, filter dimensions, classification semantics, geographic scope, and source. It does not describe exact return fields or default ordering, but 'limit' default is in the schema and the description states the key output element (final classification). An agent has enough context to select and invoke the tool correctly.

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 every parameter already has a clear description with examples. The tool description adds marginal value by grouping the search dimensions and emphasizing that 'firm' is a substring and that OAI signals enforcement risk, but these details largely overlap with the schema. Baseline 3 is appropriate because the structured schema carries the parameter documentation burden.

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 names a concrete resource ('FDA inspection results') and a specific action ('Search by'), then defines the three classifications and the global scope. It differentiates from sibling FDA tools by calling itself 'inspection OUTCOME data,' which is distinct from fda_483_citations and fda_compliance_actions. This is far more specific than the tool title alone.

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?

The description provides clear context for when to use the tool: worldwide FDA-regulated establishments, filterable by firm substring, state, country, product type, or date range. It also implies its niche with 'This is inspection OUTCOME data — openFDA does not carry it.' However, it never explicitly names sibling alternatives or states when not to use it, so it falls short of perfect routing guidance.

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