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

With no annotations, the description carries the transparency burden. It discloses that the tool is local and makes no network calls, and that it operates on cached data. It also specifies that invented names should fall below the threshold, giving insight into matching behavior. However, it does not describe what happens if the cache is empty or the output structure.

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 two sentences, front-loaded with the primary function and key constraints. Every word contributes meaning, including the local/no-network note and the threshold behavior. No redundancy or padding.

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 tool with no output schema and no annotations, the description is incomplete. It does not state what the search returns, how results are ordered, or the exact role of 'municipio' in scoping the cache. It also does not explicitly instruct to first run the population tools, though it implies their role. This leaves significant gaps for an agent to invoke it 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 description coverage is 0%, so the description must compensate. It explains 'umbral' via the threshold behavior, but 'municipio' and 'texto' are not explicitly described beyond their names. The names are fairly self-explanatory, but the description adds limited meaning for two of three parameters.

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's function: fuzzy search by place name over already cached parajes. It specifies the resource (cached parajes), the action (búsqueda difusa), and differentiates from siblings by noting it is local and relies on cache populated by catastro_ficha / catastro_completar_parajes.

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 when to use it: after other tools have populated the cache, for local fuzzy searching without network. It does not explicitly name alternatives or exclusions, but the context of caching and local operation gives clear usage context.

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?

With no annotations, the description carries the full burden and does well by disclosing key behaviors: it is resumable, skips entries that already have a record, respects a daily limit, and can be relaunched. This gives the agent a realistic picture of the tool's side effects.

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 concise sentences effectively front-load the main action and then provide essential resumability details. There is no redundant text or 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?

The description covers the core workflow and operational limits (resumability, daily cap), but it omits parameter semantics and return/error behavior. Given the tool's specialized batch nature, this is a strong but not perfect completion.

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 0%, yet the description only clarifies the 'rcs' parameter (list of RCs). The other parameters (municipio, municipio_mun, provincia_del) remain unexplained, forcing the agent to guess their formats and purpose.

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 action: iterate over a list of RCs and fill in missing 'paraje' via the official source, with a limiter. This distinctly sets it apart from sibling tools that query, download, or search.

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 provides clear context for use (batch completion of missing parajes) and explains resumability and the daily cap, but it does not explicitly name alternatives or state when not to use the tool.

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?

Without annotations, the description discloses side effects (builds local cache) and scope (no limit, GML official), but does not cover auth, rate limits, or return format. The context is helpful but not comprehensive.

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?

Three sentences deliver purpose, usage guidance, and parameter format without redundancy or 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 foundational download tool with no output schema, the description covers the purpose, parameter semantics, and usage threshold. It doesn't describe return values or edge cases, but it is adequate for this operation's simplicity.

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 explains that both provincia and municipio are numeric codes and gives a concrete example (Muxía: '15', '15053'), which adds meaning beyond the bare string schema. With 0% schema coverage, this is essential.

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 uses a specific verb 'Baja' (downloads) and resource 'parcelario INSPIRE completo del municipio', and explicitly defines its scope as foundational and for bulk operations, distinguishing it from sibling tools like catastro_parcela_local.

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 states 'Operación fundacional: el resto la da por hecha' and 'Cualquier operación sobre más de ~20 parcelas se resuelve aquí, nunca una a una', which clearly directs when to use this tool over per-parcel siblings.

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?

With no annotations provided, the description carries the full burden. It discloses that the operation is local and offline ('Local, sin red'), which is useful, but it does not state whether the operation is read-only, what the response format will be, or any side effects. This is a significant gap for a tool with no annotations.

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 extremely concise with no filler. It front-loads the core function and key parameter details in a single sentence, making every word earn 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 simple query tool, the description provides minimal information. It does not explain what the response will look like, whether it returns a list of parcels, or any prerequisites. Given no annotations and no output schema, this lack of detail makes the tool under-specified.

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 input schema has 0% description coverage, so the description must compensate. It explicitly indicates that x and y are in EPSG:25829 and radio is in meters, adding crucial meaning to the bare schema properties. It does not explain the optional srs parameter, but the default is provided in 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?

The description clearly states the tool returns parcels whose centroid falls within a circle, specifying coordinate system (EPSG:25829) and units (meters) for the inputs. While it lacks an explicit verb like 'returns' or 'searches', the intent is unambiguous and distinguishes it from siblings like catastro_por_coordenada.

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 tool versus alternatives. The phrase 'Local, sin red' provides some context about offline capability but does not mention exclusions or when to prefer this over sibling tools like catastro_vecinas or catastro_por_coordenada.

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?

With no annotations, the description carries the burden of explaining what the tool does. It discloses the testing method (three-pronged check against two hosts, canary) and the interpretation logic (distinguishes data error from IP block). It also adds context about 403s, going beyond a generic 'check status' description.

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 three sentences long and each sentence adds information: method, usage, and interpretation. It is compact and well-ordered, though the heavy use of technical shorthand ('RC', 'canario') might reduce immediate clarity. No wasted words.

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 tool is complex and has no output schema or annotations. The description explains the diagnostic approach and the meaning of differences, but it does not describe what the tool returns (e.g., a status code, a string, a boolean) or how to map the outcome to specific outputs. This is a notable gap for an agent that needs to act on the result.

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 input schema has 0% description coverage, and the description provides no information about the 'municipio' and 'provincia' parameters. It does not explain their role, accepted values, or how they affect the check. The parameter names are self-explanatory, but no additional meaning is added, which is required given the lack of schema descriptions.

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 diagnostic function ('Control de tres puntas contra ambos hosts') and distinguishes two failure modes, but uses jargon ('RC que funcionó + RC inventada', 'canario') that requires domain knowledge. It is not a clear, straightforward statement of purpose like 'Check connection status'.

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?

Explicit usage guidance is provided: 'Llamar antes de una tanda y cuando algo devuelva vacío' and 'Un 403 aislado no dice nada'. This clearly indicates when to use the tool and when not to rely on a lone 403, though it does not name specific alternative tools.

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?

With no annotations, the description carries full burden and does so admirably. It discloses the host and its resilience to blocks, clarifies that the surface data is informative ('informativa; la oficial es la del GML'), and specifies accepted RC formats and missing data types. This provides rich behavioral context beyond a simple action.

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 a single dense sentence packed with information, but it remains relatively concise given the breadth of content. It uses parentheses and colons to organize details efficiently. While it could be better structured with separate sentences, every clause adds value.

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?

Given no output schema and no annotations, the description covers the essential aspects: purpose, input formats, limitations, and an example. It lists return fields (paraje, clase, uso, etc.) but does not describe the response structure or error behavior, which keeps it from a perfect score.

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?

Despite 0% schema description coverage, the description explains parameter semantics. It defines RC formats ('RC de 20. Acepta RC de 14') and gives concrete examples for provincia_del/municipio_mun ('Muxía: del \'15\', mun \'53\''). This adds significant meaning beyond the bare schema properties.

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's purpose: 'Consulta la sede electrónica' with specific data fields (paraje, clase, uso, superficie gráfica, RC). It is specific about what it returns, but it does not explicitly differentiate from sibling tools by name, though the 'ficha' (record) nature and detail imply a targeted lookup.

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 provides usage context: it mentions the host differs from the OVC ('distinto del OVC — sobrevive a sus bloqueos'), indicating when this tool is preferable. It also warns about what is not available ('NO existe por vía pública: valor de referencia... ni titularidad') and explains parameter code formats. However, it does not explicitly name alternative tools for those cases.

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?

No annotations are provided, so the description must carry the full transparency burden. It discloses the exact data source (areaValue del GML, the only accepted source), the outputs (centroid and geometry), and the cache/network behavior. However, it omits details about potential errors, cache staleness, or what happens if the cache is not populated.

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 a single, compact sentence that front-loads the core outputs and key behavioral constraints (cache, no network). Every word contributes value, with no redundancy or 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 simple 1-parameter readonly lookup, the description covers the essential return values (area, centroid, geometry), the authoritative source (GML areaValue), and the network behavior. It lacks an output schema but explicitly lists what the tool returns. Minor gaps around error handling and cache availability prevent a perfect score.

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 input schema already fully describes the single parameter 'rc' with the constraint 'referencia catastral de 14 o 20 caracteres', giving 100% coverage. The description adds no extra semantic detail about the parameter, so the baseline 3 is appropriate.

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 returns 'Superficie oficial (areaValue del GML — la única fuente aceptada), centroide y geometría' from cache without network. It identifies a specific resource (parcela_local) and its outputs, but does not explicitly contrast with sibling tools, relying on the cache/network distinction to imply differentiation.

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 phrase 'desde caché, sin red' implies this tool is intended for situations where network access is unavailable or cached data is preferred. However, there is no explicit guidance on when to use this tool versus siblings like catastro_ficha or catastro_por_coordenada, nor any stated exclusions or prerequisites.

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?

With no annotations, the description carries the full burden. It discloses that it uses OVC and hints at a caching preference, but it does not mention whether the operation is read-only, what happens on invalid coordinates, or whether any side effects occur. It is better than nothing but lacks substantial behavioral detail.

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 a single, well-structured sentence with no unnecessary words. It front-loads the core purpose and adds the key usage hint. This is appropriately concise.

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?

Given the tool has 3 parameters, no output schema, and no annotations, the description is too thin. It omits parameter explanations, output format, and edge-case behavior. It provides some usage guidance but is insufficient for an agent to invoke the tool correctly in diverse scenarios.

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%. The description does not explain the meaning of x, y, or srs, nor their units or coordinate system. It provides no parameter-level insight beyond the bare schema, so it fails to compensate for the lack of schema descriptions.

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's function: it resolves which parcel exists at a given point using the OVC service. It also distinguishes itself from the sibling tool catastro_en_radio by explicitly mentioning a preference condition, making its specific role unambiguous.

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 says 'Prefiere catastro_en_radio si el municipio está cacheado', which tells the agent when to use an alternative tool, and by implication when to use this one (when the municipality is not cached). This is clear contextual guidance.

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?

The description discloses that provincia/municipio must be provided in OVC text format, with examples ('A CORUÑA', 'MUXIA'), which is a meaningful behavioral constraint. However, with no annotations present, the description carries the full burden, and it does not mention permissions, return value, error behavior, or other potential side effects. It adds partial transparency but not a complete picture.

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 a single sentence with a clarifying parenthetical, containing no redundant words. It is front-loaded with the main action and includes only necessary details about input format. Every element 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 simple lookup tool, the description conveys what it does (resolves RC), the key input format constraint, and the underlying service (OVC). It lacks details about return structure or error handling, but these can be partially inferred from the tool name and the explicit mention of 'RC' as the output. Given the tool's low complexity, this is reasonably complete, though not exhaustive.

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. It provides explicit format guidance for provincia and municipio (OVC text), but leaves poligono and parcela completely unspecified beyond their string type in the schema. This adds partial value, but fails to fully compensate for the lack of schema descriptions on two of the four required parameters.

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's function: 'Resuelve la RC desde polígono/parcela vía OVC' – resolving a cadastral reference from polygon/plot via a specific service. This is a specific verb+resource combination that distinguishes it from siblings like catastro_por_coordenada (by coordinate) or catastro_ficha (by cadastral reference).

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 phrase 'desde polígono/parcela' provides clear context for when to use this tool: when the user has polygon and parcel identifiers. Although it does not explicitly mention alternatives or exclusions, the context is unambiguous, and the tool name reinforces the use case.

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?

With no annotations, the description carries the transparency burden. It discloses core behavior: distance-based filtering, cardinal orientation inclusion, and local/no-network execution. However, it omits details such as edge cases, output format, or what happens with no matches.

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 a single compact sentence that packs essential operational details without filler or repetition, making it highly efficient.

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?

Given no output schema and no annotations, the description is too terse to provide complete context. It fails to explain the input parameter rc, the structure of the output, or edge cases, making it insufficient for robust tool selection and 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 0%. The description explains contacto_max as a distance in meters but does not explain the rc parameter at all, leaving its format and purpose ambiguous beyond 'una dada'.

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 identifies the tool's purpose: it returns parcels that touch or are within a configurable distance of a given parcel, and it mentions cardinal orientation. This distinguishes it from siblings like catastro_en_radio, though it lacks an explicit verb like 'returns'.

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 explicit guidance is given on when to use this tool versus alternatives like catastro_en_radio or catastro_ficha. 'Local, sin red' implies an offline context, but it does not state when to prefer this tool or when not to use it.

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