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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety and closed-world scope are covered. The description adds real value beyond that: it flags that the e-invoicing dates are provisional 'counted from the ministerial order' while the order is a draft, and that output is 'information about the rules, not advice' – important caveats for relying on the answer.

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, no filler. The purpose and legal basis are front-loaded, and the provisional/not-advice caveats are packed economically at the end.

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?

For a read-only lookup tool with annotations covering safety and required params covering input, the definition is essentially complete. It does not describe the shape of the returned deadline data, but with no output schema that gap is minor and the description signals the domains the dates span.

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%, including the enum semantics for forma and the meaning of factura_a_empresas, so the schema does the heavy lifting. The description adds only tacit context (which regimes the answers pertain to) and no per-parameter detail beyond the schema; 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 specific resource (Spanish compliance deadlines) and names the exact regimes (Veri*factu, mandatory B2B e-invoicing) with their legal citations. This clearly separates it from the calculation/validation siblings (calculate_modelo_303, check_vat_number, validate_iban), though the phrasing leads with the rules rather than a crisp verb+object like 'returns deadline dates for a taxpayer profile'.

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?

Usage is implied by the required taxpayer-profile parameters (forma, factura_a_empresas), but the description never states when to reach for this tool versus a sibling, nor any prerequisites or exclusions. No alternative is named.

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