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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it discloses that results include reviewed brands, that an rx_alternative entry is a different medicine, and it imposes explicit safety constraints on how results may be presented (not interchangeable, no buy/import advice). This is valuable behavioral guidance that annotations cannot convey.

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 compact and front-loaded: the first sentence states the core purpose and the reverse relationship. Every subsequent sentence earns its place by adding usage routing, return-field context, or safety guardrails. No filler or repetition of schema/annotation 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?

For a single-parameter read-only tool with no output schema, the description covers the key things an agent needs: what the tool does, when to use it, where the parameter comes from, what the response contains, and how to handle a potentially confusing field (rx_alternative). It doesn't describe pagination or exact response formatting, but the listed return fields and the safety constraints make it complete enough for correct invocation and safe use.

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 0%, so the description must compensate for the single parameter, slug. It does: it states that slug comes from search_drugs, which tells the agent where to obtain the value and implies it is a drug identifier. It doesn't give format details, but for a single required parameter with a clear provenance instruction, this is adequate compensation.

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 and resource: it returns foreign brand names for a US drug, and explicitly frames it as the reverse of find_us_equivalent. It also gives a concrete example ('what is lisinopril called in Mexico?'), which makes the tool's purpose unmistakable and distinguishes it from siblings.

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 explicitly says when to use this tool: when the person has the US name and wants the home-country one. It also names the sibling alternative (find_us_equivalent) and explains the relationship. It further instructs that slug comes from search_drugs, giving a clear prerequisite and routing an agent to the correct upstream tool.

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