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

Annotations already declare it read-only, non-destructive, open-world. The description adds genuine behavioral context beyond them: it only samples up to 500 rows per file and is explicitly a heuristic, so the agent knows the result is approximate and bounded. That is exactly the kind of caveat annotations do not carry.

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 tight sentences with zero filler. The core purpose and the cumulative-vs-incremental distinction are front-loaded, and the heuristic/row-limit caveat follows immediately.

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 still conveys the decision it returns (cumulative vs incremental) and the format switch is documented in the schema. It is nearly complete, missing only how the conclusion is expressed in the text/json output.

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

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

Schema description coverage is 100%, so every parameter (source portal, format, dataset_id, resource_id_new/old with auto-detection) is already documented in the schema. The description adds only the notion that the two newest files are used, which is baseline-level value when the schema does the heavy lifting.

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+resource: determining whether a dataset's periodic files are cumulative or incremental. It even names the mechanism (comparing period values in the two newest files), so an agent can distinguish it from list_dataset_resources or investigate_dataset without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when the result matters (choosing whether the newest file suffices or all files must be combined), but never states when to call this tool versus siblings like list_dataset_resources or investigate_dataset, nor any prerequisites or exclusions. Usage must be inferred from the purpose.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: it accepts ANDA's research-use terms, and it returns links to multi-MB ZIPs rather than the data itself, warning about payload size.

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 tight sentences with zero waste, front-loading the return type and following with the prerequisite and size warning. Every clause carries information an agent needs.

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

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

No output schema exists, so the description usefully discloses the return shape (links to ZIPs) and the research-use terms constraint. It is essentially complete for a two-parameter link tool, though it could say more about how to consume the links.

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

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

Schema description coverage is 100%, so both idno and format are already documented in the schema; baseline is 3. The description implies the idno comes from an ANDA survey but adds no syntax or format detail beyond the schema.

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

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

States the resource (an ANDA survey's microdata files) and the outcome (direct links, multi-MB ZIPs), and implicitly distinguishes from the metadata sibling get_anda_survey_info. The action verb is somewhat implicit ('direct links to') rather than an explicit 'download', so it lands just 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?

Explicitly routes the agent through a prerequisite: 'Check get_anda_survey_info first', which is actionable sequencing with a named sibling. It lacks explicit exclusions (when NOT to use vs download_resource), so it stops short of 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?

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so safety is covered. The description adds genuinely new behavioral facts: output is base64-encoded, hard 5 MB ceiling, and that format='text' only confirms the download rather than returning data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short clauses, front-loaded with what the tool returns, then the size limit, then the format directive. No filler; every sentence carries 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?

With no output schema, the description carries the return-value burden and does explain the payload (base64 raw bytes) and the size cap. It doesn't describe the shape of the json structured result, a minor remaining 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 coverage is 100%, so the baseline is 3. The description still adds meaning: it tells the agent that format='json' is required to actually receive the data and that 'text' is only an acknowledgement, which the schema's terse enum description does not convey.

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+resource ('Raw bytes of a CKAN resource') and the delivery format (base64-encoded). It also implicitly distinguishes itself from the preview path by scoping to 'formats the preview can't parse', so an agent can separate it from preview_resource_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?

Gives clear context for use ('for formats the preview can't parse') and a directive on the format param. It doesn't name the alternative sibling (preview_resource_data) explicitly, so it stops short of full when/when-not routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds scope value by stating that the full AD 2 sheet is returned, but does not address the format parameter's effect, latency, or any source/freshness caveat for the published AIP data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that names the resource first and then enumerates returned sections. No filler, no repetition of the title, no restatement of schema fields.

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 read-only single-record lookup with fully documented parameters and annotations covering safety, the description is close to sufficient. It stops short only on routing (which list tool to use first) and on the fact that the response shape is governed by the format parameter, but no output schema exists that would carry that detail.

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

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

Schema description coverage is 100% and both parameters are well documented in the schema itself (ICAO code with real examples, format enum with default). The description adds no meaning beyond that, so the baseline 3 is appropriate.

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

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

States a specific resource, 'full published AIP AD 2 data sheet for one aerodrome', keyed by ICAO code, and enumerates the sections returned (coordinates, runways, hours, services, frequencies, procedures). The singular 'one aerodrome' distinguishes it implicitly from a list operation, but it never names the sibling list_aip_aerodromos, so an agent must infer the distinction.

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: 'one aerodrome (ICAO code)' signals a single-record detail lookup versus a browsing/list tool, but there is no explicit when-to-use statement, no prerequisite (e.g. resolving the ICAO code first), and no named alternative such as list_aip_aerodromos.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the content shape of the metadata (variables, microdata availability, access terms), which is useful, but discloses nothing extra about auth needs, rate limits, or edge 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?

A single efficient sentence with the resource identifier front-loaded and the returned facets listed after. Nothing is wasted, though the parenthetical is slightly compressed.

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 carries the burden of telling the agent what comes back, and it does so by enumerating scope, variables, microdata availability and access terms. Annotations cover safety, so the remaining omission — return format details for text vs json — is minor.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the enum for 'format'. The description only restates that idno comes from search_anda and adds no syntax or format guidance beyond the schema — the baseline 3 for full coverage is appropriate.

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

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

Names a specific verb+resource ('Full metadata for one ANDA survey') and enumerates the returned facets (scope, variables, microdata availability, access terms). The search-then-detail relationship to search_anda is implied rather than stated as an explicit contrast, so it falls just 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?

The parenthetical 'string idno from search_anda' establishes the prerequisite workflow: the agent must first call search_anda to obtain an idno. It gives clear context for when this tool applies but offers no explicit when-not guidance or alternative siblings.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld). The description usefully adds return semantics — 'returns links, not file contents' — and a size constraint on the alternative preview/download path, which is behavioral context the annotations don't provide.

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 tight sentences with the scope and return semantics front-loaded and no wasted words. Every clause carries 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?

With no output schema, the description compensates by naming the return fields (title, URL, format) and clarifying that links, not contents, are returned. Combined with annotations covering safety, it is largely complete for a three-parameter listing 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 description coverage is 100%, so the schema already documents all three parameters including both enums. The description's mention of title/URL/format refers to outputs rather than inputs and adds little beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource — list the downloadable files (title, URL, format) in one section — and anchors the resource to the sibling tool list_archivo_secciones. An agent can distinguish this from list_archivo_secciones and the download/preview tools without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly positions the tool as the listing step that takes a section id from list_archivo_secciones, and adds a routing rule for the download side ('download large files directly; preview/download tools cap at 5 MB'). It stops short of explicitly stating when not to use it, so it's clear context without full exclusion logic.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds real behavioral value: calls are slow, ~50 rows per page, max_paginas caps the work, and the 'completo' flag reveals truncation. That is genuinely useful operational context beyond the 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?

Two compact sentences with zero filler. The purpose and example lead, then the performance/truncation reality is front-loaded so the agent plans paging before calling.

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 paged, slow statistical-report tool with no output schema, the description supplies the operational facts an agent needs: slowness, rows per page, page cap, and completeness flag. It stops short of describing row shape, but the format parameter and json option make the return sufficiently predictable.

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

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

Schema coverage is 100%, so all six parameters are documented including the mes month-filter caveat and the tipo catalog lookup. The description's mention of max_paginas and completo only restates schema semantics. Baseline 3 is appropriate; little added meaning beyond the schema.

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

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

States a specific verb (run) and resource (one ARCONEL report) with an example report name, so the agent can tell it apart from list_catalogo or generic search siblings. It doesn't explicitly name siblings but the ARCONEL domain and report-row return make its scope clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The example 'Balance Energía' for a year implies the expected call, and the tipo description points to list_catalogo(fuente='arconel') for discovery. But the description itself gives no explicit when-to-use or when-not-to-use guidance relative to list_catalogo or the other statistical 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the returned content (authorization, nationality, contact info) and that both RUC and cédula are accepted, but says nothing about lookup failure behavior or whether the format parameter alters the response.

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 tight sentence with no waste, front-loading the resource and scope before the lookup keys. Nothing redundant or padded.

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 two-parameter read-only lookup with annotations covering the safety profile and a fully documented schema, the description is nearly sufficient, and it usefully names the returned fields despite there being no output schema. Minor gap: no note on what happens when the identifier is not found.

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

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

Schema description coverage is 100% and the format enum is fully documented in the schema, so the baseline is 3. The description's 'by RUC or cédula' merely restates the identificacion parameter and adds no syntax or format detail beyond the schema.

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

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

The description names a specific verb (retrieves) and resource (one external auditor) and enumerates the returned fields (authorization, nationality, contact details) plus the lookup keys (RUC or cédula). The singular 'One' implicitly separates it from the sibling search_auditores, though that sibling is never named, keeping it 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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of the obvious alternative search_auditores. The single-record framing only weakly implies that you come here once you already have an identifier, leaving routing 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?

Annotations already cover the safety profile (readOnly, non-destructive) and open-world scope. The description adds genuinely new context: the data is 'live', output is 'raw ICAO text', and sigmet needs no aerodrome code. It omits auth/permission needs and any rate-limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler; the tool's function, all three modes and the output format are conveyed compactly. The semicolon-joined parentheticals are dense and slightly hurt scanability, but nothing is redundant.

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 3-parameter, no-output-schema tool with annotations covering safety, the description supplies the domain context, mode semantics and output nature an agent needs. Minor gaps: how the json format option differs from 'raw ICAO text', and behavior on an invalid or empty ICAO code.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by tying 'designador' to the metar/notam modes and clarifying that sigmet does not need a code, resolving the conditional applicability of a parameter the schema only presents as an empty default.

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 a specific verb+resource (live aeronautical notices from DGAC/AIS) and enumerates the three products it returns (metar, notam, sigmet) with what each contains. The scope statement for sigmet ('whole FIR, no code needed') vs the ICAO-code scoping for metar/notam makes it clearly distinct from aerodrome-data siblings like get_aip_aerodromo.

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?

Gives clear selection context per mode: metar for latest weather reports, notam for active notices, sigmet for FIR-wide alerts requiring no code. It stops short of naming alternative siblings (e.g. the AIP aerodrome tools) or stating when not to use it.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false), so the bar is lower. The description adds real behavioral context beyond them: for the 'standard layout' you get date-filterable series, otherwise a 'faithful preview' (i.e. filters may not apply). This output-variance disclosure is genuinely useful, though the phrasing is somewhat cryptic.

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 tight sentences, front-loaded with what the tool returns and where the id comes from. Nothing is wasted, though 'a faithful preview otherwise' is compressed to the point of ambiguity.

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 6-param, no-output-schema tool, the description covers what is returned (an XLSX table / text-or-json per the format param), the id source, and the bulletin selector. Pagination (rows) and format handling are left to the schema, which is acceptable given 100% coverage.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description reinforces the provenance of table_id and boletin_numero and the date-filterability of desde/hasta, but adds no syntax or semantics beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('One IEM XLSX table') and ties it to its sibling by naming search_bce_iem as the source of table_id, so an agent can tell it apart from the search tool. It stops short of a fully explicit 'this fetches one table by id' framing, but the pairing is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent must infer that it should call search_bce_iem first to obtain a table_id, and search_bce_iem(historico=true) for a boletin_numero. There is no explicit when-to-use/when-not statement, though the input provenance gives practical 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?

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower, and the description still adds real behavioral context: a hard 366-row cap on results and the fallback rule that ultimos_n governs when no date range is supplied. It doesn't disclose pagination or what happens when both a range and ultimos_n are provided, but the added row cap is a useful operational constraint beyond the 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?

A single dense sentence with the resource, the source of the identifiers, and the retrieval modes all front-loaded; no filler. It is compact enough that nothing could be cut without losing information, though the nested parenthetical slightly crowds the core 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?

For a read-only series fetch with no output schema, the description plus schema are nearly sufficient: the format parameter in the schema covers the text/json return shape, and the description covers scope and the result cap. The only gaps are precedence when both a date range and ultimos_n are given and whether 366 rows truncates silently, which are minor for a read 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 description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it explains the interplay between ultimos_n and the desde/hasta range, and imposes a 366-row ceiling that applies to results regardless of the parameter combination chosen. That is genuine semantic value on top of the fully documented schema.

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

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

States a specific verb and resource: retrieves a single BCE daily/monthly indicator series, with a clear scope ('one' series, capped at 366 rows). It distinguishes itself from list_catalogo by naming it as the source of the required identifiers, but it does not differentiate from the nearby siblings get_indicador_bce or search_indicadores_bce, which an agent could easily confuse with this tool.

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?

Implies usage through the prerequisite 'archivo and codigo from list_catalogo(fuente='bce_diarios')', which tells the agent where the required identifiers come from, and clarifies that ultimos_n applies when no date range is given. However, it offers no explicit statement of when to pick this tool over get_indicador_bce, search_indicadores_bce, or get_serie_internacional, leaving 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the ordering convention ('most recent first') and the catalogo-specific scope of anio, but discloses nothing about rate limits, result truncation behavior, or failure modes.

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, front-loaded with the resource and its return shape before the filtering note. No redundancy or filler; the telegraphic phrasing costs a little readability but not precision.

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 five parameters, no output schema and rich annotations, the description supplies the essential missing piece: what the call returns (title, URL, format) and in what order. The catalog dimension and the format=json option are handled by the schema, so nothing critical is left 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 description coverage is 100%, so every parameter is already documented in the schema, including the anio/catalogo coupling and the max_archivos cap. The description's sentence about anio largely restates the schema, adding no new syntax or semantics. Baseline 3 applies when the schema does the heavy lifting.

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+resource: files of one BCE publication page, and even enumerates the returned fields (title, URL, format) and ordering. It names where pagina_id comes from, which separates it from the other *archivos siblings (e.g. get_inec_publicacion_archivos). It stops short of an explicit contrast with any alternative tool.

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 parenthetical '(pagina_id from search_bce_paginas)' implies the search-then-fetch workflow, which is useful. Beyond that there is no when-to-use/when-not guidance, no mention of when another sibling (e.g. search_bce_indicador or get_bce_iem_table) would be 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the 20-feature ceiling, absence of bbox/filter support, and the fact that geometry is dropped from results, which shapes expectations of the payload.

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 tight sentences with no filler, and the identifying information (what it samples, from where) comes first, with the scoping caveat immediately after.

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 preview tool with fully documented parameters and no output schema, the description supplies output-shape context (attributes only, geometry dropped) and the source of the required layer identifier. Nothing essential is missing, though the text/json format distinction could have been tied to expected output.

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

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

Schema description coverage is 100%, so all four parameters (capa, count, format, fuente) are already documented with formats, defaults, ranges and enums. The description only echoes the 20-item cap and the capa provenance, adding little beyond structured data, so baseline 3 applies.

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

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

States a specific verb and resource: sampling feature attributes from a WFS-enabled layer, with the exact cap (20) named. It also routes the agent to the sibling that produces the required `capa` value (search_capas_geo) and explicitly carves itself away from a spatial query tool.

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 'A preview, not a spatial query' tells the agent when this tool fits and, by negation, when it does not. It also implies the prerequisite source of `capa`. It stops short of naming a concrete alternative tool for the spatial-query case, so it is clear context rather than a full when/when-not/alternative map.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safe-read profile is covered. The description adds only the fact that sample datasets may be included; it says nothing about how many are returned, truncation, or portal-dependent behavior across the four sources.

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 economical sentence with the resource and scope front-loaded and zero filler. It is slightly under-explained rather than over-long, but there is no 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?

With no output schema, the description does signal what comes back ('details and sample datasets'), which is the key return-value hint for a read-only informational tool. It omits how the response varies by the format parameter and by source portal, which would round it out.

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

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

Schema description coverage is 100%, so format, source, category and include_datasets are all documented in the schema, including enum values and defaults. The description's only parameter hint ('name from list_categories') duplicates the schema's own wording, adding no new meaning. Baseline 3 applies.

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

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

States a specific verb (retrieves details + sample datasets) for a specific resource (one CKAN thematic category) and scopes it to a single item, which cleanly distinguishes it from the sibling list_categories, which enumerates them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical '(name from list_categories)' implies the prerequisite that you must first call list_categories to obtain a valid category, but there is no explicit when-to-use guidance, no exclusions, and no routing away from alternatives such as search_datasets for broader dataset discovery.

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

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

Annotations already declare readOnly, openWorld and non-destructive, so the safety profile is covered. The description adds genuine value beyond that: the snapshot is point-in-time and limited to now/yesterday/month/year-to-date, with no historical depth.

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 tightly packed sentences with the resource and scope front-loaded and the limiting condition placed at the end. No filler, every clause carries 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?

With no output schema, the description does indicate what comes back (generation mix and demand figures). A snapshot tool of this complexity is adequately covered, though it could say a bit more about the returned shape.

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

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

Schema description coverage is 100% with both enums documented, so the schema does the heavy lifting. The phrase "now, yesterday, month or year to date" loosely echoes the five tablero values but does not map them explicitly, so no credit above the baseline.

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

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

States a specific resource (CENACE live grid) and content (generation mix and demand), with the time granularities spelled out. It is clearly distinguishable from unrelated siblings, though it does not explicitly differentiate itself from the nearby get_energia_ecuador_snapshot.

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 historical queries" is an explicit when-not condition that bounds the tool's use. It does not, however, name an alternative tool for historical energy data, leaving the agent to search siblings on its own.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: dimension ids are decoded to labels, and country defaults to Ecuador, which shapes what the agent gets back. It omits any note on volume, pagination, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The scoping constraints (one indicator, one country, default Ecuador, decoded labels) are front-loaded, and the dependency instruction follows immediately.

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 exists, and the description partially compensates by describing the shape of the result (decoded dimension labels). With all four parameters documented and the indicator_id dependency stated, an agent has what it needs, though return format and result size remain unspecified.

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

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

Schema description coverage is 100% and every parameter (lang, pais, format, indicator_id) already carries its own description, so the schema does the heavy lifting. The description only echoes the Ecuador default and the indicator_id source, adding no format or syntax detail beyond the schema.

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

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

States a specific resource and scope: observations of ONE CEPALSTAT indicator for ONE country, with dimension ids decoded to labels. This clearly separates it from the plural search_cepalstat_indicadores, though it does not explicitly distinguish itself from the other data-retrieval sibling get_serie_internacional.

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?

Explicitly names the prerequisite source for indicator_id ("Take indicator_id from search_cepalstat_indicadores"), which tells the agent it must search first. It gives no when-not guidance or mention of alternatives for the same data, so it stops just short of a full routing instruction.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the semantic clarification that this is a boolean-style compliance status rather than a data listing, but says nothing about auth requirements, rate limits, or freshness of the compliance data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the core scope stated first and the disambiguation second. Every clause earns its place.

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

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

With no output schema, the description correctly carries the return-value burden by stating it answers 'whether ... is current on IESS contributions.' It is complete for a single-lookup compliance check, though it could note what a non-compliant or unknown identification returns.

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

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

Schema description coverage is 100%, with both params (identificacion, format) fully documented in the schema including the enum. The description reinforces identificacion's dual identity semantics (RUC for employers, cédula for persons) but adds no format or validation detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific check (IESS contribution compliance) over a specific resource (RUC or cédula), and explicitly differentiates itself from the sibling tool get_financials by calling out that it is 'a compliance check, not a headcount.' An agent can distinguish it from the many search_*/get_* siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the condition that selects this tool (verifying contribution compliance) and explicitly routes the agent elsewhere for the adjacent need ('for employees use get_financials' n_empleados'). This is a clear when-to-use plus a named alternative for the most likely confusion.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the field scope and the exclusion of financials, which is genuinely useful routing context, though it says nothing about response size, latency, or failure modes for a bad RUC.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence pairing the source, the key, and the returned fields, closed by a short exclusion. No filler or 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?

With no output schema, the description usefully enumerates the returned attributes and notes the financials gap, which is what an agent needs to decide relevance. It could be slightly more complete by mentioning the text/json output choice, but the schema already carries that.

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

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

Schema description coverage is 100%, so both the 13-digit ruc and the text/json format enum are already documented in the schema. The description only restates that lookup is by RUC and adds no format or syntax detail beyond it, so the baseline 3 applies.

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

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

States a specific verb+resource (registry record for one company by RUC) and enumerates the returned fields (status, incorporation, representative, capital, CIIU, address). The closing 'No financials' and the singular 'one company' implicitly separate it from get_financials and search_companias, so an agent can route without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'for one company by RUC' gives clear context for a single-record lookup versus a bulk search, and 'No financials' acts as an explicit exclusion steering agents to get_financials. It stops short of naming the alternative tools, so it is context rather than a full when-to-use directive.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint). The description adds genuinely new behavioral context: the result is either row-oriented CSV data (one row per approved report) or metadata plus a read_pdf pointer for annual plans, disclosing an unusual dual-return behavior that the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with no filler, front-loading the primary return type before the annual-plan exception. It is dense but earns its words; the dual-mode clause is slightly cryptic but purposeful.

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 carries the burden of explaining returns and does so only briefly. It omits which condition triggers the metadata/read_pdf branch and how the rows preview relates to the full dataset, leaving a meaningful gap for a data-retrieval 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 description coverage is 100% and every parameter (informe_id, rows, format) is documented in the schema itself. The description adds no syntax, format, or constraint detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description names a specific resource ('one Contraloría audit-reports CSV') and states what comes back (rows, one per approved report), so the agent knows the subject matter precisely. It does not, however, differentiate itself from adjacent tools such as get_informe_igepn or get_contrato_info, and it lacks an explicit verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit 'use this when' guidance or exclusion against alternatives. Usage is only implied by the dual-mode framing (CSV rows vs. annual-plan metadata plus a read_pdf pointer), which hints at a follow-up chaining step but leaves the selection criteria 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds that this returns the *full* record and names the four OCDS blocks, but says nothing about record size, potential latency, or error behavior on an unknown ocid.

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 dense sentence, front-loaded with the resource and scope, with every clause carrying information (scope, id provenance, returned sections). 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 output schema, the description correctly compensates by naming the returned OCDS sections, and annotations carry the safety profile. Only gap is the absence of any note about response size or failure modes for a bad ocid.

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

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

Schema description coverage is 100%, with both ocid (including a concrete example value) and the format enum documented in-schema, so the baseline is 3. The description only adds that ocid originates from search_contratos, marginal value beyond the schema.

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

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

States a specific verb+resource: retrieving the full OCDS record for one SERCOP procurement process, and enumerates the sections returned (buyer, tender, awards, contracts). The parenthetical tying the ocid to search_contratos distinguishes it from the search sibling, though it doesn't explicitly frame itself as the 'detail view' counterpart.

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 '(ocid from search_contratos)' implies the required upstream workflow — search first, then fetch detail. There is no explicit when-not guidance, no note about what to do if the ocid is unknown or invalid, and no named exclusion of 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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is carried structurally. The description adds the distribuidora-dependent output shape (EEQ substation vs Centrosur province/canton/zone), but says nothing about malformed-PDF handling, failure modes, or size/rate constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, front-loaded with the verb and resource; the output fields and the query behavior are packed in without 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?

For a read-only parse tool with full schema coverage and no output schema, the description adequately covers the input provenance and the shape of the returned rows. It would be fully complete with a note on how unresolvable or unparseable PDFs are reported.

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

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

Schema description coverage is 100%, so all four parameters are already documented, including the accent-insensitive `query` matching and both enums. The description only restates that query filters by place and confirms the archivo provenance, adding little beyond the schema.

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

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

States a specific verb and resource ("Parse one power-cut PDF") plus the exact fields it yields (date, time blocks, location, sectors), so it is immediately distinguishable from search_cortes, which only locates files.

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 names the prerequisite sibling and the input it supplies ("archivo from search_cortes"), which establishes the find-then-parse workflow. It does not state explicit exclusions or when not to call it, so it stops short of a full when/when-not routing rule.

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

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the safety profile is covered. The description usefully enumerates the returned metadata fields, which substitutes for the missing output schema, but says nothing about sourcing behavior per portal, errors, or rate limits.

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 zero filler; the payload (returned fields) is front-loaded and the navigation hints follow. Every clause earns its place.

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

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

With no output schema, the description carries the return-value burden and does so by listing the metadata fields returned. Portal selection (source) and output format are handled by the well-documented schema, leaving little an agent still needs; only error/edge behavior is 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 description coverage is 100%: dataset_id, format and source are all documented in the schema, including enum values and defaults. The description only adds the advice on where dataset_id comes from, which is marginal beyond the structured fields, so the baseline 3 applies.

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

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

States a specific verb+resource (metadata for one CKAN dataset) and enumerates the returned fields, so the agent knows exactly what it gets. It also names the adjacent siblings (search_datasets upstream, list_dataset_resources downstream), distinguishing it from the search and resource-listing tools.

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?

Explicitly tells the agent where dataset_id comes from (search_datasets) and what to call next for files (list_dataset_resources), which is strong workflow routing. It does not state when to avoid this tool (e.g., when only a resource-level lookup is needed via get_resource_info), so it stops short of 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?

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), so the description doesn't need to. What it adds beyond them is substantive data-quality context: the source portal is defunct, the data is frozen at a specific date, and coverage is partial (only one rotation survived). That staleness/completeness warning is exactly what an agent needs to avoid treating this as live data.

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: the identifying fact (what the snapshot is and its limits) is front-loaded, followed immediately by the redirect to live alternatives. No filler, every clause carries decision-relevant 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?

For a two-parameter, optional-parameter read-only snapshot tool with no output schema, the description supplies the essentials: source, date, coverage limitation, and alternatives. It doesn't describe the shape of the returned rotation data, which would help an agent interpret results, but the gap is minor given the tool's simplicity.

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

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

Schema description coverage is 100%, so both `query` (accent-insensitive match against canton or sectores) and `format` (text|json, with default) are fully documented in the schema. The description adds no extra syntax, scope, or default guidance, so the baseline 3 applies.

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

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

States precisely what the tool returns: a frozen Wayback Machine copy (dated 2024-04-24) of a specific defunct portal, including its coverage limitation (only EEQ's Pichincha rotation survived). It names the sibling tools it must not be confused with (search_cortes, get_cortes_horarios), so an agent can disambiguate without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to search_cortes and get_cortes_horarios for current schedules, which implicitly confines this tool to historical/snapshot queries. It stops short of stating the positive trigger (e.g., 'use this when you need pre-2024 EEQ Pichincha data'), leaving a small inference gap.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds the 'last five fiscal years' temporal bound and the returned field set, but says nothing about rate limits, data freshness, or behavior when a year filter yields no data.

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 efficient sentences with no filler, and the resource/scope is front-loaded ahead of the input note. It is terse to the point of omitting the optional anio/format parameters, 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?

With no output schema, the description compensates by naming the returned fields and the five-year window, and annotations cover safety. It is largely complete for a single-company read tool, though it could note the year-filter and format behavior.

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

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

Schema coverage is 100%, so all three parameters are already documented in the schema (including the anio filter and text/json format). The description only restates the identifier input, adding no syntax or format detail beyond the schema; baseline 3 applies.

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

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

The description states a specific resource (one company's Supercías financial history), scope (last five fiscal years), and enumerates the returned fields (revenue, assets, equity, profit, employees, ratios). An agent can tell this is the financial-history tool rather than the general company-info tool (get_compania_info) from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the accepted identifiers ('Takes expediente or RUC'), which hints at usage, but never says when to prefer this over get_compania_info or search_companias, and gives no exclusions or prerequisites. Usage is only implied.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only 'with direct links' regarding the response and the conditional anio requirement; it says nothing about result volume, pagination, or what happens for collections that have no documents in the requested year. Modest value on top of 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?

Two short sentences with zero filler, and the conditional requirement is placed after the core statement. The first sentence is a noun fragment without an explicit verb ('Lists…'), which is a minor structural weakness but costs no comprehension.

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 list tool with 100% schema coverage, annotations, and no output schema, the definition covers the key call conditions, including the one non-obvious required parameter. Missing pagination/result-size behavior is the main gap, but 'direct links' does signal what the agent will get back.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds a real constraint the schema does not express: the schema marks only 'coleccion' as required and gives 'anio' a null default, whereas the description discloses that anio is effectively mandatory for informes_auditoria. That is meaningful semantics beyond the structured fields, lifting it above baseline.

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

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

Identifies the resource precisely — documents (archivos) belonging to an IESS collection — and hints at the return form with 'direct links'. It does not, however, distinguish itself from the many parallel archive-listing siblings (get_inec_publicacion_archivos, get_bce_pagina_archivos, get_sgr_sitrep_archivos), so an agent must rely on the 'IESS' qualifier alone to pick it. Clear verb+resource, no sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The line 'anio is required for informes_auditoria' is a genuine conditional usage rule that steers the agent for one enum value. Beyond that there is no statement of when to prefer this tool over the other archive/report tools, nor what to do when the requested collection is unknown. Implied usage only.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds no behavioral context beyond that, such as response format for the text default or any limits, so a baseline 3 is appropriate for a read-only query 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?

A single sentence with zero waste; the resource and its disambiguating id source are front-loaded before the optional filters.

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, single-required-parameter query tool with full schema coverage and no output schema, the description supplies what an agent needs to call it. Only the absence of any hint about return shape or noting it as one of several BCE series tools keeps it from a 5.

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

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

Schema description coverage is 100%, so all six parameters (including YYYY-MM ranges, frecuencia enum and unidad) are already documented. The description reinforces the optional range/frequency/unit framing and the id_grupo provenance, adding light value on top of the schema but nothing the 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?

States a specific verb+resource ('Time series of one BCEData group') and ties id_grupo back to its source tool, search_indicadores_bce, which helps separate it from the many other retrieval siblings. It does not explicitly name what it is not (e.g. get_bce_indicador_diario or get_bce_iem_table), so differentiation 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?

The description implies usage by noting id_grupo comes from search_indicadores_bce, which is genuine routing guidance for the required parameter. However it gives no explicit when-to-use vs when-not, and no mention of the adjacent daily/IEM tools that could otherwise be confused with it.

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

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

Annotations already declare read-only, non-destructive, open-world behavior, so the safety profile is clear. The description adds that the output consists of file links (bulletins, methodology, historical series), but does not cover rate limits, auth, or return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, front-loaded sentence with no filler. It delivers purpose, scope, and source in one clause.

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 three-parameter read-only tool with no output schema, the description covers what is returned and where the required URL comes from. It omits return format details and the optional year/format filters, but those are handled by the schema and annotations.

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

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

Schema description coverage is 100%, so url, year, and format are fully documented in the schema. The description only implies the url source and does not add semantic detail beyond the schema; baseline 3 applies.

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

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

States the resource ('File links') and scope ('one INEC topic page'), with examples of file types. It ties the tool to search_inec_estadisticas, distinguishing it from that search tool, but does not explicitly differentiate from the similar get_inec_publicacion_archivos sibling.

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?

Clearly directs the agent to use a topic URL from search_inec_estadisticas, establishing the intended workflow. It gives no exclusions or alternative tools, but the source dependency is 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description adds that the output is file links restricted to one publication, but omits any pagination, rate-limit, or empty-result behavior. Given annotation coverage, a 3 is appropriate.

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 tightly-worded sentence that front-loads what is returned (file links) and their types. No filler.

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

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

For a simple two-parameter read tool with no output schema, the description conveys the input source (search_inec_publicaciones) and the nature of the result (file links with formats). It is adequate, though it could better disambiguate from get_inec_estadistica_files.

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

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

Schema description coverage is 100% and the schema already documents both 'post' (id or URL) and 'format' (text/json enum with default). The description only echoes the 'id or URL' notion and adds no format or syntax detail beyond the schema, so the baseline 3 holds.

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+resource: retrieving file links (PDF/XLSX/CSV/ZIP) within a single INEC publication. It names the parent search tool, but does not differentiate itself from the very similar sibling get_inec_estadistica_files, so an agent could confuse the two.

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 parenthetical '(id or URL from search_inec_publicaciones)' implies the workflow of searching first to obtain the post id/URL, giving implicit usage context. There is no explicit statement of when to prefer this tool over siblings or when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real operational context beyond them: a per-call page cap (max 20) and the fact that identification keys must match the search call. It says nothing about auth or error behavior, keeping it at 4.

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 identification mechanism front-loaded and the page constraint trailing. No filler, no restatement of the title, every clause carries 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?

For a no-output-schema retrieval tool, the description covers identification, pagination limits and the format toggle that governs the return shape. It does not describe what a caller gets when a nombre matches nothing or how large extractions are chunked beyond the page cap, leaving a small 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 coverage is 100%, so the baseline is 3 and the schema already documents all six parameters. The description adds the 'max 20 pages/call' constraint, which the schema's pages field does not state, and frames nombre/grupo/anio as reused search keys. That extra constraint earns one step above baseline.

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

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

States a specific verb pair (download and extract text) plus a precisely scoped resource (one IG-EPN report), and names the sibling it depends on (search_informes_igepn). An agent can distinguish it from the search sibling without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description establishes a clear discovery-then-retrieval workflow: the report comes 'from search_informes_igepn' and is re-located by the exact values used there, with volcan needed only when names repeat. It lacks an explicit exclusion or 'do not use for X' clause, so it stops short of a full 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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds the returned field set but says nothing about errors, missing institutions, or auth needs, so it contributes only modest 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?

Two compact clauses: the return content is front-loaded, followed by ID sourcing and the related-tool route. No filler, no repetition of the title, and every clause earns its place.

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

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

For a simple read-only lookup, the definition supplies the ID source, the returned fields, and the sibling for procedures. With annotations covering safety and no output schema to explain, nothing essential is missing, though the lack of an explicit verb keeps it slightly shy of fully self-contained.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by supplying concrete ID mappings (SRI=8, IESS=163, Registro Civil=23) that the schema only shows as 'e.g. "8"'. This meaningfully helps the agent populate institucion_id correctly.

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 the specific resource (one gob.ec institution) and enumerates the returned fields (acronym, sector, description, websites), which makes it clearly distinct from the plural list_instituciones sibling. The retrieval verb is only implied by the noun phrase rather than stated, but an agent can still tell what the tool returns without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly routes the agent: take institucion_id from list_instituciones, and use search_tramites for procedures. That names the source and the alternative for related data. It stops short of stating when NOT to use this tool, but the context 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?

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so safety is covered. The description adds real behavior: it discloses that this is a browse-style bulk listing, that 'query' filters dataset titles rather than doing a topic search, and that output can be a text summary or structured json. It stops short of describing pagination or result-size limits, which keeps it out of the top band.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what the tool returns before the routing instructions. Every clause carries information: scope, sourcing of the slug, the query's filtering target, and the sibling alternative.

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 no annotation for return shape, so the description must carry that burden; it does so adequately by naming the payload (organization plus its datasets) and the two output formats. It is slightly thin on what fields come back per dataset and whether results are truncated, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100% and every parameter already carries a description with defaults and enum values, so the baseline is 3. The description reinforces the slug format and the title-filtering behavior of 'query' but adds no syntax, format, or constraint detail beyond the schema.

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

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

The description states a specific verb+resource ('One CKAN organization and its datasets') and frames it functionally ('the way to browse a large publisher'). It explicitly separates itself from the two adjacent siblings, search_organizations and search_datasets, so an agent can pick correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit prerequisite/ordering rule ('Take the slug from search_organizations') and an explicit alternative with the condition that selects it ('To search by topic across publishers use search_datasets'). Usage is fully resolved, including how to obtain the required parameter.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety and network profile is covered structurally. The description adds the downstream workflow hint (read_pdf), but says nothing about error handling, whether the PDF link may be absent, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler; the resource and its fields come first, followed by the ID source and the follow-up tool. Every clause earns its place.

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

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

There is no output schema, and the description compensates by listing the returned fields. With annotations covering the safety profile and the schema covering both parameters, the definition is essentially complete, missing only edge-case behavior for a nonexistent ID.

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

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

Schema description coverage is 100%, so both parameters are already documented (regulacion_id with an example, format with its enum and default). The description only adds the provenance of the ID value ('from search_regulaciones') and says nothing about the format parameter.

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 the resource (a single gob.ec regulation) and enumerates the returned fields (type, Registro Oficial reference, description, PDF link), which clearly separates it from the sibling search_regulaciones. It lacks an explicit verb such as 'retrieve/fetch detail', but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit call sequence: obtain regulacion_id from search_regulaciones and then use read_pdf to read the PDF text. That routes the agent to the correct sibling tools, though it does not state any when-not-to-use condition or failure cases.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds the returned metadata fields, but says nothing about portal/source behavior, availability, or any per-portal caveats despite openWorldHint implying external calls. Adequate but not rich beyond the 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?

Two short sentences with no filler; the payload description comes first and the routing/next-step guidance follows. Every clause earns its place.

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

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

With no output schema, the description usefully enumerates the returned metadata fields, which is the right compensation, and it names the downstream tools for content retrieval. It stops short of covering multi-portal behavior or any error/not-found case, but nothing critical for calling the tool correctly is missing.

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

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

Schema description coverage is 100%, so format, source and resource_id are already documented with enums and defaults; the baseline is 3. The description adds provenance for resource_id (comes from list_dataset_resources) but does not explain the meaning of the source portal switch or the text/json format choice beyond the schema text.

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 ('Metadata for one CKAN resource (file)') and enumerates the exact fields returned: format, size, MIME type, download URL and parent dataset. It also separates itself from the content-oriented siblings (preview_resource_data / query_resource_data), so an agent can pick it without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent where resource_id comes from (list_dataset_resources) and names the alternatives to use when the contents rather than the metadata are wanted. This is a full when-to-use plus when-not-to-use routing statement.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds real behavior beyond that: the dual mode where an empty indicador/flow triggers a catalog listing rather than a data fetch, plus per-source semantics (xm is cross-border power flows, comtrade is bilateral trade). It omits any note on auth, rate limits, or result size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the core purpose front-loaded before the source mapping. The second sentence is dense and slightly ambiguous ('Without indicador/flow'), which keeps it just under a 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?

For a 20-parameter, no-output-schema dispatcher this is adequate but thin. It explains source selection and catalog discovery, yet says nothing about the shape of returned data (text summary vs json is only in the schema) or which parameter combinations are valid per source, which is the main risk area for a multi-source 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 description coverage is 100%, so the baseline is 3, but the description earns extra by decoding the `fuente` enum values and explaining the indicador/query interaction that the schema alone leaves implicit. It does not clarify how the source-specific parameters (clave, sentido, tecnologia, etc.) combine when several are supplied.

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+resource (retrieve international series for Ecuador) and enumerates the eight `fuente` sources with a short gloss for each (wdi=World Bank, irena=electricity, xm=Colombia-Ecuador power flows, comtrade=UN bilateral trade, etc.). That is far more specific than the tool name alone. It does not, however, position itself against nearby siblings such as get_cepalstat_indicador or search_indicadores_bce, so it stays 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?

It gives one genuine workflow hint: with an empty indicador/flow, wdi/who/imf/ilo return their catalog, and `query` is the search text. That is useful implied usage. It never states when to pick this tool over the BCE or CEPALSTAT alternatives, and there are no exclusions or prerequisites, so guidance remains partial.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so safety is covered. The description adds genuinely new behavioral context beyond the structured fields: the tool returns link references rather than document contents, which sets expectations about the response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, with the scope and return-type qualifier front-loaded. Every clause earns its place.

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

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

For a simple read-only link extractor with no output schema, the description covers what is returned and what is not. It does not mention the text/json format toggle, though the schema documents that parameter adequately.

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

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

Schema coverage is 100%, and the schema already documents both parameters, including that evento_url must come from search_sgr_sitreps and reside on gestionderiesgos.gob.ec. The description restates the source of evento_url, adding little beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('SITREP PDF links... for one SGR event page') and scopes it (national, provincial, cantonal). It explicitly distinguishes itself from the sibling search_sgr_sitreps by stating the URL comes from that tool, and 'Returns links, not contents' separates it from read_pdf.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the prerequisite source for the required argument ('from search_sgr_sitreps'), which is a clear when-to-use signal, and 'Returns links, not contents' implicitly routes the agent to read_pdf for actual content. No explicit when-not or exclusion is spelled out, keeping it just under 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?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description usefully adds that the return is a set of monthly PDF *links* (not embedded data) and that coverage starts in 2018, which is genuine context beyond the annotations, but it says nothing about pagination or whether a download step follows.

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 tight sentence with the resource and scope front-loaded; zero filler. It is arguably too terse for the amount of behavior an agent must infer, but as pure structure it is 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 link-listing tool with no output schema, the description conveys what is returned and the year floor, which covers the essentials. It stops short of explaining how the linked PDFs are subsequently retrieved (e.g. via a download sibling) or the response shape, leaving the hub-and-spoke flow implicit.

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

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

Schema coverage is 100%, so both parameters are already documented, making 3 the baseline. The description adds one meaningful constraint not in the schema ('2018 onward' bounds on 'anio'), but does not elaborate on the format enum's effect.

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 ('SIPA's (MAG) Resumen de Indicadores') and the exact content returned ('Monthly PDF links'), with a scope qualifier ('for one year, 2018 onward'). It is clear enough that an agent can distinguish it from archive-listing siblings, though it never names an alternative directly.

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 reports the 2018-onward coverage boundary but gives no guidance on when to pick this tool versus the many other archive/indicator siblings, and no prerequisites or exclusions. An agent must infer usage purely from the resource name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: it identifies the data as public SRI records and explicitly scopes out tax amounts, telling the agent what will NOT be returned.

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 tight sentences with zero waste. The core resource and identifier format are front-loaded, and the scope caveat is a short, high-value clause.

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 usefully lists the return fields, and annotations plus full schema coverage handle safety and parameters. It is close to complete, though it does not describe output shape or behavior for invalid/missing RUCs.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (ruc, format, include_establecimientos). The description echoes the 13-digit RUC constraint and the establishments field but adds no syntax or formatting detail beyond what is already structured.

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+resource (public SRI record for one 13-digit RUC) and enumerates the fields returned (name, status, type, activity, dates, establishments). The 'one 13-digit RUC' phrasing implicitly differentiates it from search_sri_ruc, but it never names that sibling 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 only implied: the singular 'for one 13-digit RUC' suggests a single-record lookup, and 'No tax amounts' hints at the scope boundary, but there is no explicit when-to-use statement or reference to search_sri_ruc for bulk/multi-record lookups.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds real value beyond annotations by disclosing the shape of the result — columns, measures with the [medida]/[suma]/[promedio] syntax, and date levels — which matters because there is 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?

A single front-loaded sentence with no filler; the return-content detail is packed into parentheticals. Slightly dense but every clause earns its place.

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

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

With no output schema, the description correctly fills the gap by describing the returned field categories and the measure syntax. Annotations cover safety and the schema covers all parameters, so nothing essential is missing.

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

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

Schema description coverage is 100%, and the three parameters (format, fuente, indicador) are fully documented in the schema. The description merely echoes '(fuente)' and adds no syntax or constraint beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific resource (queryable fields of a SUT/Judicatura dashboard) and enumerates what those fields are: columns, measures, and date levels. It also hints at its relationship to query_sut_indicador and list_catalogo, so an agent can place it, though the verb is implicit rather than explicit.

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 'for query_sut_indicador' implies this is a prerequisite/discovery step for that sibling, which is useful context. However, it never states when to call it versus alternatives (e.g. list_catalogo) or any condition, so usage is implied rather than guided.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond them: the data returned (monthly attentions/complaints), the coverage start date (mid-2021), and the single-trámite scope. It stops short of noting rate limits or result-size behavior, so it is not a 5.

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, front-loaded with what the tool returns and its scope, followed by the routing guidance. No filler or restatement of the name/title.

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 exists, yet the description names the returned metrics and their granularity, and the schema's format enum covers the output shape. For a two-parameter read tool with annotations handling safety, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters are documented, making 3 the floor. The description adds value beyond the schema by telling the agent where tramite_id comes from (search_tramites), which the schema's bare example '11752' does not convey.

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+resource (monthly attentions and complaints for one gob.ec trámite), including the temporal scope (since mid-2021) and the one-trámite-at-a-time constraint. It also names the sibling to use for other trámite data, so an agent can distinguish it without opening schemas.

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?

Gives an explicit prerequisite ('Take tramite_id from search_tramites') and routes the agent away from this tool for other needs ('for requirements and cost use get_tramite_info'). The when-to-use and the alternative are both stated, not inferred.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the payload covers requirements, beneficiaries, cost and responsible institution, which is useful, but says nothing about auth, rate limits, caching, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the resource front-loaded and no filler. It is a noun-phrase fragment rather than a full sentence, which is terse to the point of being clipped, 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?

With no output schema, the description compensates well by naming the returned fields, so an agent knows roughly what it will get. It is still light on preconditions and does not address the format parameter's effect, leaving a small 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 100%, so both parameters (tramite_id and format) are already documented, which sets the baseline at 3. The description contributes one genuine extra: the provenance of tramite_id from search_tramites, but it does not touch the format option at all.

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

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

Names the specific resource (a gob.ec trámite) and enumerates exactly what it returns: requirements, beneficiaries, cost, and responsible institution. The parenthetical linking to search_tramites also separates it from siblings like get_tramite_estadisticas, which covers statistics rather than detail.

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 parenthetical '(tramite_id from search_tramites)' implies the required upstream lookup, so usage is inferable, but there is no explicit statement of when to call this versus search_tramites or get_tramite_estadisticas, and no exclusions or prerequisites stated.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: this is a chained operation (search + select + preview) and it silently falls back to the 'first readable resource' rather than failing, which tells the agent the result may come from an indirectly chosen resource.

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 tight sentences with the primary purpose front-loaded and the fallback guidance second. No filler or restatement of the name/title.

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 4-param, no-output-schema tool with annotations covering the safety profile, the description covers what the tool does and when to prefer it. It could say more about behavior when no dataset matches or the preview is empty, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so all four parameters (query, format, source, preview_rows) are already fully documented in the schema, including enum values and defaults. The description adds no syntax, format, or constraint detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific chained behavior: search CKAN, take the top dataset, preview its first readable resource. This is clearly distinguishable from siblings like search_datasets and preview_resource_data, since it explicitly frames itself as the combined shortcut of those 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?

Gives a clear when-to-use (one-step shortcut) and an explicit when-not-to-use condition: 'Use the individual tools when the top hit isn't the right one.' It stops short of naming which sibling tools to fall back on, so the agent must infer the alternatives from the tool list.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral constraint — results are limited to aerodromes with a published AIP AD 2 page — but says nothing about result size, pagination, or completeness of the listing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler: the scope/filter constraint is front-loaded and the follow-up tool is appended as a route hint. Every clause earns its place.

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

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

For a one-parameter, no-output-schema list tool, the description names the returned fields and the inclusion filter, which is most of what an agent needs. A brief note on volume/ordering would close the remaining 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?

Only one optional parameter (format, text/json) and schema description coverage is 100%, so the schema fully documents it. The description adds no format or output-shape detail beyond the schema, which is the expected baseline for a single well-described param.

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 the specific resource (aerodromes/helipads with a published AIP AD 2 page in the DGAC eAIP) and the exact payload returned (ICAO codes and names). It also names the sibling whose scope it differs from, so an agent can separate it from get_aip_aerodromo without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trailing 'Next: get_aip_aerodromo' establishes the intended two-step flow (list here, then fetch details), which is clear context for when to use it. It stops short of explicit exclusions or stating when NOT to call it, so it falls just short of 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds the enumeration of valid sources and the downstream call, but says nothing about result ordering, size, or whether sections are stable identifiers.

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 tight sentences: the purpose first, the next-step routing second. No padding, and the actionable 'Next:' directive is front-loaded in the second clause.

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 read-only two-parameter list tool with full schema coverage and annotations, the description covers purpose, valid inputs, and the follow-up call. What's missing is result-shape detail (count/format specifics), but that is minor for such a simple 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 100% and both parameters (fuente enum, format enum) are fully described in the schema. The description's source list mirrors the fuente enum and adds no new syntax or semantics beyond the schema.

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

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

States a specific verb (list) and resource (sections of one institution's document archive), and enumerates the valid instituciones (ARCSA, Superbancos, etc.). Clearly distinguishable from the sibling get_archivo_seccion, which fetches a single section.

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?

Explicitly names the natural next step: get_archivo_seccion(fuente, seccion). This defines the two-step workflow, though it doesn't name when to skip this and call get_archivo_seccion directly if you already know the section.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds the workflow-ordering relationship, which is useful context, but says nothing about return contents, pagination, or rate limits beyond what the format parameter implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence leads with the core action, then spends the rest on the source-to-tool mapping. Dense and list-heavy but every clause carries routing information; no filler.

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

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

For a read-only, two-parameter list tool with full schema coverage, annotations covering safety, and no output schema, the description supplies the one thing structured fields cannot: how this catalog relates to the get tools it precedes. Nothing critical is missing, though return-shape details are absent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by tying each fuente enum value to its specific downstream tool, which gives an agent a clearer mental model of what each catalog contains than the schema's generic 'Catalog to list; see the list above.'

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

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

States a specific verb and resource ('List one source's catalog') and immediately distinguishes itself from siblings by mapping each fuente value to the exact downstream get tool it precedes (get_arconel_reporte, get_bce_indicador_diario, etc.). An agent can identify the tool's role without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames the tool as 'the step before its get tool' and enumerates which get tool each source feeds into, leaving no inference about when to call this versus the downstream tools. This is a routing guide as much as a 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?

Annotations already declare readOnly=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds that results carry dataset counts and that names feed search_datasets, but says nothing about portal scope behavior, caching, or result completeness across the four sources.

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 dense sentence: what the tool returns first, then how to use the output. No filler, no repetition of the title.

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 exists, so the description usefully discloses the return shape (categories plus dataset counts), which is the key missing piece. What remains thin is the multi-portal 'source' semantics and any sibling differentiation, but the core need is met for a zero-required-parameter list 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 100% and both parameters are fully enumerated, so the schema carries the load. The description adds no meaning about 'source' (which portal variant) or 'format' beyond what the schema already states, making baseline 3 appropriate.

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

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

States the resource precisely — thematic categories of a CKAN portal, with dataset counts — so an agent knows it is an enumeration tool. The verb 'list' is only implied via the name, and it does not distinguish itself from the adjacent get_category_info sibling, which keeps it out of 5 territory.

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 gives a downstream workflow hint ('pass a name as search_datasets' category'), which is genuinely useful routing information. However, it never states when to call this versus get_category_info or list_catalogo, nor any prerequisites, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the shape of the returned listing (format, size, URL, dates) and the fact that periodic-series name groups are flagged, which an agent could not infer from schema or annotations. Pagination/limits for large datasets remain unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler: the listing scope is front-loaded and the follow-up routing is compressed into a single clause. Every phrase carries 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?

There is no output schema, and the description compensates by naming the returned fields and the series-flagging behavior. Minor gaps remain: what a 'periodic series' flag actually looks like in the text vs json output, and whether results are capped or paginated for datasets with many resources.

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

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

Schema description coverage is 100%, with both enums (format, source) and dataset_id fully documented in the schema, so the baseline is 3. The description adds nothing about the 'source' portal switch or the text-vs-json output choice, so it does not exceed the baseline.

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

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

States a specific verb and resource ('Files (resources) in a CKAN dataset') and even enumerates the fields returned (format, size, URL, dates) plus a distinctive derived behavior (flagging name groups that look like periodic series). An agent can distinguish this from get_dataset_info (metadata) and get_resource_info (single resource) without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trailing 'Next: preview_resource_data or query_resource_data' explicitly routes the agent to the follow-up tool once a resource is identified, which is real selection guidance. It stops short of stating when NOT to use this tool (e.g., use get_dataset_info for dataset-level metadata, or detect_series_pattern for the series analysis itself), so no exclusions are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety and openness profile is covered. The description adds only the fact that IDs are returned, which is genuinely useful for chaining, but it says nothing about pagination limits, result caps, or the difference between the text and json 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?

A single front-loaded sentence with no filler; the core resource and the returned identifier are stated immediately. It is efficient, though arguably too sparse to guide invocation on its own.

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 three-parameter, all-optional lookup with no output schema, the combination of the description, the fully documented schema, and clear read-only annotations gives the agent enough to call it correctly. The missing piece is pagination/result-size expectations for the list mode, which is a modest 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 100% and each parameter is documented in the schema itself, including the page/query interaction and the format enum. The description adds no extra semantics, so the baseline 3 for a fully documented schema is correct.

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 pair (list/search) applied to a clearly bounded resource (public institutions registered on gob.ec) and notes the payload includes IDs. It does not name the sibling get_institucion_info, so the agent must infer that this is the discovery step preceding it.

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?

"List or search" implies two modes (browse vs. query), and the schema backs that with 'only used without query', but the description never states when to prefer one mode or when to move on to get_institucion_info after obtaining an ID. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond that: it is a static list, not an alert feed, and it returns codes and coordinates. It does not cover pagination or rate limits, but the added distinction is valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste. The core purpose and scope are front-loaded, and the sibling alternative follows naturally.

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 static list with a fully documented two-parameter schema and no output schema, the description is complete enough: it states what the tool returns (codes and coordinates), what it is not (alerts), and when to use a sibling instead.

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

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

Schema coverage is 100% and both parameters (limit, format) have complete descriptions, so the schema already carries parameter meaning. The description does not add syntax or format details for limit or format, making the baseline 3 appropriate.

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

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

The description states a specific resource (SGR tsunami early-warning SAT stations), its key output fields (codes and coordinates), and explicitly distinguishes itself from alerts. The sibling differentiation is clear: 'For recent seismic events use search_sismos.'

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 explicit when-not guidance ('not alerts') and names the alternative for a different need ('For recent seismic events use search_sismos'). The scope of this tool, a static station list, is stated directly.

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

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

Annotations already declare readOnly/openWorld/non-destructive, but the description adds real behavioral context: it works over HTTP Range requests without downloading the archive, handles archives well beyond 5 MB, and explicitly does not support ZIP64. That limitation disclosure is exactly the kind of trait annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence delivering mechanism, return shape, and the size/ZIP64 caveats with zero filler. Nothing to trim.

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

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

For a 4-param read-only tool with no output schema, the description covers the operation, the return fields, and the key scale/ZIP64 constraints. Pagination behavior (limit/offset) is only covered by the schema, which is acceptable but leaves a small 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 100% and all four parameters are documented there, including the URL provenance hint. The description adds no parameter-level meaning beyond what the schema already carries, so the baseline 3 applies.

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

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

States a specific verb (list), resource (remote ZIP members), and even the mechanism (HTTP Range requests) plus the returned fields (name, size). No sibling tool lists ZIP contents, so it is trivially distinguishable from the rest of the catalog.

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 ('without downloading it', 'works for archives far beyond 5 MB') which helps an agent decide to call it for large remote archives, but it never states when not to use it or names an alternative (e.g. download_resource). Usage is inferable, not 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Description adds that INEC codes, region, and population are returned and that parroquias can be filtered, but does not mention pagination, limits, or exact return shape.

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 tight sentences: first states the resource and fields, second states the filter rule. No redundancy or filler.

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

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

Given six optional params, read-only annotations, and no output schema, the description is sufficient to call correctly. It could say more about default 'auto' behavior or text vs json, but those are already in the 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 100% and every parameter is described there, so the schema carries the detail. The description only reinforces the canton/provincia filters for parroquias; baseline 3 is appropriate.

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

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

States a specific verb (look up) and resource (Ecuador's provinces, cantons, parroquias, INEC codes, region, population). Clearly distinguishable from tax/company/dataset siblings; no other sibling handles political-administrative divisions.

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?

Explicitly says 'For parroquias, filter by canton and/or provincia', giving condition-level guidance. No when-not-use or named alternative, but the niche is clear enough that no other tool competes.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds real behavior beyond them: the 5 MB size ceiling, the accepted file formats, and the fact that ZIP/tar.gz archives containing a CSV are unwrapped and previewed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler. The capability and format list come first, with the limit and routing hint compressed into the trailing clause.

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 still conveys the return shape ('as a table', text vs json via schema). It does not mention pagination, error behavior for oversized files, or which portal index to consult, but the essentials for a correct call are present.

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

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

Schema description coverage is 100%, so rows/format/source/resource_id are all documented in the schema (defaults, max 100, enums). The description adds no per-parameter syntax or format detail beyond the 5 MB cap, so the baseline 3 applies.

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

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

States a specific verb (preview) plus resource (CKAN resource) and even the shape of the result ('as a table'). The supported format list and the explicit hand-off to query_resource_data for DataStore resources separate it from siblings like download_resource and query_resource_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?

Names a concrete alternative and the condition selecting it: 'for DataStore resources prefer query_resource_data'. It does not state when to prefer download_resource or list_dataset_resources instead, so the routing guidance is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered structurally. The description adds that the operation runs through the DataStore server-side (no file download), which is useful behavioral context, but it omits rate limits, auth requirements, and result-size behavior beyond what the schema's rows/filters_json say.

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 tightly-packed sentence that front-loads the core action and scope, then lists the key capabilities. Nothing is wasted and no filler is present.

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 query tool with 8 well-documented parameters, one required field, and annotations covering the safety profile, the description gives an agent enough to select and call it. The return shape is not described, but the format enum (text/json) in the schema partly mitigates that.

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

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

Schema description coverage is 100%, so parameter meaning is already fully documented in the schema. The description names the same capabilities (full-text query, filters_json, sort, pagination) without adding syntax, format, or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Query) and resource (tabular CKAN resource through the DataStore), and the phrase 'without downloading it' implicitly carves it out from siblings like download_resource and preview_resource_data. No sibling is named explicitly, but the resource and scope are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'without downloading it' implies the tool is for inspecting/filtering data rather than retrieving the file, which suggests when to prefer it over download_resource. However, there is no explicit when-to-use/when-not guidance or direct routing to alternatives such as preview_resource_data or list_dataset_resources.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful context with 'Live query' (freshness) and the plain-columns filter restriction, but defers the row cap and truncado=true flag entirely to the schema, so it does not go far beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and then the input-sourcing recipe. No filler, and the most decision-relevant information (what it queries, where inputs come from) leads.

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 should hint at returns; it notes the row limite cap indirectly and the format param (text vs json) is documented, but it does not describe the result shape or the truncado flag. The input workflow is complete, so only the return-side detail is thin.

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

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

Schema description coverage is 100%, so every parameter is already documented, including the value sourcing for indicador and campos. The description restates this workflow guidance rather than adding syntax or format detail the schema lacks; the 100%-coverage baseline of 3 applies.

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

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

States a specific verb (live query) and resource (one SUT or Consejo de la Judicatura dashboard's data model), scoped to a single indicador. It distinguishes itself from siblings by naming list_catalogo and get_sut_indicador_schema as the sources for its inputs, so an agent can place it in the toolchain.

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?

Gives a clear workflow: pull the indicador from list_catalogo(fuente) and valid campos from get_sut_indicador_schema, plus the constraint that filtros work on plain columns only. It stops short of explicit when-not-to-use or an alternative tool for cases outside this data model.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds real context beyond that: a 5 MB / 20-page ceiling and, critically, that there is no OCR so scanned PDFs return empty rather than erroring. This is exactly the kind of silent-failure disclosure an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, fully front-loaded: the action first, then constraints and the failure mode. Not a wasted word; the parenthetical carries real 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?

With no output schema, the description still conveys the return shape indirectly (text summary vs json are in the format enum; "come back empty" implies the text result). Combined with 100% schema coverage, an agent has what it needs to call this correctly, though a hint about the json result structure would complete 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 100% and the schema already documents url, the 1-indexed pages range syntax, and the text/json enum. The description restates only that pages selects a range, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource: "Extract text from a PDF at a direct URL." No sibling tool does PDF text extraction (the rest are search/get/list tools over Ecuadorian datasets), so it is trivially distinguishable. The scope qualifiers (URL, 5 MB, 20 pages) sharpen rather than blur the purpose.

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 conditions by requiring a "direct URL" and capping size/pages, which tells the agent when the call will succeed. However, it never states when to prefer this over alternatives (e.g. preview_resource_data, list_zip_contents for extracting content from other file types). Usage is inferable but not explicit.

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