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

Annotations only establish readOnlyHint=true and openWorldHint=false; the description goes well beyond by disclosing the precise semantics of each branch, the tolerated input noise (spaces, dots, dashes, ES prefix), and an explicit negative scope statement that it does NOT confirm the document exists, is active, or belongs to the caller. That last clause is exactly the kind of caveat that prevents an agent from over-trusting the result.

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 densely packed sentences, front-loaded with the organizing idea ("Two modes in one input") so the agent knows the branching logic before reading details. Every clause carries operative information; nothing is filler or restatement of the title.

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?

There is no output schema, and the description compensates by stating what each branch returns (the derived check letter / full 8-digit-plus-letter DNI vs. a validity determination). Combined with the mode selection rules and negative scope, an agent has everything needed to call it and interpret the result.

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% (baseline 3), but the description substantially enriches it: it defines the two accepted input classes, the exact accepted document formats, zero-padding behavior, and separator/prefix tolerance that the schema's one-line "1-8 digits, or a full DNI/NIE/CIF" does not convey.

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: it computes or validates the check character of a Spanish DNI, NIE or CIF. That resource is narrow enough to be instantly separable from the sibling tools (validate_iban, check_vat_number, calculate_vat), which target different identifier families.

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?

Explicitly frames usage around input shape: "If `valor` is only 1-8 digits... If `valor` is a full document...", which tells the agent exactly which behavior to expect for a given call. It stops short of naming alternatives or stating when-not to use it, so it earns a 4 rather than a 5.

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