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

With no annotations, the description carries the burden of behavioral disclosure. It provides useful context (e.g., x/y coordinate interpretation for EPSG:4326, output as JSON dict), but does not mention error handling, coordinate system support nuances, or limitations. Some behavioral info is present, but it is 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?

The description is concise and well-structured with clear sections for Uso, Entradas, and Salida. Every sentence adds value, and the core purpose is front-loaded. No unnecessary repetition.

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's moderate complexity and the presence of an output schema (which removes the need to explain return structure in detail), the description is mostly complete. It covers parameters and output type, but could be improved by noting supported coordinate systems or potential edge cases. Overall, it is adequate for the task.

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's parameter annotations are essential. It adds meaning to all three parameters: x is CoorX (longitude if EPSG:4326), y is CoorY (latitude if EPSG:4326), and srs is the reference system with an example. This compensates well for the schema's lack of 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 with a specific verb and resource: 'Devuelve la(s) referencia(s) catastral(es) asociadas a unas coordenadas.' This distinguishes it from sibling tools like 'rc_a_coordenadas' which performs the reverse operation.

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 no explicit guidance on when to use this tool versus alternatives. It includes a 'Uso:' label but only restates the purpose, without mentioning exclusions or comparing to sibling tools such as 'distancia_coordenadas_a_rc' or 'rc_a_coordenadas'.

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 carries the full burden. It discloses the data scope ('datos catastrales no protegidos') and implies a read-only operation via 'Consulta'. It also mentions the dependency on prior calls to sibling tools. However, it does not describe error behavior, response size, rate limits, or any side effects, leaving some behavioral aspects undisclosed.

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 clear sections (Uso, Entradas, Salida) and the purpose is front-loaded. Each line delivers necessary information without redundancy, though the parameter list is verbose by nature. It earns its place and is not overly wordy.

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?

With 9 parameters, 5 required, and no annotations, the description covers all inputs and the output, and explicitly references the necessary sibling dependencies. The output schema exists, so return values are not under-explained. What it lacks are examples or edge-case notes, but the tool's operation is straightforward enough.

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%, but the description compensates thoroughly. For each parameter it states the type, required/optional status, and often the source of valid values (e.g., 'según ObtenerProvincias'). For 'sigla', it even clarifies the expected code format (CL, AV, PZ, etc., Anexo II). This adds substantial meaning beyond the bare schema names and types.

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 los datos catastrales no protegidos de un inmueble por su localización' (Query non-protected cadastral data of a property by its location). It uses a specific verb ('Consulta') and resource, and the location-based scope distinguishes it from siblings like dcnp_por_rc (by reference) and dcnp_por_poligono_parcela (by polygon/parcel).

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 implicit workflow guidance by specifying that parameter values should come from sibling tools ('según ObtenerProvincias', 'según ObtenerMunicipios', etc.). This tells the agent to first call those tools to populate the inputs. However, it does not explicitly contrast with alternative lookup methods like dcnp_por_rc, so exclusions are missing.

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 of behavioral disclosure. It notes the data is 'no protegido' and uses 'Consulta' to imply read-only behavior, but it does not describe any permissions, rate limits, error handling, or the structure of the return JSON beyond calling it a 'dict'. The absence of annotation context makes this a significant 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?

The description is well structured with sections for Uso, Entradas, and Salida. It provides all necessary information in a compact form without redundant text, making it easy to scan and understand.

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 parameterized query, the description covers the essential inputs and output type, but the output is only described as 'dict: respuesta JSON del servicio'. Without an output schema or more detail on the response contents, the agent may not know how to interpret the result, and no error or edge-case behavior is mentioned. Given the tool's simplicity, it is minimally viable but lacks deeper completeness.

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 schema has no descriptions, so the description fully compensates by explaining each parameter's semantics, including that provincia and municipio should follow the naming from ObtenerProvincias and ObtenerMunicipios. It also clarifies that polygon and parcel are 'catastral' identifiers, which adds meaningful context beyond the bare schema types.

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 'Consulta' and identifies the resource as 'datos catastrales no protegidos de un inmueble' accessed by 'polígono y parcela'. This clearly distinguishes it from sibling tools that use RC, address, or coordinates as input.

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 context by specifying that the input must be a polygon and parcel, and that province and municipality names must follow those from ObtenerProvincias and ObtenerMunicipios. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions, so the guidance remains implied rather than explicit.

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 a non-obvious behavior: for 14-position references, it returns a list of all properties in the finca. However, it does not mention error handling, permission requirements, or the meaning of 'non-protected' data, which would be important for an agent.

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 structured with clear sections for usage, inputs, and output, and every sentence serves a purpose. It is concise and front-loaded with the main purpose, avoiding redundancy.

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 presence of an output schema (stated in context), the description adequately covers the input semantics and the key behavioral rule (14-digit expansion). It misses a few contextual aspects like alternative use cases, but for the core functionality, it is complete enough.

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?

With 0% schema coverage, the description compensates for refcat by explaining its format (14, 18, or 20 positions) and the list-return behavior for 14 positions. It only labels provincia and municipio as 'opcional' without further detail, which limits the score.

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 names the tool's action ('Consulta los datos catastrales no protegidos') and specifies the input (Referencia Catastral), making it distinct from sibling tools that query by address or return GeoJSON. However, it does not explicitly reference sibling tools or differentiate them, so it misses the top score.

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 no guidance on when to choose this tool over alternatives like dcnp_por_direccion or parcela_geojson_por_rc. It only explains input behavior for 14-digit references, not usage context or exclusions.

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 explains the output contents (nearby references, addresses, distance) and the JSON response format. However, it does not disclose error handling, edge cases (e.g., no results), or side effects, which is a moderate gap for a lookup tool.

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 clear sections (Uso, Entradas, Salida). Each sentence serves a purpose, avoids fluff, and is appropriately sized for the tool's simplicity.

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 function, inputs, and output type. It does not detail the JSON response structure, but an output schema exists (even though not shown), so that is acceptable. It lacks some behavioral details (e.g., error conditions) but is otherwise complete for a straightforward query tool.

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%, so the description must compensate. It does so effectively by explaining each parameter: x and y as coordinates with typical longitude/latitude for EPSG:4326, and srs with an example. This adds meaning beyond the raw schema types.

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 and resource: 'Devuelve la(s) referencia(s) catastral(es) por proximidad a unas coordenadas.' It clearly distinguishes from the sibling 'coordenadas_a_rc' by emphasizing the proximity search and inclusion of distance and address details.

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 context that this tool is for proximity-based lookups and includes distance calculation, but it does not explicitly mention when to use this instead of the similar sibling 'coordenadas_a_rc'. Usage is implied rather than explicitly contrasted.

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 key behaviors: GeoJSON is always WGS84 lon/lat, GML respects the srs parameter, falls back to EPSG:4326 if pyproj is missing, out_dir must be within EXPORT_ROOT, and basename defaults to ref14. This goes beyond the schema and reveals important constraints and fallbacks.

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 'Uso', 'Entradas', and 'Salida' sections, front-loading the purpose. Every line adds value, including edge-case fallback behavior. It is appropriately sized for five parameters with no fluff.

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?

Despite having 5 parameters and no annotations, the description covers the tool's purpose, parameter meanings, output format, and a critical fallback condition. It is complete enough for an agent to use the tool correctly without needing external documentation.

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%, and the description fully compensates by explaining each parameter's meaning: refcat uses base 14, srs is 'AUTO' or an EPSG/URN for GML, out_dir must be inside EXPORT_ROOT, basename defaults to ref14 when empty, and overwrite controls overwriting. This adds rich semantics beyond the bare schema types.

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 ('Exporta') and resource ('GML + GeoJSON de una parcela'), clearly stating the tool's combined output. It distinguishes from siblings like parcela_gml_por_rc and parcela_geojson_por_rc, which export only one format.

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 this tool ('en una sola llamada' – to get both formats at once) and provides clear context for the GML/GeoJSON behavior. However, it does not explicitly name alternatives or exclude them, so it stops short of full when/when-not 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the output IFC includes a minimal structure (listing specific IFC entities), uses local coordinates with georeferencing, and that the tool may request a base GML based on the 'srs' parameter (implying external data fetching). It also mentions the 'overwrite' parameter's effect. This goes beyond a minimal description, though it doesn't explicitly warn about file system writes or error cases.

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-organized with clear sections for 'Uso', 'Entradas', and 'Salida'. It uses bullet points for the IFC structure and parameter list, making it scannable. Every sentence contributes value—there is no fluff or redundancy. The structure is front-loaded with the purpose statement.

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's complexity (5 parameters, no nested objects, output schema exists), the description is quite thorough: it covers all parameter semantics, the output (ruta del IFC y metadatos), and the IFC structure. However, it omits some contextual details, such as required permissions, network dependencies, or error handling, which would be valuable for fully autonomous use. The presence of an output schema reduces the burden for return-value details, but the description could still be slightly more complete.

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 provides a dedicated 'Entradas' section explaining each parameter: refcat (with base 14 detail), srs (AUTO or EPSG/URN), out_dir (within EXPORT_ROOT), basename (empty defaults to ref14), and overwrite (whether to overwrite). This fully compensates for the lack of descriptions in the schema (0% coverage), adding significant meaning beyond the raw 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's function: 'Exporta una parcela catastral a IFC4 como superficie plana cerrada.' This includes a specific verb ('exporta'), a resource ('parcela catastral'), and a format ('IFC4'), making it immediately distinguishable from sibling tools that export GML/GeoJSON or return GeoJSON data.

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 clear context for when to use the tool (for exporting parcels to IFC4 for BIM environments like Bonsai). It does not explicitly name alternative tools for other export formats, but the purpose-focused wording and the mention of IFC-specific needs implicitly guide the agent. The lack of explicit 'when not to use' phrasing prevents a perfect score.

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 the output format (dict: JSON response from service) and the input constraint (province name per ObtenerProvincias). It does not mention read-only nature, potential errors, or pagination, but the simplicity of the operation partially mitigates this.

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 concise and well-structured with clear sections (Uso, Entradas, Salida). Every sentence provides necessary information without redundancy or fluff.

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's low complexity (2 simple parameters, no enums, output schema present), the description covers the essential aspects: purpose, parameters, and output format. It lacks error handling details but is otherwise complete for a straightforward list operation.

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 schema has zero description coverage (0%), but the description compensates well by explaining that 'provincia' is a province name according to ObtenerProvincias and that 'municipio_filtro' is an optional partial text. This adds meaningful context beyond the bare type definitions.

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 action with a clear resource: 'Lista municipios de una provincia' (lists municipalities of a province). It also mentions an optional filter, making the tool's purpose unambiguous and distinct from sibling tools like obtener_provincias or obtener_vias.

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 context by indicating the province parameter should follow 'ObtenerProvincias', implying a prerequisite workflow. It also explains the optional filtering capability. However, it does not explicitly state when not to use this tool or mention alternative tools for other municipal data.

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 behavioral disclosure burden. It states the return behavior: 'devuelve RC del número si existe o aproximación', and that 'numero' can be partial, implying approximate matching. This adds meaningful context beyond the name, though it doesn't cover error handling or authentication.

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 'Uso:', 'Entradas:', and 'Salida:' sections. It front-loads the purpose in the first line and every subsequent line serves a purpose, providing necessary parameter guidance without wasted text.

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's complexity (5 required parameters, no schema descriptions) and the presence of an output schema, the description sufficiently covers the invocation context: it explains the data dependencies, parameter formats, and the approximate behavior. It could be more explicit about error cases, but overall it's functionally complete.

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 does so by listing all 5 parameters with brief but useful explanations: e.g., tipo_via is 'idealmente código: CL, AV, PZ, etc. Anexo II' and other params are constrained to outputs of specific sibling tools. This adds meaning beyond the bare 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 'Consulta número de una vía' and specifies the output: 'devuelve RC del número si existe o aproximación'. This is a specific verb+resource+scope, and it distinguishes from sibling tools by focusing on querying a road number to obtain a cadastral reference (RC).

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 gives clear context for when to use this tool: it requires inputs 'según ObtenerProvincias', 'ObtenerMunicipios', and 'ObtenerVias', implying a sequence of lookup calls. It also advises using a code for tipo_via (e.g., 'CL, AV, PZ'). It lacks explicit when-not-to-use or alternative tool comparisons, so it's not a 5.

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 burden. It only states the output type ('dict: respuesta JSON del servicio'), but does not disclose behavioral traits such as network calls, caching, or error behavior. 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 and well-structured with 'Uso:', 'Entradas:', and 'Salida:' sections. Every line serves a purpose, and it front-loads the main verb and resource.

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 trivial with no parameters and an output schema. The description covers purpose and output format, which is mostly complete. It doesn't mention potential limitations or context about the Catastro service, but given the simplicity, this is adequate.

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 tool has zero parameters, and the description matches this with 'Entradas: -'. Per the rubric, a baseline of 4 applies for zero parameters; the description adds no extra semantics but is consistent with 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 verb and resource: 'Lista provincias disponibles en los servicios del Catastro' (List provinces available in Catastro services). This distinguishes it from sibling tools like obtener_municipios (municipalities) and obtener_vias (streets).

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 when you need a list of provinces but provides no explicit exclusions or alternatives. It lacks comparative guidance against sibling tools like obtener_municipios, so it only meets the 'implied usage' criterion.

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 behavioral disclosure. It explains the input parameters, optional filtering behavior, and says output is a dict (JSON). However, it does not disclose potential side effects, error conditions, or prerequisites beyond referencing ObtenerProvincias/ObtenerMunicipios for valid name formats.

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 clear sections (Uso, Entradas, Salida) and is front-loaded with the main purpose. It is concise, with no filler, but slightly more verbose than necessary for a simple list 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?

The description covers inputs and the general return type but lacks details on the output structure (e.g., a list of street names vs. full objects), error handling, or how to interpret the JSON response. Given no output schema is provided, more completeness would be beneficial.

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 compensates by explaining each parameter: provincia and municipio are names from prior tools, tipo_via is an optional code (with examples CL, AV, PZ), and via_filtro is a partial text to search. This adds meaning beyond the bare 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 'Lista las vías / calles de un municipio' (lists streets/roads of a municipality), which is a specific verb+resource combination. It also mentions an optional partial-name filter, distinguishing it from sibling tools like obtener_provincias or obtener_municipios.

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 ('de un municipio', 'podemos filtrar por nombre parcial') but does not explicitly specify when to prefer this tool over siblings or mention exclusions. No alternatives are referenced, so usage is implied rather than explicitly contrasted.

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 transparency burden. It discloses the forced EPSG:4326 reprojection, the swap to lon/lat, the reason (avoiding pyproj and CRS issues), and that srs is accepted only for compatibility but overridden internally. It also specifies the exact output dictionary keys.

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 clear sections (Uso, Entradas, Salida) and bullet points. Every sentence adds value, and the technical rationale for CRS handling is concise and relevant. It is appropriately sized for the complexity.

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 only two parameters and the description covers purpose, parameter semantics, internal behavior, and output structure, it is fully complete. The lack of annotations is compensated by detailed behavioral notes, and the output schema is preemptively outlined in the Salida section.

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 provides no descriptions, so the tool description is essential. It explains refcat as RC using base 14, and srs as retained for compatibility but forced to EPSG:4326. This adds critical meaning beyond the raw schema, especially for srs.

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 opens with 'Devuelve GeoJSON (FeatureCollection) de una parcela por RC' – a specific verb (Devuelve) and resource (GeoJSON FeatureCollection by RC). It clearly distinguishes from sibling tools like parcela_gml_por_rc by specifying the JSON output format and coordinate system.

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 gives clear context for when to use the tool: when a GeoJSON in lon/lat WGS84 is needed and reprojection issues should be avoided. It does not explicitly name alternatives or state when not to use it, but it implies the intended use case strongly enough.

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 available, the description carries the full burden and discloses key behavioral traits: it uses a specific StoredQuery, employs a two-step CRS negotiation in AUTO mode (requests 4326, detects zone, then requests supported UTM), and explains regional CRS support differences. The output dict with 'ok' and 'diagnostic' implies error handling. It does not explicitly state read-only semantics but it's implied by 'GetParcel'.

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 sections (Uso, Nota importante, Entradas, Salida) and front-loads the main purpose. The CRS caveats are essential and not padding. Every line adds value; it's appropriately sized for a tool with complex CRS handling.

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's complexity (CRS negotiation) and the lack of annotations, the description covers purpose, parameters, CRS fallback behavior, and output schema. It doesn't mention external dependencies like service availability or error scenarios beyond the diagnostic field, but the output schema likely covers the return structure. Overall, it's quite complete.

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 schema provides no descriptions (0% coverage), but the description compensates fully. For refcat, it explains the acceptable formats (14/18/20) and that a base of 14 is used. For srs, it lists valid values (AUTO, EPSG:4326, EPSG:25830, EPSG:32628, EPSG::25830, URN) and explains the AUTO behavior, adding significant meaning beyond the bare 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's function: 'Obtiene el GML de UNA parcela por RC' (gets the GML of one parcel by RC) using StoredQuery GetParcel (WFS CP Catastro). It specifies the resource (GML), scope (one parcel), and method, distinguishing it from siblings like parcela_geojson_por_rc (GeoJSON) and exportar_parcela_gml_y_geojson.

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 a 'Uso' section with concrete guidance on how to invoke the tool, including the recommended 'AUTO' mode for CRS detection and important caveats about supported EPSG codes for Canarias vs Península. However, it does not explicitly compare to alternatives or state when not to use this tool, so it's clear context but lacks explicit exclusions.

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 and it discloses AUTO mode behavior: requests 4326, calculates UTM EPSG, and conditionally reprojects if pyproj is available. This adds meaningful behavioral detail beyond a simple 'returns vertices'. It does not cover error handling but that's acceptable for a read-only test tool.

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 clear sections (Uso, En AUTO, Entradas, Salida) and bullet points. Each sentence serves a distinct purpose with no redundancy, making it compact and easy to scan.

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 inputs, conditional behavior, and output structure ('dict con vertices_4326 y/o vertices_utm'). Though an output schema exists, the description explicitly documents the return fields. It's nearly complete for a simple 2-parameter tool, with only minor omissions like error handling.

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%, but the description fully compensates by defining refcat as 'RC' and explaining the srs parameter ('AUTO' or explicit EPSG) along with the AUTO processing logic. This adds semantic meaning that the raw schema lacks.

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 parcel vertices ('Devuelve vértices de la parcela') with a specific verb and resource, distinguishing it from sibling tools that return geojson, gml, or ifc formats. The phrase 'para pruebas rápidas' adds useful context about its intended use.

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 'para pruebas rápidas' gives clear context for when to use this tool (quick tests) without explicitly naming alternatives or exclusions. It doesn't say 'use this instead of X', but the context is understood from the sibling list and the light-touch wording.

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 the output is a JSON dict from a service, implying a network call, and lists the inputs. But it does not mention error handling, rate limits, or side effects beyond the basic conversion, leaving some gaps.

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 perfectly structured with Uso, Entradas, and Salida sections. Every line is informative and there is no redundant text, making it highly concise and easy to scan.

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 a simple conversion with 4 parameters and an output schema. The description covers all inputs and the general output shape, which is sufficient for basic usage. It lacks details on error scenarios, but the output schema presumably covers return structure, making this a minor 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 0%, so the description must compensate. It provides useful info for refcat (lengths 14/18/20) and srs (example EPSG:4326), but provincia and municipio are only marked as 'opcional' without further explanation, offering limited extra meaning.

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 verb 'Convierte' and the resource 'Referencia Catastral' to coordinates, making the purpose unambiguous. However, it does not distinguish this from sibling tools like coordenadas_a_rc, though the direction of conversion is evident from the name.

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 guidance is provided on when to use this tool versus alternatives such as coordenadas_a_rc or dcnp_por_rc. The description only explains the conversion mechanics, not the use cases, 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 for behavioral disclosure. It vaguely mentions resolving includes/imports, but does not explain recursion limits, error handling, or whether this is a read-only operation. The 'max_includes' parameter is not described.

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 short, but this is under-specification rather than conciseness. The 'Uso:' prefix is unnecessary, and the sentence only restates the tool name without adding informative content.

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?

Despite having an output schema, the description provides almost no context about return values, behavior, or use cases. For a tool involving include/import resolution, key details such as default limits, cyclic dependency handling, and typical usage scenarios are absent, so it is not complete enough for an agent to invoke confidently.

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% and the description does not mention any parameters. It does not explain that type_name is required, what version means, or how max_includes controls include/import resolution. The description adds no value beyond the raw 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 'DescribeFeatureType + resolución de includes/imports' is essentially a direct restatement of the tool name, adding no real clarification of what the tool does. It names the WFS operation but does not state that it retrieves the schema definition for a feature type or what the resolved output contains.

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 usage guidance is provided. The description gives no indication of when to use this tool versus siblings like wfs_cp_get_capabilities or wfs_cp_list_feature_types, nor any exclusions or alternatives.

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 of behavioral disclosure, but it offers no details about read-only nature, network dependence, output format, or error behavior. It only says the document is obtained, which is minimal.

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 concise sentence that front-loads the action ('Uso: Obtiene') and the resource. There is no wasted words or unnecessary detail, making it highly focused.

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's simplicity (one optional parameter) and the presence of an output schema, the description is still too sparse. It lacks any operational context, parameter explanations, or usage scenarios, making it minimally viable at best.

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 single 'version' parameter is undocumented in the schema (0% coverage) and completely ignored in the description. There is no explanation of supported values, the meaning of the default, or why a caller might want to change it, so the description does not compensate for the schema gap.

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 operation ('Obtiene' = gets) and the specific resource (GetCapabilities document of the INSPIRE WFS for cadastral parcels). It distinguishes this from sibling tools like wfs_cp_get_feature_sample and wfs_cp_list_feature_types, which serve different WFS operations.

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 guidance is provided about when to use this tool versus alternatives. The description simply restates the function without contextual cues, such as mentioning that GetCapabilities is often a prerequisite for other WFS operations or when to choose it over sibling 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the request is unfiltered but lacks details on default count, type_name, or the read-only nature of the operation.

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, front-loaded sentence with no redundant content. However, it is slightly under-specified, missing parameter context, which prevents a perfect score.

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?

With no annotations and minimal parameter coverage, the description is insufficient for an agent to fully understand the tool's role among many sibling WFS and parcel tools. The output schema exists but does not substitute for usage context.

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%, and the description provides no explanation of the srs, count, or type_name parameters. It only implies filtering behavior without any parameter-specific 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?

The description clearly states the tool performs a WFS GetFeature request without filters to inspect real output. This distinguishes it from sibling WFS tools by focusing on unfiltered sample retrieval.

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 for inspecting raw WFS output but does not explicitly compare with alternatives or state when not to use. No exclusions or references to sibling tools are provided.

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 states the tool lists FeatureTypes and CRS from GetCapabilities but does not disclose whether it performs a network request, requires authentication, or has any side effects. Behavioral traits are largely opaque.

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 brief with no unnecessary words, and the 'Uso:' prefix provides a slight structural cue. However, the prefix is somewhat redundant in a description field, preventing a perfect 5.

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?

With no annotations, an optional parameter, and an output schema that may provide some context, the description still lacks essential context about when to use the tool, what the version parameter does, and operational implications like network access. It is minimally viable but leaves significant gaps.

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%, and the description fails to explain the 'version' parameter. It does not mention the default value (2.0.0) or supported versions, adding no semantic value beyond the parameter name.

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 'Lista' (lists) and identifies the resource: FeatureTypes and supported CRS from GetCapabilities. This clearly distinguishes it from sibling wfs_cp_get_capabilities which retrieves the full capabilities document.

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 'Uso:' label implies usage instructions, but the content merely restates the tool's function without specifying when to use it versus alternatives. No exclusions or scenario-based guidance is provided.

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