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

Annotations already declare the tool read-only and idempotent, and the description adds useful behavior on top: what the search covers and that it returns status, indication, holder, authorisation dates, and an EPAR link. Since there is no output schema, stating the return fields is valuable context.

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?

Three sentences, front-loaded with the resource and action, then return fields, then realistic example queries. Every sentence earns its place and there is no filler or repetition of the schema.

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 search tool with rich schema coverage and read-only annotations, the description covers the main operational facts: what is searched, what is returned, and what kinds of questions it answers. It does not need an output schema because the return fields are explicitly named, though it could have added a note about result pagination or open-world matching.

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 the baseline is 3, but the description goes beyond the schema by expanding the free-text query to include therapeutic area, INN, and marketing-authorisation holder. The example questions also illustrate how query, status, and orphan_only can be combined.

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 uses a specific verb and resource: 'Search the European Medicines Agency register of centrally authorised medicines', and enumerates the many query dimensions an agent can use. It is clear enough to be told apart from most EMA siblings, though it does not explicitly name or contrast a sibling such as ema_medicine.

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 provides clear usage context through concrete answerable questions like 'is drug X authorised in the EU' and 'EU authorised orphan medicines for cystic fibrosis'. It does not explicitly state exclusions or alternatives, but the examples strongly signal when the tool should be selected.

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