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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, which fully covers the safety profile. The description adds the FEI-resolution behavior and the fact that it aggregates multiple sources, which is useful. However, it doesn't disclose edge cases like what happens when a firm name is ambiguous, whether results are capped per source, or the response format. Given the annotations carry the heavy safety disclosure, a 3 is fair – it adds context but not rich behavioral detail.

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 a dense, front-loaded single paragraph. The first sentence states the core function and deliverables; the second adds the FEI resolution detail and then the use cases. Every sentence earns its place, with no filler or redundancy. It's appropriately sized for the tool's complexity.

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 read-only aggregation tool with full schema documentation and strong annotations, the description covers the what, the scope, and the when. It lacks detail on output format and pagination/limits behavior (though 'limit' is described in schema), and it doesn't mention how to handle ambiguous firm names. These are minor gaps given the schema and annotations carry much of the load. A 4 is justified because it's nearly complete for an agent to invoke 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 coverage is 100%, so every parameter (firm, limit, since, _apiKey) is already documented in the schema. The description adds that 'firm' is a name substring and that the tool resolves to FEI, which reinforces but doesn't extend the schema. The _apiKey format is fully in the schema. Baseline 3 is appropriate since the schema does the heavy lifting; the description doesn't add new parameter semantics beyond reinforcing the substring and resolution behavior.

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 ('resolves', 'provides') and a clear resource: a one-call FDA regulatory risk profile for a manufacturer. It enumerates the exact data points included (inspection history with NAI/VAI/OAI split, CFR citations, compliance actions, import refusals) and explicitly mentions resolving firm names to FEI identifiers. This distinguishes it from siblings like fda_inspections, fda_483_citations, fda_compliance_actions, and fda_import_refusals, which cover individual components.

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 gives explicit use cases: 'supplier due-diligence or to check a pharma name before an investment or sourcing decision.' It frames the tool as a consolidated one-call alternative to pulling each FDA dataset separately, which implicitly tells the agent when to prefer this over the sibling tools that return single facets. While it doesn't explicitly say 'use fda_inspections for just inspections,' the aggregation purpose is clear enough to route selection.

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