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

With all annotations set to false, the description carries the full behavioral burden and delivers: unlisted medicines are unsupported, do not drop or substitute, ambiguous matches return clarification guidance, reference-only products are separately marked with sources, and arguments/results are excluded from telemetry. This goes well beyond the structured metadata.

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 dense but compact, with mapping examples and constraints front-loaded before output details. Every sentence contributes meaningful guidance; there is no filler or repetition of schema 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?

Since an output schema exists, return values do not need to be restated. The description covers input conventions, unsupported cases, output categories, ambiguity handling, and privacy, giving an agent everything needed to decide when to call it and how to construct valid calls.

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?

Only one of three parameters has schema documentation, but the description compensates by mapping public product names to enum values: Children's Motrin means brand motrin + audience children, Zyrtec means brand zyrtec, generic cetirizine means ingredient cetirizine, and Walmart means brand equate. This is essential semantic information not present in the schema.

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 ('Resolve') and resource ('ordinary public product names') and gives concrete mapping examples that make the function unambiguous. The mention of 'matching calculator bottles and separately marked reference-only' formulations also distinguishes it from sibling tools like get_label_directions and list_calculator_bottles.

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 guidance: omit filters only when unspecified, do not substitute unlisted products, and reject free-text/patient inputs. It does not explicitly name alternative sibling tools for routing, but the boundaries are mostly inferable from the output categories it describes.

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