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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the return format is markdown, the content is a FULL card (implying a shorter preview may exist elsewhere), and the fields returned vary by ficha type.

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?

Two sentences, front-loaded with the return value and followed by the input form. The middle list of card contents is slightly long but each item is informative and cheap, and nothing is redundant.

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 carries the burden of describing the return value and does so adequately for a read tool with zero required parameters. It omits error/pagination behavior, which is a minor gap given the low complexity.

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%: the URL example, the slug definition, and the enum plus its 'novedad' note are all documented in the schema. The description only restates the URL-or-tipo+slug combination, adding no syntax or constraint beyond what the schema already provides, so the baseline 3 applies.

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 concrete verb and resource ('Devuelve una ficha entera') and enumerates the payload an agent will get back (pasos, prompt, precios, pros y contras, fuentes). It is clearly distinguishable from a search or news-listing tool, though it never names or contrasts the siblings (buscar, novedades, temas).

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 the two invocation paths (URL, or tipo+slug) which implies the identifier must already be known, but it never says when to call this versus 'buscar' or how to obtain the slug/URL in the first place. Usage is implied rather than stated.

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