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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description need not repeat those. It adds the behavioral note that the tool returns null if the line has no card, and explicitly says it will not invent one. This is valuable context beyond the annotations.

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 two sentences long, with the core purpose stated first. It packs the card contents, usage guidance, and null behavior into a tight, front-loaded structure with no wasted words.

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?

The tool has an output schema, so the description does not need to explain the return structure. It covers the key behavioral outcome (null if missing), the intended usage (before describing a product), and the card's content. It is sufficient for an agent to call the tool correctly, though it could mention category constraints or examples.

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?

The schema has one parameter, category, with 0% description coverage. The description mentions 'por su categoría' (by its category), which clarifies the parameter's role but essentially repeats the schema's property name. It does not add details about valid category values or formats, so it only minimally compensates for the schema's lack of description.

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 clear verb and resource: it retrieves the service line card by category. It enumerates the card's contents (what it is, what it is not, for whom, differentiators, technical detail, FAQs), which makes the tool's function unmistakable. It also distinguishes it from sibling tools like get_product by referring to 'línea de servicio' vs 'producto'.

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 usage guidance: 'Úsala antes de describir un producto' (use it before describing a product). It also warns against a common error, implying when not to use it. However, it does not name specific sibling tools as alternatives, so it lacks explicit exclusion criteria.

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