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

Annotations already declare readOnlyHint=true, so the description correctly does not repeat that it's a read-only calculation. The description adds useful context about scope (single heir) and the integration warning about not combining it manually for comparisons. However, it does not disclose any potential limitations (e.g., approximations, jurisdiction-specific nuances) beyond what the annotation implies. Given the annotation covers the safety profile, a 3 is appropriate.

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 with zero waste. The first sentence states the core purpose, and the second provides essential routing guidance. Although the IMPORTANTE sentence is long, it is justified because it prevents a common misuse. The description is front-loaded with the main action and does not redundantly restate schema information.

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 description is complete for an agent to decide when to call this tool: it states the purpose, scope, and two critical alternatives. It does not describe the return format, but as a calculation tool without an output schema, that is not strictly necessary. The comprehensive schema covers parameter requirements, and the annotation covers safety. The only minor gap is that it doesn't mention it cannot handle multiple heirs or joint inheritances, but 'individual' implies that.

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 all 8 parameters are fully described in the input schema (e.g., edad_heredero's role for Group III and under-21 reductions, convivio_dos_anios requirement). The description adds no new parameter-level detail beyond the schema; it only mentions the existence of reductions and bonuses in general terms. With complete schema coverage, the baseline of 3 is correct.

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 clearly states the tool calculates the Spanish Inheritance Tax (ISD) for an individual heir with regional reductions and bonuses. It uses a specific verb ('Calcula'), names the resource ('Impuesto de Sucesiones'), and distinguishes it from both 'consulta_herencia' (general query) and 'comparar_donacion_vs_herencia' (comparison tool), making it unambiguous among 48 sibling tools.

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 explicitly tells when to use this tool versus alternatives: it directs the user to 'consulta_herencia' for general inheritance queries and explicitly warns against using this tool alone (or summing it manually) when comparing donation vs. inheritance, pointing to 'comparar_donacion_vs_herencia' instead. This is exemplary usage guidance with clear when-to-use and when-not-to-use conditions.

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