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

Annotations already declare readOnlyHint=true, and the description adds substantive context beyond that: the calculation is derived from existing invoices and gastos, and modelo 202 assumes pagos_anteriores=0, so the figure is a raw base not a final payable amount. That caveat is exactly the kind of behavioral disclosure annotations cannot carry.

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 with purpose and the supported modelos, then caveat, return format, and the sibling alternative. Dense but every clause carries information; the modelo 202 warning is slightly long but genuinely necessary for correct interpretation of the output.

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?

No output schema exists, but the description explains the return shape (full AEAT breakdown of casillas as JSON). Period semantics are covered, though it doesn't state what happens if the period is omitted for a modelo that requires one.

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 0%, so the description must compensate, and it does for the tricky parameters: it maps quarter to 303/130/349 and periodo to 202, and the model enum values are all named in prose. Only 'year' is left unstated, though its meaning is self-evident.

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 ('Get an AEAT tax model summary') and enumerates exactly which modelos are supported (303, 390, 130, 347, 349, 202). It also distinguishes itself from the sibling calculate_modelo_303 by naming it explicitly.

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?

Gives explicit routing: use this tool for the full AEAT breakdown, and use calculate_modelo_303 instead if you only need to sum casillas by hand without querying the account. It also specifies which period parameter applies to which modelo (quarter for 303/130/349, periodo for 202).

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