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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful output context by mentioning HTML and PDF links, but it does not disclose pagination behavior, rate limits, or authorization requirements.

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?

It is a single, front-loaded sentence with no wasted words. The core action and scope are immediately clear.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description is complete enough for basic invocation, though it omits any mention of the optional query, section, or limit filters that the schema supports.

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 75%, and the schema already documents day, query, and section. The description only implies a day-based listing and does not add syntax or filtering meaning beyond what the schema provides, so it stays at the baseline level.

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 gives a specific verb and resource: 'List what the BOE published on a given day.' It also adds output detail ('with links to HTML and PDF'), so an agent can immediately understand the tool's scope without opening the schema.

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 explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisite information. The purpose implies a daily BOE listing, but routing guidance is absent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety and idempotency profile is covered by structured data. The description adds nothing on top of that: no note on external-service dependency or latency, no handling of invalid/unmatched references, and no behavioral nuance beyond what the annotations and output schema already convey.

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?

One short sentence with the verb, output, and input all front-loaded; there is no filler, hedging, or redundancy to trim.

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?

An output schema exists, so return-value explanation is not required, and the single parameter is fully documented in the schema. What is missing for this one-param tool is the disambiguation from its inverse sibling, which the description never addresses; otherwise it is adequate for such a simple lookup.

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 the single parameter already documents the '14 or 20 character cadastral reference' format, so the schema carries the burden. The description adds no syntax, normalization, or format guidance beyond restating 'cadastral reference', which is the baseline-3 case.

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 states a specific verb ('Get') and two concrete resources ('address and coordinates') scoped to a 'cadastral reference' input, so the direction of the lookup is unambiguous. It does not name its exact inverse sibling, catastro_reference_from_coordinates, so an agent must infer the distinction from the phrasing alone.

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 only implied: the phrasing signals a forward lookup (reference in, address/coordinates out), which is the natural counterpart to the coordinate-to-reference sibling. There is no explicit statement of when to prefer this over catastro_reference_from_coordinates or catastro_property_details, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint and idempotentHint, so further safety disclosure isn't required. The description adds the candidate/ambiguation behavior, which is valuable, but is silent on return format, provenance, or failure modes beyond the candidates case.

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 compact sentences that front-load the requested fields and then state the multi-property behavior; no filler.

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 with a documented parameter and output schema, the description covers purpose and the only surprising behavior (candidate fan-out). It could be more complete if it mentioned what the return object contains or whether the 20-char form bypasses candidates.

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 coverage is 100%, so the schema already documents the single parameter. The description adds only that a 14-char reference can return `candidates` and a retry is needed; this supplements but does not replace schema semantics.

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 (property) and the exact attributes returned (use, built area, year built, units). Names the sibling function it is not, and its input domain (parcel reference) is clear.

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 implies usage via the candidates note; it explains what happens when a 14-char reference matches several properties and directs a follow-up call. However, it does not say when NOT to use it or name alternatives like catastro_coordinates_from_reference.

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

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

Annotations already declare readOnly, idempotent and openWorld, so safety is covered. The description adds genuine non-annotation behavior: the fallback to match='nearby' with a distance_m field when the point is not on a parcel. It says nothing about rate limits or upstream failure modes, but for a read-only lookup that is a minor gap.

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, and the primary purpose is front-loaded ahead of the edge-case behavior. Every clause carries information the agent needs.

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?

An output schema exists, so return values need not be enumerated; the description instead flags the one response variant that matters (nearby match plus distance_m). Combined with full schema coverage and annotations, nothing needed to call this tool correctly is missing.

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 (latitude, longitude) carry WGS84 labels plus Spain-bounding min/max constraints. The description adds no parameter-level syntax or format detail beyond that, so the 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 verb ('Find') and resource ('cadastral parcel and address') with an explicit geographic scope ('at a point in Spain'). It is readily distinguishable from the sibling catastro_coordinates_from_reference, which performs the reverse lookup, without opening either schema.

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 second sentence gives the operative condition of use: if the point falls on a street or square, the result set changes to nearby parcels. It clearly frames the input context but never explicitly names the alternative tool (catastro_coordinates_from_reference) for the reverse direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered by structured data. The phrase 'latest values' adds useful scoping (recent points rather than full history), but the description says nothing about rate limits, upstream INE availability, or how last_n governs the returned window.

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?

A single front-loaded sentence with zero waste. Its brevity is efficient, though it edges toward under-specification rather than pure conciseness.

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?

An output schema exists so return values needn't be explained, but for a tool with an undocumented last_n parameter, no usage guidance, and no sibling differentiation, the description leaves meaningful gaps for correct invocation.

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 only 50%: series_code carries an example in the schema, while last_n is undocumented in both schema and description. The description adds no meaning beyond the structured fields — it never mentions the window size parameter at all.

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 and resource ('fetch the latest values of a single INE series'), which tells an agent this retrieves data points rather than metadata. It doesn't explicitly contrast with siblings like ine_get_table or ine_list_tables, so an agent must infer the boundary from the noun 'series' alone.

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 guidance, no prerequisites, and no mention of alternatives such as ine_get_table or ine_search_operations. The agent must infer that this tool applies once a series code is already known.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and repeat-call behavior are covered. The description adds only that it returns 'latest values' for series in a table, with no extra detail on rate limits, auth, or data freshness semantics.

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?

Single sentence, front-loaded with the verb and resource, with no filler. It is appropriately sized for a simple read tool.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, the description omits when to choose this over ine_get_series and leaves max_series undocumented, making it incomplete for routing and full parameter interpretation.

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?

The description adds no parameter meaning; it does not explain query, last_n, table_id, or max_series. Schema coverage is 75% (query, last_n, and table_id are described; max_series is undocumented), so the schema does most of the work, but max_series remains unexplained anywhere.

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 'Fetch' and resource 'latest values of the series in an INE table,' which is more precise than the title alone. It distinguishes the table-oriented data retrieval from siblings like ine_list_tables or ine_get_series by scoping to series within a table, though it does not name alternatives 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?

No when-to-use guidance, no alternatives, and no exclusions are provided. The agent must infer that ine_list_tables supplies the table_id and that ine_get_series is for a different scope.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, covering the safety profile, but the description adds nothing beyond them. It says nothing about result size, truncation, or how the default limit of 50 / maximum of 200 affects the listing.

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?

A single front-loaded sentence with no filler. It is efficient, though its brevity edges into under-specification rather than pure conciseness.

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?

An output schema exists, so return values need not be described, and the core purpose is conveyed. Still missing is the link to ine_search_operations for obtaining the required operation code and any note on how limit interacts with large result sets.

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 67%: query and operation are documented in the schema, while limit has no description anywhere. The description reinforces that results are scoped to an operation but adds no syntax, format, or pagination detail beyond the schema.

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 and resource ('List the data tables published for an INE operation'), which is unambiguous on its own. However it does not distinguish itself from siblings like ine_get_table or ine_get_series, so an agent must infer the boundary from the names alone.

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 guidance on when to use this versus ine_get_table or ine_get_series, and no mention that the operation code typically comes from ine_search_operations. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one genuinely useful behavioral fact — 'Accent-insensitive' matching — but says nothing about pagination, how the limit interacts with results, or match/ranking behavior.

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 short sentences with zero filler, and the core action is front-loaded. It is terse to the point of omitting useful context, but nothing present is wasted.

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?

An output schema exists, so return-format explanation is not required. However, for a search tool with an undocumented 'limit' parameter, the description should say more about result volume/paging; accent-insensitivity alone is a thin addition.

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 only 50%: 'query' is documented in the schema with an example, but 'limit' has no description beyond default 25 / max 100. The description's operation examples (IPC, EPA) implicitly illustrate good query values, which partially compensates, landing at the baseline.

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 ('Find') and resource ('INE statistical operations') and gives concrete examples (IPC, EPA, Índice de Precios de Vivienda) that make the domain unambiguous. It's clearly the discovery/search tool versus the retrieval siblings (ine_get_table, ine_get_series), though it never names them.

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 offers no when-to-use guidance, no prerequisites, and no mention of the sibling tools (ine_list_tables, ine_get_table) that an agent might pick instead. Usage is only inferable from the verb 'Find'.

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