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

Annotations already declare readOnly/idempotent/openWorld, so the description's job is to add beyond that. It does: every system is queried in parallel, and systems with no record are left null AND listed so gaps are visible as gaps. That partial-failure/absent-data semantics is genuinely operational information not covered by any annotation.

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 value proposition is front-loaded in the first clause, and each sentence carries routing or behavioral content. It is dense and long, but nothing is filler; the only mild cost is that the identifier enumeration is a run-on list that could be trimmed without losing meaning.

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, so the description must convey return shape — and it does, enumerating every identifier returned and explaining the null-plus-listed convention for missing records. Combined with the routing guidance, an agent has everything needed to call and interpret this tool.

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% and the schema description already states the accepted forms (brand, INN, ingredient) and that US names resolve best. The prose adds no new parameter syntax beyond what the schema provides, so the baseline 3 for a single fully-documented parameter is appropriate.

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 verb ('turn one drug name into') and enumerates the precise resources returned: RxNorm RxCUI, FDA NDA/BLA application numbers with sponsor, DailyMed setid, SEC CIK/ticker, ClinicalTrials.gov study count, and ChEMBL molecule id. This is far more specific than sibling tools like pharma_drug_profile, and an agent can tell them apart without opening either schema.

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?

'Call this first when a name has to travel between regulatory, clinical, chemical, and financial sources' clearly states the trigger condition. It gives strong positive routing guidance but does not name the alternative siblings (e.g., pharma_drug_profile, resolve_entity) or state when this tool is the wrong choice, so it stops short of explicit when-not guidance.

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