dataprem_catastro_lookup

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

With no annotations, the description carries the transparency burden. It discloses a key behavioral limitation: the endpoint does not expose 'titular' because of the free SOAP and public API LOPD/GDPR constraints, and mentions a future authorized pipeline. It also summarizes the normalized record and return breakdown, giving the agent a good behavioral model. Minor gaps: no error behavior or required-coupling enforcement, but the search-mode rules are stated.

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 description is well-structured with a clear lead sentence, bullet-style mode summaries, a brief output summary, and an Args list. A bit lengthy due to the GDPR/future-pipeline note, but that content provides meaningful behavioral context and earns its place.

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 lookup with an output schema present, the description covers the two valid input modes, the expected response shape (class, use, surfaces, construction year, INE codes, constructions[]), and a privacy limitation. It doesn't specify what happens on invalid/no-match input, but the overall context is sufficient for a competent agent to select and invoke the tool correctly.

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 has 0% description coverage and all four params are nullable with no descriptions, so the description must add meaning. It does: refcat length (14/18/20), address format ('tipo + nombre + número'), city as municipality, province as optional, and the mode-based coupling (address+city). This substantially compensates for schema gaps.

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?

Description opens with 'Consulta datos catastrales de un inmueble en el Catastro español', naming exact verb, resource, and domain. It distinguishes this from sibling tools (BORME, CENDOJ, tenders) by focusing on the Spanish cadastre, and clarifies the two lookup modes.

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?

It explicitly defines two mutually exclusive search modes ('Por referencia catastral' vs 'Por dirección') and states which parameters to pass, with province optional. It also warns that owner/titular data is not exposed, which is a clear when-not-to-use indicator. However, it doesn't explicitly contrast with sibling tools, though they are clearly different domains.

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