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

Annotations already mark the tool as read-only and non-destructive; the description adds non-obvious operational context: it costs $0.10 USDC per call, uses OpenFDA as its source, and returns a cryptographically attested settlement receipt with a verification URL. There is no contradiction with the annotations.

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 pack purpose, outputs, source, cost, and verification without significant padding. The attestation sentence is trust-oriented but compact and useful because it describes a non-obvious return artifact.

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?

The prose covers the essential return values (total reports, serious events, deaths, hospitalizations, top reactions with percentages, signal level) and the per-call cost. For a simple one-parameter read-only tool this is mostly complete, though input-format guidance and explicit differentiation from the close sibling are 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?

drug_name is the only parameter and the schema has 0% description coverage; the phrase 'for a drug' is the only semantic hint. The description does not give examples, does not explain whether generic or brand names are accepted, and does not clarify expected spelling/casing, so it only barely compensates for the schema gap.

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 first sentence states a specific verb and resource (FDA FAERS adverse event signal) and enumerates a distinctive output set including percentages and a signal-level scale. The OpenFDA source and FAERS scope separate it from the generic-sounding sibling get_drug_adverse_events, though it never explicitly contrasts them, so it isn't a 5.

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 contains no when-to-use or when-not-to-use guidance and names no alternatives. With a near-identical sibling named get_drug_adverse_events, an agent must infer selection from the FAERS/OpenFDA/signal focus, which is only implicit.

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