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

Annotations only cover the safety profile (readOnly, non-destructive, closed-world); the description goes well beyond them by disclosing what the generated document does and does not contain — personal data is neither requested nor returned, and the document leaves name/DNI/address/contact as bracketed placeholders for the filer. This is exactly the behavioral context an agent needs and that annotations cannot supply.

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 purpose followed by the data constraint, and every sentence carries information. The closing pair ('No le pidas esos datos y no los escribas en la llamada') restates the earlier 'no pide ni devuelve datos personales' for emphasis, which is slightly redundant but serves as an actionable instruction.

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 characterizes the produced document (bracketed gaps, no personal data) and covers the one required parameter's role implicitly. It could still say more about the document's format or what the caller receives back, but the essential calling information is present.

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 the four fields are already documented, giving a baseline of 3. The description adds meaningful boundary information by stating what is deliberately NOT a parameter (nombre, DNI, domicilio, contacto), which prevents the agent from inventing fields the schema explicitly forbids via additionalProperties: false.

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?

Names a concrete verb+resource ('compone el escrito con el que se identifica al conductor de un vehículo') and pins down the exact triggering scenario (denuncia llega al titular y no conducía él). That scenario makes it clearly distinguishable from siblings like reposicion_contra_sancion_trafico or alegaciones_denuncia_trafico without opening their schemas.

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?

States clearly when to use it (when the complaint lands on the registered owner who was not driving, to avoid the fine and points loss) and adds an explicit usage constraint (do not request or include personal data). It never names an alternative sibling tool or an exclusion against them, so routing between the many 'escrito'-style siblings is left to inference.

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