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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is added context — and it delivers: every figure carries source, period and read date; unpublished values come back as null with the reason; the response includes the yearly price series since 2013 and five dimension indices with cut-off dates. That is real disclosure about data provenance and completeness that the annotations do not 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?

The scope is front-loaded ('Everything Verithic publishes for one municipality'), but the body is a long enumerated list presented twice, once per language, which roughly doubles the length without adding information. The bilingual mirroring is defensible for a bilingual product, yet it is not economical prose.

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, so the description carries the burden of explaining returns — and it does so well, spelling out the field catalogue, the null-with-reason convention, provenance metadata, and the included series and indices. What an agent receives is clear; only the absence of any routing to overlapping siblings leaves a gap.

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% and both parameters (municipio with name/slug forms, language enum) are documented in the schema. The description adds nothing about parameter syntax or defaults, so the baseline 3 applies — the schema does the work and the prose neither helps nor hurts.

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 and scope: the complete published dataset for one municipality ('Everything Verithic publishes for one municipality'), then enumerates the concrete fields (price €/m², IBI, rent, transport, rent-cap zone, tourist flats, empty homes, satisfaction). 'One municipality' implicitly sets it apart from comparar_municipios or listar_municipios, but no sibling is named explicitly, so differentiation is left partly to inference.

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?

There is no when-to-use or when-not guidance, and no alternative is named despite a crowded sibling set with clear overlap (comparar_municipios for multiple, zona_tensionada_2027 for a single dimension, alquiler_ano_a_ano for the rent series, ranking_por_perfil for ranking). The 'everything for one municipality' framing implies usage, but the agent must infer that this is the broad profile rather than a focused lookup.

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