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 that the tool is read-only, returns columns, rows, and coverage, and provides instructions to create the store if missing. It also warns that borme.actos is a list requiring list_contains, which is valuable behavioral context.

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 with the main purpose front-loaded, but it includes extraneous details (e.g., exact counts of perfiles, plataformas, menores) that may not help an agent invoke the tool correctly. It could be more concise and better structured.

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 complexity of a SQL query tool with two undocumented parameters, no annotations, and no output schema, the description covers the available tables, views, return format, and store fallback. However, it leaves a significant gap by not explaining the 'limite' parameter or the expected format of 'consulta', which are essential 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 0%, so the description must explain parameters. It implies 'consulta' is a SQL query but never defines it explicitly, and it completely omits the 'limite' parameter (default 100) — leaving the agent without guidance on how to limit results or what the parameter does.

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 (SQL de solo lectura) and resource (almacén local en Parquet) and enumerates the available tables and views. This is clear enough for an agent to understand it runs read-only SQL queries over a local data store, though it doesn't explicitly compare to sibling tools like ckan_buscar or ckan_filas.

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?

Mentions a precondition ('si existe') and a fallback ('sin almacén, cómo crearlo'), which implies when the tool is usable. However, it never states when to choose this tool over alternatives (e.g., for ad-hoc SQL vs. structured lookups), leaving selection guidance implicit.

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 exist, so the description carries the full burden. It discloses the date format, the two bulletin sources, the section-code filter, the title-text filter, and the Sunday/holiday emptiness caveat — useful behavioral context. It is silent on result shape and on the effect of max_items (default 200), which matters for a listing tool with no output schema.

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 dense clauses front-load the operación (which bulletin, which day) before the filter and caveat details. Every sentence carries information; the only omission is the untied max_items, not 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?

For a 5-parameter listing tool with no annotations and no output schema, it covers sources, filters, and the empty-day case well. It leaves an agent guessing about the max_items default behavior and the structure of the returned 'disposiciones', which is a meaningful gap when no output schema exists.

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, and it does for 4 of 5 parameters: it explains fecha's 'AAAA-MM-DD' format, diario's boe/borme values, the valid sección codes (1, 2A, 2B, 3, 4, 5A), and texto's title-matching semantics. Only max_items is left unexplained.

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 names a specific resource ('Disposiciones de un día') and its two possible sources (BOE via diario=boe, BORME via diario=borme), so an agent knows exactly what it retrieves. Siblings are unrelated datasets, so explicit differentiation is unnecessary, but the verb (list/retrieve) is only implied rather than stated.

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 one genuine usage constraint — 'Domingos y festivos no hay boletín' — which tells the agent when a call will return nothing, plus the allowed diario and sección values. However, it never states when to prefer this over alternatives (e.g. a search tool) or what to do for holiday dates.

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 tool performs a cross-source search and returns a light index, but says nothing about result ordering, what the light index contains, how 'limite' behaves, or whether 'sector' scopes results. Those are meaningful gaps for a search 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 two sentences and front-loads the search scope before the return/handoff behavior. It is dense but each clause serves a purpose; the parenthetical about 'resumen, alerts y code' could be trimmed slightly.

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 multi-entity search with three undocumented parameters, no annotations, and no output schema. The description covers purpose and the handoff to ficha(id), but omits parameter semantics and key behavior such as pagination via 'limite' and sector filtering, leaving significant 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 0% for all three parameters (consulta, limite, sector), and the description never mentions any of them or explains their meaning, defaults, or interaction. The description provides no compensation for the undocumented 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 names a specific verb (Busca) and enumerates exactly what is searched across: fichas, recetas, necesidades, productos e identificadores. It also distinguishes itself from the sibling ficha by stating it returns a light index while detail comes from ficha(id).

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 clearly routes the agent: use this tool for discovery across multiple entity types and then call ficha(id) for detail. It does not explicitly compare against ckan_buscar or codigos, so there is room for more explicit 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 burden; it does disclose the shape of returned items (id, format, datastore presence, download URL), which signals a read-only listing. It says nothing about pagination via limite, error behavior for unknown portals, or whether network access to arbitrary portal URLs is permitted.

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, with the return payload listed up front and portal values second. Slightly telegraphic phrasing ('portal: ...') but no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description usefully enumerates the returned fields, which covers the return-value gap. But for a 3-parameter search tool with zero schema coverage, the missing explanation of the required 'texto' and the 'limite' default is a real omission.

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 well on 'portal' by enumerating valid values (substituting for a missing enum) and the /api/3/action URL form, but 'texto' and 'limite' are never explained – texto is required yet its search semantics are undefined.

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?

Names the resource (CKAN portal datasets plus their resources) and enumerates the fields returned, so an agent knows this is a discovery/search call. It does not explicitly contrast with the sibling ckan_filas, which presumably fetches dataset rows, leaving the boundary fuzzy.

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 statement of when to use this versus ckan_filas, descargar, or socrata_filas. The discovery-then-rows workflow is only inferable from the sibling names, not from the description.

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 does disclose two non-obvious traits: the portal silently truncates results, and the response carries a total_datastore field that should be reconciled against the file. It does not cover auth needs, rate limits, or how pagination state is carried between calls.

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 dense sentences with no filler, and the capability plus its key caveat are front-loaded. The final clause is slightly compressed ('compáralo con el fichero') and could be a touch clearer, but nothing 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?

No output schema and no annotations mean the description is the only context, and it covers the return field and the truncation gotcha. However, it claims pagination while the schema exposes only 'limite' with no offset or cursor parameter, leaving the actual paging mechanism unexplained.

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% across four parameters, so the description must compensate. It does well for 'filtros' by giving a concrete equality example ({"Territorio": "Madrid"}) and implies 'limite' via pagination, but leaves 'portal' and 'recurso' (URL vs. id/slug) undefined.

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: read datastore rows of a CKAN resource, with equality filters and pagination. An agent can distinguish this from ckan_buscar (dataset search) and socrata_filas (different portal family) by the 'datastore de un recurso CKAN' phrasing, though no sibling is named 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?

Usage is implied rather than stated: use it when you need filtered rows without the portal's silent cap. The closing instruction ('compáralo con el fichero antes de dar un total') is a useful workflow rule for totals, but there are no explicit exclusions or named alternatives for when a different tool is preferable.

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 disclosure burden. It usefully explains the dual-mode behavior (no group returns the group list; with group returns that group's entries), which is real behavioral context. It does not state that this is a static read-only lookup, whether results are cached or exhaustive, or anything about permissions, leaving gaps for an annotation-free 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?

Two dense sentences with the purpose front-loaded and the parameter behavior following. Every clause carries information; the parenthetical example list is long but earns its place by supplying the missing enum values.

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 single-optional-parameter lookup with no output schema and no annotations, the description covers both invocation modes and the shape of the return (group list vs. entries). Minor gap: it does not describe what an individual entry contains (code plus label?), which matters since there is no output schema.

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, and it does: it explains exactly what omitting 'grupo' yields versus supplying it. The parenthetical list (tv, DataComex, AEMET, carburantes, BOE) effectively supplies example group values that the schema lacks. It does not enumerate exact accepted group identifiers, so not a 5.

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 identifies a specific resource (API lookup codes) and grounds it with concrete examples (INE tv id, DataComex countries, AEMET stations, fuel products, BOE ranges), so an agent understands it is a reference/enumeration tool. The verb is nominal/implicit rather than a stated action, and no sibling tool is named as a contrast, so it stops short of a 5.

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 implied by the framing ('codes an API requires and you can't guess'), which tells the agent to reach for this before calling code-dependent tools. However, there is no explicit when-to-use/when-not, no mention of alternatives among the many siblings (ckan_buscar, boe_sumario, tabla_pcaxis), and no stated 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?

No annotations are provided, so the description carries the full burden. It does disclose return content (period, series, source, and whether the IPC figure is an advance/flash estimate), which is genuinely useful. It does not state data freshness, units, caching, or what happens if a series is unavailable — notable gaps for a no-annotation tool, but the read-only nature is implicit and the payload description is above average.

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 sentence, front-loaded with the core purpose ("Último dato de coyuntura de España") before the indicator enumeration. The list of indicators is long but each item earns its place by telling the agent exactly what data will come back; 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?

With no annotations, no output schema, and no parameters, the description is the only source of truth. It covers which indicators and which metadata fields come back, but omits units, reference-period conventions, data source authority, and failure behavior — details an agent would want before relying on the numbers.

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 takes zero parameters, so there are no semantics to document and the baseline of 4 applies. The description instead spends its words on the returned content, which is the right allocation for a zero-arg tool.

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 ("Último dato de coyuntura de España") and enumerates exactly which indicators are covered: IPC with advance flag, EPA unemployment, corrected GDP, registered unemployment, Euribor, dollar, PDE debt, 10-year bond, risk premium. The macro-economic domain is clearly distinct from the sibling tools (empresa_nif, perfil_municipio, ckan_buscar, boe_sumario), though no sibling is named 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?

"Último dato" implicitly scopes usage to the latest snapshot rather than historical series, which is a useful usage signal. However, there is no explicit when-to-use, no prerequisites, and no routing to alternatives (e.g., almacen_sql for custom queries). Usage must be inferred from the domain.

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 it well: it discloses the 25 MB cap, retry/gzip/encoding handling, WAF-block reporting, that alerts from the host's ficha are appended, and that a substitute is offered for dead URLs — all behavior an agent could not infer. Gaps remain on authentication requirements and whether repeated calls are cached or counted against any quota.

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 core action is front-loaded in the opening clause and the second sentence adds the use case without restating anything. The first sentence is very densely packed with clauses, which slightly slows parsing but each clause contributes distinct information.

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?

Behavior is rich enough to call the tool safely, but with no output schema and 0% schema description coverage, the description should explain what the returned summary looks like and what desde/max_caracteres control. As written, an agent can invoke it but not tune it.

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 explain all three parameters. It only implicitly suggests truncation via "la resume", and the parameters desde and max_caracteres (offset and truncation length) are never mentioned or explained, leaving their semantics and units entirely undocumented.

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 ("Descarga una URL pública") and immediately qualifies it with the machinery it handles: FNMT certificates, User-Agent, retries, gzip, encoding, and a summary in CSV/JSON/xlsx/ZIP. This is clearly distinct from siblings like buscar, ficha, ckan_buscar, which search or look up metadata rather than fetch a raw URL.

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?

"Para cuando tu fetch falle con un .gob.es o para ver qué devuelve una URL" gives a concrete triggering condition, which is exactly the kind of routing signal an agent needs. It stops short of naming siblings to prefer instead or stating when-not to use it (e.g., for JSON APIs already covered by ckan_filas or socrata_filas).

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 disclose meaningful behavior: name-mode returns ranked candidates and explicitly excludes natural persons ('sin personas físicas'), exact matches return the profile directly, and batch is capped at 10. It is implicitly read-only but never states response shape, empty-result behavior, or the meaning/default of max_filas.

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?

Every clause carries substantive information, but the whole definition is a single run-on paragraph chained with semicolons, making it hard to parse quickly. Front-loading is good, yet the three usage modes would scan far better as separated sentences or bullets.

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 output schema, the description does the heavy lifting by enumerating the returned data categories, and it explains input modes. The main gap is the max_filas parameter and any note on result volume/pagination, but overall it is sufficient for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It thoroughly explains the nif parameter's three accepted forms (single NIF, name, list up to 10), but says nothing about max_filas, which has a default of 5 and is undocumented in both schema and description.

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 precisely enumerates the resource (empresa/entidad) and the exact data domains it returns: sector público/DIR3, subvenciones, ayudas de Estado, minimis (BDNS), ayudas AEI, prohibiciones de contratar, contratos adjudicados and actos del BORME. It also states lookup modes (NIF, name, list). It does not explicitly differentiate itself from siblings like buscar or ficha, relying on the domain specificity of 'por NIF' instead.

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 mode-selection guidance is given: pass a NIF for full entity data, a name when you only have a name (candidates with their NIFs), and a list of up to 10 for batch. What's missing is when NOT to use it or which sibling to pick for adjacent lookups, but the conditional usage within the tool is clear.

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 exist, so the description carries the full burden; it does disclose the returned content per id type (endpoints with example and response, sync, gotchas, steps, freshness, license, regex, cross-references) and the near-miss fallback on missing ids. That is meaningful output-content disclosure, but it never states read-only behaviour, whether any lookup is rate-limited or cached, or what the near-match response looks like structurally.

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 dense run-on sentence with deeply nested parenthetical lists, so the core fact (returns detail for an id from buscar) is buried and the fallback behaviour is tacked on the end. Compact, but under-structured rather than 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?

For a simple one-parameter read lookup with no output schema, the description does cover the broad shape of returned data and the missing-id case, which is close to sufficient. It falls short on id formatting and on distinguishing this from the many topic-specific siblings, which an agent would need before choosing it.

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% for the single required 'id' parameter, so the description must compensate. It does add real semantics by enumerating the four kinds of ids accepted (source, recipe, product, identifier), implying the id is polymorphic and resolved by prefix/type; however it gives no format, syntax, or example values, leaving the agent to guess.

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 it returns detail for any 'id' produced by the sibling tool 'buscar', which does differentiate it from a plain search. However, the phrasing ('Detalle de cualquier id de buscar') is dense jargon and the enumerated categories (fuente, receta, producto, identificador) are opaque without domain knowledge, so an agent must infer what 'detail' actually means.

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 id is described as coming from 'buscar', suggesting this is a follow-up lookup tool. The fallback behaviour ('Si no existe, ids parecidos') is a useful hint, but there is no explicit when-to-use versus siblings like 'codigos' or 'empresa_nif', nor any stated 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 and does reasonably well: it discloses coverage caveats (energy certificates only for Cataluña and C. Valenciana), accuracy flags (exacta=false when the matched street differs), proximity radii (under 1 km, three nearest facilities), and the 20-item batch limit. It omits failure behavior, missing-data handling and any auth/rate context.

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?

There is little filler, but the whole description is one semicolon-chained run-on with the key structural fact (solo_codigos) and the batch limit buried at the end. It is dense rather than front-loaded, which makes it slow to parse for an agent.

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 output schema and only two parameters, the description does the heavy lifting on return contents and conditional fields (location, parcel info, nearby facilities). What it lacks is any statement about behavior when data is unavailable for a municipality or when a lookup fails.

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 entirely, and it does: 'municipio' is documented as accepting a bare name, INE/SIGPAC/DIR3/NIF codes, an address string, or 'lat,lon', plus an array of up to 20, and solo_codigos is explained as returning only codes and location. Both parameters gain meaning well beyond their 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 names the resource (a municipality, by name/code/address/coords) and enumerates exactly what comes back: cross-system codes, padrón, income, unemployment, crime, tourist housing, home sales and appraised value. That makes the purpose concrete without opening the schema. It never distinguishes itself from the sibling 'codigos', which likely overlaps on the code-lookup portion.

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?

Accepted input forms (name, INE, SIGPAC, DIR3, NIF, address, 'lat,lon', or up to 20 in one call) and the solo_codigos shortcut imply when the tool is a fit, and the note about addresses/coordinates unlocking location and nearby POIs hints at scope. But there is no explicit when-to-use / when-not guidance and no mention of the alternative 'codigos' 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?

With no annotations, the description carries the full behavioral burden. It adds two useful facts (values come back already type-converted, field names must be ASCII-stripped), but says nothing about read-only semantics, the default 100-row cap, pagination behavior, rate limits, or what the response looks like for a tool that clearly has a truncated default result set.

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 clauses, front-loaded with the resource and portal, with no filler. The parenthetical id and the ASCII note are dense but each carries information; the phrasing is somewhat telegraphic and the SoQL hint is buried at the end rather than attached to the parameters it governs.

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?

A five-parameter query tool with no annotations, no output schema, and no parameter descriptions needs the description to explain both the query model (SoQL clauses, result limits) and the return shape. It covers the dataset id format and one data-formatting quirk but leaves the default limit, pagination, and response structure entirely unaddressed.

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 all five parameters rely on the description. It documents the required 'conjunto' via the id example and gives a field-naming convention relevant to select/where/order, and mentions SoQL, which implies the clause style. However, it never explains that where/select/order are raw SoQL strings, nor what 'limite' means or that it defaults to 100, leaving most parameters underspecified.

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: retrieve the rows of a Socrata dataset from analisi.transparenciacatalunya.cat, with a concrete id example (gn9e-3qhr). It is clear what the tool does, but it never names or contrasts with the sibling ckan_filas, which fetches rows from a different portal, so an agent must infer which one to pick.

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 statement of when to use this tool versus ckan_filas or almacen_sql, and no prerequisites, pagination advice, or coverage caveats (e.g., that only the Socrata-hosted Generalitat datasets work here). The portal name hints at the applicable domain but leaves the routing decision to inference.

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 does useful work by disclosing that values are pre-converted and that None means unavailable/secret data rather than zero — a real correctness trap avoided. It says nothing about truncation at max_filas, rate limits, or failure behavior when the table id/URL is invalid, which matters for a network fetch 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?

Compact with no filler, but the second clause is a run-on enumeration ('id de tabla del INE (24077), URL Tabla.htm del INE, Interior, Educación o Cultura, o URL del fichero') where the 'Interior, Educación o Cultura' fragment is ambiguous rather than clearly listing accepted input forms.

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 fetch tool with no output schema and three undocumented schema params, the description covers input forms, filter behavior and the None convention but leaves output shape (columns returned) and truncation behavior unaddressed, so it is adequate but incomplete.

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 explain tabla (INE id, Tabla.htm URL, or file URL) and filtro (substring match across any field, with code/name/period examples), but max_filas — whose default of 200 implies silent truncation — is never mentioned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and outcome: a PC-Axis table returned as rows with numbers already converted, plus the None semantics. It does not distinguish itself from siblings like ckan_filas, socrata_filas or descargar, so an agent cannot tell from the description alone which row-fetching tool to pick.

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?

Implicitly scoped to INE PC-Axis tables via the accepted inputs (INE table id, Tabla.htm URL, file URL), which implies 'use this for INE statistical tables'. There is no explicit when-to-use versus ckan_filas/socrata_filas/descargar, and no when-not guidance.

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