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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description stays consistent while adding value beyond them: the upstream feed (registroCambios), the returned columns, and that the tool is 'Keyless' (no auth needed). It still doesn't disclose rate limits or pagination behavior beyond the schema's limit field.

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?

Front-loaded with what changes are returned, then use cases, then an example — no filler sentences. Dense but every clause carries information; slightly long, though nothing is wasted.

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?

With no output schema, the description usefully enumerates the returned fields (nregistro, name, holder, change date, category tags), which is exactly the compensation needed. Minor gaps remain around result volume/paging and whether categories are filterable, but the definition is sufficient to invoke correctly.

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 100%, so both parameters are already fully documented in the schema, including the date format and the limit default/max. The description adds a worked example call, which reinforces the date format, but omits any mention of 'limit' or paging semantics, so it stays at the baseline for a fully-covered 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?

States a specific verb+resource+scope: records AEMPS has changed on or after a date, sourced from CIMA's registroCambios feed, covering new authorisations, label revisions, and material-informativo updates. An agent can distinguish it from cima_search_medicines or cima_medicine_detail without opening a 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?

Gives concrete use cases ('what changed in the Spanish medicines register this month', monitoring one drug for label updates), which clearly frames when to reach for this tool. It does not, however, name an explicit alternative or an exclusion (e.g., use cima_medicine_detail for full record detail), so routing against siblings is left partly to inference.

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