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

Annotations already declare the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the description's added value is the heuristic caveat and the sampling bound — 'Heuristic over up to 500 rows each' — which tells the agent the answer is approximate and may miss long-range structure. It stops short of saying what happens when fewer than two periodic files exist, which is the main uncertainty left.

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 decision the tool answers, then the mechanism, then the heuristic limit. No filler and nothing buried.

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, an output schema, and full annotation coverage, the description supplies the one thing the structured fields cannot: that the verdict is a heuristic with a row cap. The only gap is behavior on datasets without two comparable periodic resources, which an agent would want before relying on the result.

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

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

Schema description coverage is 100% and every parameter carries its own description, including the auto-detection behavior for resource_id_new/resource_id_old, so the schema does the heavy lifting. The description reinforces the 'two newest files' default comparison but adds no format, syntax, or enum guidance 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+outcome: determine whether a dataset's periodic files are cumulative or incremental. It also names the mechanism (comparing period values across the two newest files), which no sibling tool does, so an agent can distinguish it from the surrounding list_/search_/get_ 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?

Usage is implied by the decision framing ('newest file suffices' vs 'combine all'), which tells the agent what the result is for, but there is no explicit when-to-use, when-not-to-use, or named alternative — e.g. it never points at preview_resource_data or query_resource_data as the follow-up once the pattern is known.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior: it accepts the research-use terms and returns links (not the data) to multi-MB ZIPs, which tells the agent about payload size and that retrieval is a pointer rather than a content dump.

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 outcome front-loaded and the prerequisite second; there is no filler and 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 an output schema present, return-value details are not the description's burden, yet it usefully characterizes the return as links to multi-MB ZIPs. Combined with annotations and full schema coverage, this is nearly complete for a simple downloader, missing only explicit exclusion guidance.

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 only two parameters, so the schema already documents idno (source field) and the format enum. The description adds no parameter-specific detail beyond the schema, 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 clearly states the resource (an ANDA survey's microdata files) and the outcome (direct links), which an agent can distinguish from the sibling get_anda_survey_info that it names as a prerequisite. The phrasing is a noun phrase rather than an explicit verb+resource, but the action 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 explicitly tells the agent to 'Check get_anda_survey_info first', establishing a sequencing rule against a named sibling, and notes the research-use terms acceptance. It stops short of stating when NOT to use it, so it is clear context without full exclusion 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 already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), but the description adds genuinely new behavioral facts: the payload is base64-encoded and capped at 5 MB, and the text format does not return the content. Size limits and encoding expectations are exactly the kind of context annotations cannot 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?

Three short sentences with zero filler; the output nature (raw bytes, base64) is front-loaded, followed by the size constraint and the format directive. Every sentence 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?

An output schema exists, so return-value detail is unnecessary, and the description covers encoding, size cap, and format behavior. It could note whether the size cap means truncation or failure, but overall it is complete enough for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for the format parameter beyond the schema's terse 'text summary or json structured result': it clarifies that text only confirms the download while json returns the structured payload. This is decision-relevant information for the agent.

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

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

The description states a specific verb and resource ('Raw bytes of a CKAN resource'), names the encoding ('base64-encoded'), and explicitly distinguishes itself from the sibling preview_resource_data by scoping to 'formats the preview can't parse.' An agent can route between download and preview 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?

It gives a clear condition for choosing this tool over previewing ('formats the preview can't parse') and tells the agent to pass format="json" because text 'only confirms the download.' It does not state an explicit when-not case, so it falls 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful scope signal that this is the 'full published' sheet rather than a summary, but says nothing about authentication, rate limits, or whether the data can go stale relative to NOTAMs. An output schema exists, so return-shape disclosure is not required.

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 named first and the returned data fields listed after, no filler and no repetition. Nothing could be removed without losing 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 read tool with full schema coverage, an output schema and read-only annotations, the description supplies enough to invoke it correctly and sets expectations about the payload breadth. It could be marginally stronger by noting that the ICAO code must be resolved first (e.g. via list_aip_aerodromos), but 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%, so both parameters (designador with ICAO examples, format with a text/json enum) are already fully documented in the schema. The description only echoes 'ICAO code' and does not mention the format selector at all, so it adds no meaning beyond the structured fields. 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 and scope: 'Full published AIP AD 2 data sheet for one aerodrome (ICAO code)', then enumerates the payload (coordinates, runways, hours, services, frequencies, procedures). The word 'one' clearly separates it from the sibling list_aip_aerodromos, so an agent can route correctly 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?

Usage is implied rather than stated: the singular scope tells the agent this is for a single aerodrome once the ICAO code is known. There is no explicit when-to-use guidance, no mention of list_aip_aerodromos as the discovery step, and no note on how it relates to get_notam/get_metar for the same aerodrome.

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 informational content of the result (microdata availability, access terms), but since an output schema exists this overlaps with structured data, and it discloses nothing about auth, 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 dense sentence, front-loaded with the operation and purpose, with zero filler. It could arguably trim the parenthetical, but it is well-sized for the tool's simplicity.

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

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

With an output schema present, annotations covering safety, and full schema description coverage, the description only needs to convey purpose and content, which it does. Minor gaps in workflow guidance keep 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 both the required 'idno' and the 'format' enum are fully documented in the schema. The description only restates that idno comes from search_anda, adding no syntax or format detail beyond the structured fields; 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 ('Full metadata for one ANDA survey') and enumerates the content: scope, variables, microdata availability and access terms. It is clearly distinguishable from search_anda by tying the idno to that tool, but it does not explicitly contrast with download_anda_microdata or get_dataset_info, so sibling differentiation is only implicit.

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 'idno from search_anda' implies a search-then-fetch workflow, which is useful. However, there is no explicit when-to-use guidance, no mention of when to prefer this over download_anda_microdata, and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it returns links rather than file contents, and it discloses the 5 MB cap on the preview/download path that forces an alternative retrieval route.

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 waste, with the return shape front-loaded ahead of the caveat about links vs. contents and the size-limit routing. 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?

An output schema exists, so return values need not be described; annotations carry the safety profile; the description covers the one non-obvious behavior (links, not bytes) and the size-cap constraint. Nothing an agent needs to call this 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 coverage is 100%, so both enums and the seccion string are already documented in the schema; baseline 3 applies. The description only reinforces that `seccion` is an id from list_archivo_secciones, without adding 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 verb and resource ('List the downloadable files (title, URL, format) in one section') and ties itself to the sibling that produces section IDs ('from list_archivo_secciones'). An agent can distinguish it from list_archivo_secciones and from the file-fetching tools 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?

Gives the prerequisite path (a `seccion` id comes from list_archivo_secciones) and routes large-file retrieval away from this tool ('download large files directly'). It stops short of an explicit when-to-use/when-not statement naming download_resource, 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 cover safety (readOnlyHint true, destructiveHint false, openWorldHint true), so the lower bar applies. The description adds genuine operational context: the call is slow, returns ~50 rows per page, max_paginas caps the work, and completo indicates whether reading was exhaustive — exactly the partial-result caveat an agent needs for a paginated scrape.

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, zero filler, with the action and the pagination caveat front-loaded. Every clause carries information an agent can act on.

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, output-schema-backed report tool, the definition covers the essentials: what it does, its slowness, and how to detect incomplete reads. It omits any note on rate limits/repeat-call cost on this 'slow' endpoint and doesn't state that tipo must come from list_arconel_reportes (left to 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%, so the baseline is 3. The description goes beyond it by explaining the pagination semantics of max_paginas ('caps work') and the meaning of completo ('says if everything was read'), i.e. how to interpret a truncated result — real added value over 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 ('Run one ARCONEL report ... and return its rows') and grounds it with a concrete example ('Balance Energía' for a year). It does not explicitly name the sibling list_arconel_reportes as the discovery step, but the purpose is unmistakable.

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 conveys the general situation (running a single report for a given period) but gives no explicit when-to-use vs when-not-to, and does not tell the agent to call list_arconel_reportes first to obtain a valid tipo. Usage is implied rather than directed.

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 useful detail that the response includes authorization, nationality and contact data, but says nothing about behavior when the identifier is not found or about the external (open-world) data source behind it.

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 identifies the record type, the returned fields and the key, with no filler. Slightly terse as a sentence fragment, but it wastes nothing.

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 an output schema and full schema coverage, the description is largely sufficient; return values need not be explained because the output schema exists. The one gap is the absent routing hint to the sibling search_auditores.

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 (identificacion, format) are already documented in the schema. The description restates the RUC/cédula lookup key but adds no format, validation or syntax detail beyond what the schema provides; 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 resource (one external auditor), the fields returned (authorization, nationality, contact details) and the lookup key (RUC or cédula), so the agent knows exactly what this does. It does not explicitly contrast itself with the sibling search_auditores, but the singular 'One' implies a single-record lookup distinct from a search.

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

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

Usage is implied by the 'by RUC or cédula' lookup key and the singular framing, which suggests this is for retrieving a known auditor rather than searching. There is no explicit statement of when to use this versus search_auditores, and no prerequisites or failure conditions 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 cover the safety profile (readOnly, non-destructive), so the description earns credit for adding real context: that the standard layout yields date-filterable series while other layouts return a faithful preview, and that boletin_numero switches to a past bulletin. That is meaningful behavior beyond the annotations, though it stops short of noting size/pagination 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 tightly packed sentences with no filler and the key identifier (table_id source) front-loaded. The 'faithful preview otherwise' clause is deliberately compressed and slightly cryptic, 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 an output schema present, return values needn't be described, and the description covers the layout-dependent behavior plus bulletin selection. For a read-only table fetcher it is nearly complete, missing only guidance on row limits or large-table 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 the schema already documents all six parameters including formats and defaults. The description only reinforces the provenance of table_id and the role of boletin_numero, adding little beyond what the schema states. 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 the sibling search_bce_iem as the source of table_id, which distinguishes it from that search tool. The 'standard layout / faithful preview' split further clarifies what actually comes back. Slightly terse but an agent can tell what this fetches.

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 implies the workflow by naming search_bce_iem as the origin of table_id and search_bce_iem(historico=true) as the origin of boletin_numero, but never states explicitly when to call this instead of the search tool or what condition selects it. Usage is inferable rather than declared.

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 genuine context beyond that: the hard 366-row cap and the mutual exclusivity of the two query modes. It omits auth requirements but the annotation bar is lower here.

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 that front-loads the resource and the key provenance constraint. No filler, though the parenthetical breaks the flow slightly.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies the row cap and mode selection, but leaves sibling routing and any auth/permission context unaddressed, so it is strong but not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the ultimos_n/date-range interaction. The description largely restates the schema rather than adding format or validation detail, 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 concrete resource (one BCE daily/monthly indicator) and explicitly ties its required inputs (archivo and codigo) to list_bce_indicadores_diarios, which distinguishes it from that list sibling. However it never differentiates from the similarly named get_indicador_bce/search_indicadores_bce, so sibling separation is only partial.

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 reveals two retrieval modes (last ultimos_n points or a date range), which implies usage, but never states when to choose this tool over get_indicador_bce or the search/list siblings. No explicit when-to-use or when-not guidance is 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, openWorldHint, and destructiveHint. The description adds useful behavioral context: the result includes title, URL and format, sorted most recent first, and anio only filters the indices catalog. It does not discuss rate limits, pagination, or auth, but with annotations covering safety, this is strong.

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 with no filler. The first sentence front-loads the purpose and return details; the second adds the anio filter constraint. Every sentence 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 an output schema, complete input schema descriptions, and annotations, the description needs only to orient the agent. It states what the tool returns, the sort order, and the conditional anio filter, which is enough for correct invocation across the five parameters.

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 five parameters, including defaults, enums, and constraints. The description restates that anio filters the indices catalog by year and mentions sorting, but adds little beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: returns files of one BCE publication page, with returned fields (title, URL, format) and sort order. It also identifies where pagina_id comes from (search_bce_paginas). However, it does not explicitly differentiate from sibling tools like get_inec_publicacion_archivos or get_bce_iem_table, so it stops short of a 5.

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

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

Usage is implied: call this to get files for a BCE page, after obtaining pagina_id from search_bce_paginas. The description notes that anio filters the indices catalog by year, adding context. But there is no explicit when-to-use vs. alternatives or exclusions, so it remains at the minimum-viable level.

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

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

The description adds substantial behavioral detail beyond the annotations: it caps results at 20 features, drops geometry, returns only attributes, and explicitly labels itself a preview rather than a spatial query. Annotations already confirm read-only and non-destructive behavior, and the description does not contradict them. This gives the agent a clear picture of what the call actually does.

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 written sentences, front-loaded with the main action and then immediately scoped with limitations. Every clause earns its place by clarifying the preview nature, the source, and the unsupported spatial operations.

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 full schema coverage, rich annotations, and an output schema, the description supplies the key missing behavioral context: preview scope, geometry removal, and absence of spatial filters. It does not need to explain return values because an output schema exists. 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 the schema already fully documents capa, count, format, and fuente. The description reinforces that capa comes from search_capas_geo and that the tool is limited to 20 features, but it adds little parameter-specific meaning beyond the schema. Baseline 3 is appropriate when the schema carries the parameter semantics.

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

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

The description states a specific verb and resource: 'Sample up to 20 features' attributes from a WFS-enabled layer.' It distinguishes this preview tool from a spatial query by explicitly saying there is no bbox or filters and geometry is dropped. It also identifies the source layer from the sibling tool search_capas_geo.

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 clear usage context: use this to preview attributes from a layer obtained via search_capas_geo, and not for spatial queries because bbox and filters are unsupported. It does not name a specific alternative tool for full spatial querying, but the exclusions and source dependency are explicit enough for 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 that the response includes sample datasets (which the include_datasets parameter can toggle), but says nothing about source-specific behavior, missing categories, 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?

A single front-loaded sentence with no filler; the core output ('details and sample datasets') comes first. It is arguably terser than ideal for a four-parameter tool, 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?

An output schema exists, so return-format description isn't needed, and param coverage is complete. What remains is a simple read-only lookup with clear provenance for the required argument, leaving only minor gaps around multi-source 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 description coverage is 100% and all four parameters (format, source, category, include_datasets) carry their own enum/default documentation. The description only echoes the category-from-list_categories rule already stated in the schema, adding no new parameter meaning.

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

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

States a clear verb+resource: retrieve details plus sample datasets for a single CKAN thematic category. It also points at the list_categories sibling as the source of the required name, which lets an agent separate listing from detail-lookup. It doesn't explicitly contrast the two tools, so it falls just short of 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 '(name from list_categories)' implies the intended workflow, i.e. call list_categories first, then look one up here. Beyond that there is no stated when-to-use, when-not, or alternative (e.g. get_dataset_info vs this) 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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the data is a live/real-time snapshot and excludes historical queries, but says nothing about freshness, update cadence, or error conditions.

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 the resource and scope followed by the exclusion. Nothing is wasted, though it is terse enough to leave gaps.

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 an output schema present and safety annotations covering the operation, the description supplies the essential scope plus the historical-query exclusion. It is complete enough to call correctly, missing only minor behavioral 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 coverage is 100% with both enums documented, so the schema already carries the parameter burden. The description's 'now, yesterday, month or year to date' loosely maps to the tablero enum values, adding marginal orientation but no syntax or selection guidance.

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: 'CENACE live grid snapshot: generation mix and demand' with temporal ranges. The 'No historical queries' clause helps separate it from historical-data siblings, though it does not name a specific alternative.

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 'No historical queries' is an implicit when-not and the time ranges ('now, yesterday, month or year to date') imply when to use it. However, no sibling tool is named and no explicit alternative for historical data is offered.

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 one genuine behavioral trait beyond that – dimension ids are decoded to labels in the output – but says nothing about return volume, pagination, or missing-data 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 core action and its scoping constraint come first. Appropriately sized given a 100%-covered schema, output schema, and safety annotations.

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 an output schema present and full parameter coverage, the description need not explain return values, and it correctly doesn't. It is nearly complete for a read-only retrieval tool, with only the missing sibling-routing guidance as a residual 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 the schema already documents all four parameters including enums and defaults. The description only restates the country-scoping behavior ('one country, Ecuador by default'), adding no syntax or format detail beyond what the schema provides. 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 ('Observations of one CEPALSTAT indicator for one country') plus useful scope details (Ecuador default, dimension ids decoded to labels). An agent can tell it retrieves observation data, but the description never names its sibling search_cepalstat_indicadores, so differentiation relies on 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?

The description gives no when-to-use, when-not-to-use, or alternative guidance. The only contextual hint ('Ecuador by default') is a parameter default, not usage direction; the routing hint to search_cepalstat_indicadores lives in the indicator_id schema field, not the description.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds that it's a compliance check (not a headcount) but does not disclose additional behavioral traits like rate limits or authentication needs. With annotations, this is adequate.

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 purpose and immediately followed by a useful disambiguation. No wasted words.

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

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

For a simple read-only compliance check with an output schema and full annotation coverage, the description covers purpose, scope, and the key alternative. 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%, so both parameters (identificacion and format) are fully documented in the schema. The description loosely mentions RUC/cédula but adds no syntax or format details 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 check (whether an employer or person is current on IESS contributions) and distinguishes from get_financials' headcount. Clear verb+resource and 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?

Provides context for when to use this tool (compliance check) and explicitly points to get_financials' n_empleados for employee counts. Does not mention other IESS-related siblings like list_iess_colecciones, but the primary alternative is covered.

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 useful negative scope ('No financials') so the agent won't expect balance-sheet data, but it discloses nothing about freshness, coverage limits, or error behavior for invalid RUCs.

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 that front-loads the resource and provenance, then lists outputs and the scope boundary. 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 an output schema present, return values needn't be explained, and the two-parameter surface is simple. The field list and 'No financials' bound are sufficient for correct invocation, though a pointer to the alternative tool for financials would complete the routing picture.

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 required ruc and the format enum are already documented in the schema. The description only restates 'by RUC' and adds no format/syntax detail beyond structured fields, 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?

Specific verb+resource ('registry record for one company by RUC') with an enumerated field list (status, incorporation, representative, capital, CIIU, address) and an explicit scope exclusion ('No financials') that distinguishes it from the sibling get_financials. An agent can identify what this 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?

'No financials' implies the alternative (get_financials) without naming it or stating the condition under which to switch. Usage is implied rather than spelled out, and no mention is made of the adjacent get_sri_ruc_info sibling for tax-level data.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context about the two possible return shapes (CSV rows vs. metadata + read_pdf pointer), but since an output schema exists, this return-shape information is partly redundant and no further behavioral traits (pagination beyond 'rows', auth, etc.) are disclosed.

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 written sentence that front-loads the primary output (rows of the CSV) and then notes the alternative shape. No filler or repetition.

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

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

With annotations covering the safety profile, a complete input schema, and an output schema handling return structure, the description is adequate for an agent to call the tool correctly and even hints at a follow-up (read_pdf). It could be stronger by explicitly tying itself to the list_contraloria_informes workflow, hence not 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 three parameters (rows, format, informe_id) are already documented in the schema, including defaults, max, and the enum. The description adds no additional parameter semantics, so the baseline 3 for high 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?

The description states a specific resource (a Contraloría audit-reports CSV / annual plan) and what it returns (rows, or metadata plus a read_pdf pointer), so the agent understands it's a single-item fetch. It doesn't explicitly name or contrast with the sibling list_contraloria_informes, so it falls short of a 5, though the informe_id schema hint covers routing.

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 informe_id parameter is described as 'An id from list_contraloria_informes', which suggests a list-then-get flow, but the description itself gives no explicit when-to-use or when-not-to-use guidance versus alternatives like search_informes_igepn or get_informe_igepn.

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 useful content scope by listing what the record contains (buyer, tender, awards, contracts) but says nothing about auth needs, rate limits, or record availability.

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 action and scope lead, and the supporting detail follows compactly.

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

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

An output schema exists, so return-value explanation is unnecessary, and the required single ocid is clear. The definition is nearly complete for a read-only detail fetch, lacking only explicit workflow guidance relative to search_contratos.

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 (ocid, format) are fully documented in the schema with an example and enum. The description adds only the provenance of ocid from search_contratos, which is a small increment over the schema 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+resource: retrieves the full OCDS record of one SERCOP procurement process, and enumerates contents (buyer, tender, awards, contracts). The parenthetical '(ocid from search_contratos)' signals it is the detail companion to the search tool, giving partial 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?

Usage is only implied through the parenthetical that the ocid comes from search_contratos, which hints at the lookup-vs-detail workflow. There is no explicit when-to-use, when-not-to-use, or named alternative 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 already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine domain behavior: it parses exactly one PDF, and location meaning differs by distributor (EEQ substation vs Centrosur province/canton/zone). It omits error handling and parsing 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 tight sentences, front-loaded with the core action and output fields, followed by the filtering detail. 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?

With an output schema present, the description needn't detail return values, and it adequately covers scope, source and filtering. It could still note behavior for malformed/ambiguous PDFs, which keeps it just short of 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 coverage is 100%, so a 3 is the baseline. The description adds meaning about the `distribuidora` parameter by explaining that it drives whether location is reported as a substation (EEQ) or province/canton/zone (Centrosur), and clarifies that `query` filters by place, giving it a slight lift over the schema alone.

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 (parse), a specific resource (one power-cut PDF) and the exact output shape: date, time blocks, location, sectors. It also situates itself relative to search_cortes by naming where the `archivo` comes from, so an agent can distinguish it from the sibling search 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 description makes the workflow explicit: take the `archivo` from search_cortes and parse it, with `query` filtering by place. This is clear context for when to use it, but it names no exclusions or failure conditions (e.g., what to do if the PDF is malformed) to reach 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, openWorldHint=true and destructiveHint=false, so safety behavior is covered. The description mainly restates the shape of the returned metadata, which the output schema already provides, and adds nothing about auth, rate limits, or whether a missing id errors.

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 colon-separated field list is compact. Slightly listy, but every element is informative and 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 an output schema and read-only annotations in place, the definition meets the minimum needed to call it. It still omits how to obtain a valid dataset_id and how portal selection interacts with the dataset, which is meaningful guidance for this family of tools.

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 the source enum and format enum are documented in the schema, so the baseline is 3. The description does not clarify that 'source' selects among multiple CKAN portals or that dataset_id accepts slugs, adding nothing 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?

Names a specific verb+resource (get metadata for one CKAN dataset) and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not, however, contrast itself with near siblings like get_resource_info, get_organization_info or investigate_dataset, so differentiation is left to inference.

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

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

There is no statement of when to use this tool versus alternatives (e.g. search_datasets to find the id, or get_resource_info for files). The only implicit guidance is the singular 'one dataset', which is thin.

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 structurally. The description adds a genuinely useful behavioral caveat, that this is a frozen 2024-04-24 snapshot with only EEQ's Pichincha rotation surviving, which warns the agent about data coverage limits. No auth or rate-limit details, so 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, well-front-loaded sentence that leads with what it is (Wayback snapshot of a specific portal) before narrowing to scope. No wasted words, though it lacks any routing or usage 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?

An output schema exists, so return values need not be explained here. The description conveys the resource and its data limitation, but an agent still has no guidance on when to select this tool over the live outage-schedule siblings, leaving a completeness 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 both the query (matched against canton or sectores) and the format enum are already documented in the schema. The description adds no syntax or format detail for either parameter, 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 and what it is: a Wayback Machine snapshot of the energia-ecuador.com portal, with a date and the surviving data scope. An agent understands what this returns. However, it does not distinguish itself from closely related siblings like search_cortes or get_cortes_horarios, which also concern outage schedules.

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

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

There is no when-to-use guidance and no named alternative. The description scopes the data ('only EEQ's Pichincha rotation survived'), which implicitly tells the agent the dataset is narrow, but it never says when to prefer this snapshot over the live search_cortes / get_cortes_horarios 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond the annotations by disclosing the data scope ('last five fiscal years'), which bounds what comes back, but it says nothing about permissions, rate limits, or behavior of the anio filter.

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 the resource and scope, with the identifier sentence last. The field enumeration earns its place by telling the agent what is returned, though with an output schema present it is slightly 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?

An output schema exists so return values need not be described, and annotations cover the safety profile; the description supplies the resource, the five-year scope and the accepted identifiers. The only real gap is the missing routing guidance versus get_compania_info/search_companias.

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 thoroughly. The description only reinforces the accepted identifier ('expediente or RUC') and hints at the five-year window, adding little beyond what the schema already provides — the baseline 3.

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 company's Supercías financial history') and enumerates the returned fields (revenue, assets, equity, profit, employees, ratios) plus scope ('last five fiscal years'), so an agent knows exactly what it retrieves. It does not explicitly differentiate itself from the sibling get_compania_info/search_companias, so it falls short of a 5.

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

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

Usage is only implied: 'Takes expediente or RUC' signals this is the drill-down after identifying a company, but there is no explicit when-to-use or when-not-to-use statement, and no sibling is named in the description text as an alternative.

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 two useful facts beyond that: results include direct links, and one collection has a mandatory filter. It says nothing about result size, pagination, or what happens with an empty query.

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, and the collection-scoping constraint is stated up front. It is a noun-phrase fragment rather than a verb-led statement, so it is efficient but slightly less immediately actionable than a full imperative sentence.

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 an output schema present, annotations covering safety, and 100% parameter coverage, the description needn't explain return values. It supplies purpose, link-return behavior and the one conditional parameter rule; only pagination/size expectations are absent, which is minor here.

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 documents each parameter's meaning and the coleccion enum already carries long explanatory text. The description adds a conditional requirement (anio mandatory for informes_auditoria) that is not encoded anywhere in the schema, which is real added semantics.

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

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

States the specific resource (documents in one IESS collection) and a distinctive return trait (direct links). It is clearly distinct from list_iess_colecciones (which enumerates collections), though it does not name 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?

Gives one concrete usage constraint — 'anio is required for informes_auditoria' — which is genuine when-to-use information. It never states the alternative (e.g. call list_iess_colecciones first to discover valid collection values, or use search_archivos for general file search).

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 only that the range, frequency and unit are optional filters, without noting limits, failures on unknown group ids, or payload size — modest added value on top of 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 front-loaded sentence packs the verb, resource, provenance of the key parameter, and the optional filters with zero filler. Nothing could be trimmed without losing 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 an output schema present, return values need not be explained, and the required id_grupo plus its source tool is covered along with the optional narrowing filters. It could still mention the default text-vs-json output mode or behavior on an invalid group id, but it is complete enough to call 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%, so all six parameters (including YYYY-MM semantics, the frequency enum and the unit examples) are already documented in the schema. The description merely restates "optional YYYY-MM range, frequency and unit", adding no meaning 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?

The description gives a specific verb and resource ("Time series of one BCEData group") and names its sibling search_indicadores_bce as the provenance of id_grupo, which cleanly separates retrieval from discovery. It stops short of explicitly contrasting itself with the other BCE sibling tools, but the resource 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?

The parenthetical "id_grupo from search_indicadores_bce" tells the agent the prerequisite discovery step and what value to feed in. There is no explicit when-not or exclusion guidance, but the context for invocation 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=true, destructiveHint=false and openWorldHint=true, so safety and network reach are covered. The description adds the useful scoping fact that output is one topic page's file links, but says nothing about pagination, whether all links are returned, or extraction failure 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 sentence front-loads the resource (file links) and the parenthetical examples, with the qualifying scope clause last. 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?

An output schema exists, so return-shape explanation is unnecessary, and annotations cover safety. The description supplies the required input provenance; only minor gaps around result scope and the format switch remain.

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 url (provenance and gob.ec domain constraint) and the text/json format enum are fully documented in the schema. The description adds only the loose phrase "topic page" and no format detail, 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 (retrieves file links) and resource (bulletins, methodology, historical series on one INEC topic page), and anchors it to the sibling that produces the input URL. This clearly separates it from search_inec_estadisticas and from parallel archivo tools like get_inec_publicacion_archivos and get_bce_pagina_archivos.

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 dependency chain is explicit: the URL must come from search_inec_estadisticas's "url" field, which tells the agent when to reach for this tool. There is no explicit when-not-to-use or statement about the publicaciones variant, 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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that it returns file links (not the files themselves), which is useful, but says nothing about auth, rate limits, or whether downloads are fetched. With annotations carrying the behavioral burden and an output schema present, 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 front-loaded sentence with no filler; the returned formats and the scoping ('one INEC publication') are packed into one line 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?

An output schema exists, so return values need not be re-explained, and annotations cover the safety profile. For a simple two-parameter retrieval tool the description is nearly complete; only deeper workflow/pagination details are absent, which is acceptable here.

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 'post' and 'format' parameters are fully documented in the schema. The description only restates 'id or URL' without adding syntax, accepted URL forms, or format behavior beyond the schema's default. Baseline 3 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 resource (file links in one INEC publication) and enumerates the returned formats (PDF/XLSX/CSV/ZIP), which is more concrete than the title alone. It implicitly contrasts with search_inec_publicaciones by scoping to 'one' publication and citing that sibling as the id source, so an agent can distinguish listing from fetching.

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)' establishes the workflow: run the search tool first, then call this with the resulting id or URL. This gives clear context for when the tool applies, though it offers no explicit when-not conditions or alternative file-listing 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/openWorld/destructive=false, so the safety profile is covered. The description adds real behavioral context beyond that: the page-range limit of 'max 20/call' and the disambiguation rule (volcan only when names repeat). It doesn't cover failure modes or pagination beyond pages, keeping it from 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?

A single front-loaded sentence carries the workflow, disambiguation rule, and page cap with no filler. It is somewhat run-on (parenthetical nesting), which keeps it from a 5, 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 an output schema present, return values needn't be explained, and the description adequately covers the search-then-fetch workflow, disambiguation, and the page cap for a 6-param tool. Minor gaps (behavior when the report is missing) are tolerable given the rich 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% so the baseline is 3, but the description contributes a constraint absent from the schema: 'pages limits the range (max 20/call)'. It also ties nombre/grupo/anio/volcan semantics to the re-location workflow, adding meaning over raw field descriptions.

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

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

States a specific verb pair (download and extract text) and a precise resource (one IG-EPN report), and explicitly ties itself to the search_informes_igepn sibling as its source. An agent can distinguish this retrieval tool from the search tool 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?

Clearly frames the workflow: the report comes 'from search_informes_igepn' and must be re-located by the same nombre/grupo/anio values, with volcan only when names repeat. This tells the agent when to use it and how it relates to the search step, though it doesn't explicitly state what to do if the report isn't found.

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 only the returned attribute set, and says nothing about invalid-ID behavior, pagination or data freshness. Adequate but not rich.

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 terse sentence with zero filler; the resource and returned fields are front-loaded. It is efficient, though so short that it reads as a label rather than a definition.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. Still, for a lookup tool in a large sibling ecosystem, the description omits how to obtain the ID and how this differs from list_instituciones, leaving a gap an agent must resolve by inference.

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 documented in the schema (institucion_id example and the format enum with default). The description adds no syntax, format or ID-sourcing detail beyond the schema, 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 the resource and scope ('One gob.ec institution') plus the fields returned (acronym, sector, description, websites), which tells an agent it is a single-record lookup. However, it is a verbless fragment, and it never distinguishes itself from the sibling 'list_instituciones' beyond the word 'One'. Purpose is inferable but not stated with a 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 when-to-use guidance, no indication that institucion_id must first come from list_instituciones, and no exclusions relative to siblings such as list_instituciones or get_organization_info. The only routing signal is 'gob.ec', which is implied context rather than stated 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 already cover read-only and open-world safety, so the description only needs to add context. It adds freshness ('Latest'), return format ('raw ICAO text with UTC times'), and data source ('from DGAC/AIS'), which helps an agent understand the output without duplicating structured fields. It omits rate limits, caching, and update frequency, but that is a minor gap given 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 sentence with zero waste, front-loading the resource and scope followed by return details and source. Every phrase earns its place and there is no 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?

The tool is simple, with full schema coverage, a defined output schema, and annotations that cover safety. The description supplies purpose, scope, source, and return format, which is sufficient for an agent to call it correctly without further guidance.

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 both parameters thoroughly, including examples for designador and the format enum. The description repeats the ICAO-code example but adds no meaning beyond the schema, 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?

States a specific resource (METAR/SPECI weather reports) for a clear scope (Ecuadorian aerodrome, ICAO code), and by naming METAR/SPECI it implicitly distinguishes itself from sibling NOTAM/SIGMET tools. An agent can tell what it retrieves 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?

Provides clear context for what the tool returns, so usage is implied for weather-report lookups, but it does not explicitly say when to use this versus alternatives such as get_notam, get_sigmet, or get_aip_aerodromo. No exclusions or prerequisites are 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=true, openWorldHint=true and destructiveHint=false, covering the safety/world profile. The description usefully adds that results are filtered to active NOTAMs and combines raw ICAO text with DGAC-decoded fields, but discloses no auth needs, rate limits, or freshness caveats.

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 that front-loads the resource and the key parameter constraint. Efficient, though bundling scope, parameter and payload into one clause leaves no room for usage guidance.

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 2-parameter read tool with an output schema and full annotation coverage, the description conveys purpose, scope and payload adequately. The missing piece is when to prefer it over the sibling weather/AIP tools, which 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 both parameters (designador and format) are already fully documented with examples and an enum. The description only reiterates the ICAO code concept ('e.g. SEQM') and says nothing about the format option, 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 ('Active NOTAMs') plus the domain scope ('Ecuadorian aerodrome') and even summarizes the payload ('raw ICAO text plus DGAC's decoded fields'). It doesn't explicitly distinguish itself from adjacent siblings get_metar and get_sigmet, 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?

No explicit when/when-not guidance and no mention of alternatives. The aviation context implies the use case (check NOTAMs for an aerodrome), but the agent gets no routing help versus get_metar/get_sigmet or the AIP 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 readOnlyHint, destructiveHint and openWorldHint, so the safety profile is known without the description. The description adds essentially no behavioral context beyond that: no indication of result size, truncation, or pagination, which is a real gap for a tool explicitly pitched at 'large publishers'.

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 stated first and the use case second; nothing is padded. It is slightly clipped (semicolon splice) but no sentence is wasted.

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

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

An output schema exists, so return values need no explanation, and the schema fully documents the four parameters. Purpose, scope and the query filter are present; the only mild omission is the multi-portal source dimension, which the schema nevertheless covers.

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 (query, format, source, organization_id) is already documented in the schema, including the enum meanings and defaults. The description only restates the query filter ('filters dataset titles'), adding nothing about the source portal dimension or format.

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: returns one CKAN organization together with its datasets, and adds the use case (browsing large publishers) with a concrete example slug. It distinguishes itself implicitly from list-style siblings by emphasizing 'one' organization, but never names search_organizations, which is the nearest alternative.

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 way to browse large publishers (e.g. sri-servicio-de-rentas-internas)' gives implied usage context, and the query hint suggests narrowing within big publishers. However, there is no explicit when-to-use vs. search_organizations / get_dataset_info guidance and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the returned field list, with no note on auth needs, rate limits, or error behavior, so it adds modest value beyond the structured 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 with zero filler that names the resource and its return fields. Every word 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 an output schema handling return structure and annotations covering the safety profile, the description is nearly sufficient. The only gap is routing guidance versus the list/search siblings.

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 (regulacion_id, format enum) are documented in the schema. The description adds no syntax or format guidance 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 verb (get) and resource (one gob.ec regulation) and enumerates what it returns (type, Registro Oficial reference, description, PDF link). It implies single-item retrieval but does not explicitly name the sibling it contrasts with (search_regulaciones).

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

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

No when-to-use context or exclusions are given. The word 'One' hints at single-item lookup versus a search, but the agent is left to infer that search_regulaciones is the alternative for 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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that the operation is metadata-only for one resource and enumerates the returned fields, but it does not discuss authentication, rate limits, or other behavioral traits beyond what annotations 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?

A single front-loaded sentence with no filler, immediately stating the resource and the metadata contents. It is appropriately sized for a simple read-only tool.

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

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

Given the simple read-only operation, full schema coverage, annotations, and an output schema, the description supplies enough context to call the tool correctly. It does not explain return values, but with an output schema that is unnecessary; only stronger usage routing would improve completeness.

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

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

Schema description coverage is 100%, so resource_id, format, and source are fully documented in the schema. The description mentions return fields, not parameter meaning, so it adds no parameter semantics beyond the schema 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: retrieves metadata for one CKAN resource/file, and lists the metadata fields returned (format, size, MIME type, download URL, parent dataset). It is clear enough to distinguish from dataset-level tools by scope, but it does not name any sibling alternative, so it falls 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?

Provides no when-to-use guidance, no prerequisites, and no alternatives such as download_resource or get_dataset_info. An agent can infer it is for metadata retrieval, but nothing explicit routes it against 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 declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context by clarifying that it returns links rather than contents, which is the key output trait an agent needs to know.

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 written sentences with zero filler. The core distinction — what it returns and what it does not — is front-loaded and immediately useful.

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 an output schema present, annotations covering safety, and complete parameter schema coverage, the description only needs to state purpose and the links-vs-contents distinction. It does exactly that, so nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates where evento_url comes from (search_sgr_sitreps's URL field), which the schema already documents, and it says nothing about the format parameter; it adds no syntax or semantic detail beyond structured fields.

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 (SITREP PDF links), scope (national, provincial, cantonal), and source (one SGR event page from search_sgr_sitreps). It explicitly says 'Returns links, not contents,' which sharply distinguishes it from content-reading siblings like 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 implies the tool should be used after search_sgr_sitreps by naming that sibling as the source of the event URL. It also implicitly differentiates from content tools via 'not contents,' but it never states when not to use this tool or names an explicit alternative for reading the PDFs.

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 and openWorldHint, so the safety profile is covered. The description adds real value beyond that: it clarifies the 'empty' result means no active advisories (not an error) and constrains scope to one FIR, so no region argument is expected.

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, scope and coverage front-loaded before the empty-result caveat. 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 an output schema present, return values need no explanation, and read-only annotations cover safety. The description supplies scope, coverage and empty-result semantics, leaving only alternative-selection guidance unaddressed, which is minor for a one-parameter 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% and the single 'format' enum is fully documented in the schema, so the baseline of 3 applies. The description adds nothing about output format or the text-vs-json distinction.

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 ('Active SIGMETs') with geographic scope pinned to Ecuador's single FIR (SEFG), and enumerates the phenomena covered (volcanic ash, turbulence, icing, storms). This lets an agent separate it from aviation siblings like get_metar and get_notam without inspecting 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?

Usage is only implied: an agent can infer this is the aviation-hazard product versus METAR/NOTAM, but the description never says when to reach for this tool instead of those, nor any conditions or exclusions. It is adequate but leaves 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 declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds that the result is a set of monthly PDF links rather than inline indicator values, which is genuinely useful return-format context beyond the annotations, though auth/rate/limitations are undisclosed.

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

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

A single front-loaded sentence with zero filler; the resource, scope, and coverage window are all present and nothing is 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?

An output schema exists, so return-value detail is not required here, and the annotations carry the safety profile. Combined with the description's coverage window and PDF-link disclosure, an agent has enough to invoke it correctly; only explicit connection to the download tool for retrieving the PDFs is 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 adds real meaning the schema lacks: the valid year floor of 2018 and the fact that results are monthly links. It does not clarify the format enum, but it still exceeds the baseline by constraining the required anio parameter's acceptable range.

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 (SIPA/MAG 'Resumen de Indicadores'), the output form (monthly PDF links), and the time scope (one year, 2018 onward), so an agent knows exactly what it fetches. It does not reference a sibling tool, but no near-duplicate SIPA tool exists in the list, so differentiation is not critical.

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 only guidance is the implicit coverage window ('2018 onward'), which sets a validity bound but is really a parameter range. There is no statement of when to prefer this over alternatives or any exclusions/routing hints.

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=true, openWorldHint=true, destructiveHint=false), so the lower bar applies. The description still adds real value by bounding the returned data — 'No tax amounts' tells the agent this is identity/registry data, not financial 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 tight sentences with the resource and scope constraint front-loaded and zero filler. Nothing can be cut without losing 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?

An output schema exists, so return values need not be explained, yet the description still sketches them without redundancy. Combined with full schema coverage and annotations, an agent has everything needed to invoke the tool correctly; only the relationship to search_sri_ruc is left 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 description coverage is 100%, so the schema already documents ruc, format and include_establecimientos, including the enum and defaults. The description adds little beyond naming the returned fields, which only loosely maps to include_establecimientos. 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 (public SRI record for a single 13-digit RUC) and enumerates the fields returned. The phrase 'one 13-digit RUC' implicitly distinguishes it from the sibling search_sri_ruc, but it never names that alternative, so the differentiation is inferential 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?

Usage is implied: call it when you already hold an exact 13-digit RUC and want a single-record lookup. 'No tax amounts' is a data-scope caveat, not a when-to-use/when-not-to-use rule, and no alternative (e.g. search_sri_ruc) is offered for partial or name-based 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 and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the shape of the result (columns, measures, date levels), but says nothing about latency, rate limits, authentication, or behavior for an invalid indicador key. With annotations carrying the core behavioral traits, 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 tight sentence with no filler; the resource and its return contents are front-loaded, and the trailing reference to query_sut_indicador closes the loop efficiently.

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 an output schema present, the description needn't explain return values, and annotations plus full parameter coverage handle most of the burden. The only mild gap is that it doesn't state what happens for an invalid or missing indicador key, but nothing an agent needs to invoke it correctly is 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 description coverage is 100%, so both parameters (indicador, format) are already documented, and the description reinforces that one indicator key is being targeted. It adds no syntax or format 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 definition states a specific resource (queryable fields of one SUT dashboard indicator) and enumerates exactly what is returned: columns, measures ([medida]) and date levels. It also names the consumer tool query_sut_indicador, so an agent can distinguish this schema-discovery tool from the sibling that actually runs the query.

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' makes the intended workflow clear: call this to learn the available fields before querying. There is no explicit when-not or exclusion guidance, but the pairing with the sibling tool leaves little ambiguity about when to reach for 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 useful scope context (monthly granularity, since mid-2021, attentions and complaints), but does not describe return format or any constraints; with annotations carrying the behavioral load, 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 efficient sentence with the resource and scope front-loaded. Nothing is wasted, though it is arguably under-specified rather than optimally concise.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The remaining gap is usage guidance versus sibling tools, which the description does not address, making it minimally adequate rather than complete.

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

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

Schema description coverage is 100%, so both tramite_id and format are fully documented in the schema. The description adds only the framing that the ID refers to a single gob.ec trámite, which is marginal beyond the schema's example. Baseline 3 is correct 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 names the resource (monthly attentions and complaints for one gob.ec trámite) and a temporal scope (since mid-2021), which is specific enough for an agent to know it retrieves usage statistics. However, it doesn't explicitly distinguish itself from siblings like get_tramite_info or search_tramites, leaving that differentiation to inference.

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 or mention of alternatives. An agent must infer from the name and sibling list that this is the statistics companion to get_tramite_info, with no stated conditions or exclusions.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds the content scope (what fields are returned) but discloses nothing about auth, rate limits, or failure behavior beyond that.

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 the resource first and the ID source trailing; every clause earns its place with no padding.

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

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

For a simple read-only tool with 100% schema coverage, full annotations and an output schema, the description needs only to identify the resource and where the ID comes from, which it does. It is essentially complete, with only minor room to note its distinction from the estadísticas sibling.

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 adds genuine provenance for tramite_id by tying it to search_tramites, which helps an agent know where to obtain the required value. The format enum is left entirely to 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 (get one gob.ec trámite) and enumerates what it returns: requirements, beneficiaries, cost and responsible institution. The singular 'One ... trámite' implicitly sets it apart from the sibling get_tramite_estadisticas, though 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?

The parenthetical '(tramite_id from search_tramites)' is a useful routing hint that this tool is a follow-up to search_tramites. However, it gives no explicit when-to-use/when-not guidance and never points to get_tramite_estadisticas as an alternative for a different need.

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 adds non-obvious behavior: this is a chained operation whose result is limited to the top hit and first readable resource, warning the agent that the result may not be the best dataset.

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 padding, with the core behavior front-loaded and the alternative-tool 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?

An output schema exists and annotations cover safety, so the description needn't explain return values. It communicates the composite nature and the top-hit limitation, though it doesn't note what happens when no readable resource is 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%, so all four parameters (query, format, source, preview_rows) are already documented with defaults and enums. The description adds no syntax or semantic detail beyond the schema, 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 composite action: search CKAN, take the top dataset, preview its first readable resource. This clearly distinguishes it from siblings like search_datasets and preview_resource_data, which do only one step each.

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 to fall back to 'the individual tools' when the top hit isn't right, which gives a clear when-to-use/when-not signal. It stops short of naming the specific alternative tools, but the routing intent is unambiguous.

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, covering the safety profile. The description adds useful scope context about published AIP AD 2 pages and DGAC eAIP, but does not disclose pagination, ordering, or other operational 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?

The description is two short, front-loaded sentences with no wasted wording. It states the content and the next tool 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?

For a simple listing tool with complete parameter documentation and an available output schema, the description covers the core content and workflow routing. It leaves out minor details such as pagination or ordering, but those are not critical for correct invocation.

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

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

Schema description coverage is 100%, and the single optional format parameter is fully documented in the schema. The description adds no additional meaning about the format parameter, so the baseline of 3 is appropriate.

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

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

The description states a specific resource and scope: ICAO codes and names of aerodromes/helipads with a published AIP AD 2 page. It also distinguishes itself from the related detail tool by ending with 'Next: 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?

The phrase 'Next: get_aip_aerodromo' gives clear follow-up routing, implying this tool is for finding aerodromes and the sibling is for details. However, it does not explicitly state when to use this tool versus alternatives 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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope (which institutions are included) and the chaining hint, but says nothing about pagination, result size, or auth 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 sentences, front-loaded with the core action and scoped with the source list, then the chaining hint. No wasted words.

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

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

With an output schema present and annotations covering the safety profile, the description need not explain return values. It covers sources and the follow-up tool adequately, though it omits any hint about result volume or the format parameter's effect.

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% with both params enum-documented, so the baseline is 3. The description's naming of the sources (ARCSA, Superbancos, SEPS, INEVAL, SGR/Educación Superior, SIPA) gives the agent human-readable meaning for the enum codes, a small value-add, but adds no syntax or format detail.

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 exactly which archives are covered, so an agent knows precisely what it returns. It is clearly distinguishable from sibling listing tools by its institution-archive scope.

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 'Next: get_archivo_seccion(fuente, seccion)' clause establishes the intended two-step workflow, making the usage context clear. However, it gives no explicit when-not or alternative-selection guidance against the many sibling listing 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the temporal scope (years from 1998) but says nothing about auth requirements, pagination, or result size; with annotations carrying the safety burden, 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?

Two short fragments with no filler, and the catalog contents are front-loaded before the routing hint. The first fragment is a bare noun phrase, which is terse to the point of being slightly cryptic, 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?

An output schema exists, so return-value structure need not be explained, and the read-only annotations cover the safety profile. For a zero-required-parameter discovery tool, the description supplies enough to call it and route onward; only the absence of any scope/limit note 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?

There is a single optional `format` parameter with 100% schema description coverage, so the schema already documents the text/json choice fully. The description adds no format syntax or default behavior beyond what the schema states, making the baseline 3 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?

The description enumerates the exact catalog dimensions returned — report types, years (with the 1998 lower bound), and company groups — which tells the agent this is a discovery/enumeration tool rather than one returning report data. It lacks an explicit verb ("Lists..."), relying on the name to supply it, so it is clear but slightly implicit.

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?

"Next: get_arconel_reporte" is a concrete routing instruction that tells the agent this tool is the discovery step preceding get_arconel_reporte, which is the key usage signal. It does not state when NOT to use it or name other alternatives, but the workflow direction is unambiguous.

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 new context — the temporal depth (riesgo país daily since 2004) and the breadth of series — but says nothing about pagination, ordering, or how widgets are keyed for the follow-up call.

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: the resource and its scope lead, the actionable next-step trails. No filler. Minor cost is that the series enumeration, while informative, is fairly dense.

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 an output schema present and read-only annotations, the description need not explain return values, and it adequately covers scope. The gap is the crowded sibling landscape of BCE indicator tools, where the definition does not make the selection boundary explicit.

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

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

The single 'format' parameter has an enum and a complete schema description (100% coverage), so the schema carries the semantics. The description adds no format or syntax guidance, which is the expected baseline when coverage is this high.

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 (BCE daily and monthly indicator widgets) and enumerates the concrete series covered (riesgo país since 2004, gold, WTI, bonds, payments, reserves, fiscal/external). It distinguishes itself from BCEData and points at the sibling get_bce_indicador_diario, so an agent can place it in the BCE family 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?

The 'Next: get_bce_indicador_diario' hint implies the list-then-fetch workflow, which is useful routing. However, it never states when to prefer this over the nearby siblings search_indicadores_bce, get_indicador_bce, or list_sut_indicadores, leaving the choice 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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that results include dataset counts and feed search_datasets, but says nothing about ordering, pagination, or how many categories return, so added behavioral value is modest.

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 that front-loads the resource and then the cross-tool hint, with no wasted words. It is appropriately sized for a simple two-parameter read tool.

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

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

An output schema exists, so return-value explanation is unnecessary, and both params are fully covered by the schema plus annotations. The description covers purpose and the search_datasets linkage; only the absence of sibling disambiguation keeps it short of complete.

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

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

Schema description coverage is 100% and both parameters (format, source) are fully documented with enums and defaults in the schema. The description adds no syntax or format 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 (list) and resource (thematic categories of a CKAN portal), plus a distinguishing detail: dataset counts. However, it does not differentiate itself from the sibling get_category_info, which an agent must infer retrieves details for a single category.

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 clause 'pass a name as search_datasets' category' implies a follow-up workflow, giving useful implied context. But it never says when to prefer this over get_category_info or list_organizations, so usage guidance remains inferential rather than explicit.

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

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

Annotations already cover readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is handled. The description adds content-level context (what data the collection contains, its cadence) but does not address result size, pagination, or freshness beyond 'quarterly.'

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 no filler, and the data scope is front-loaded. The 'Next:' clause is efficient but telegraphic, reading more like a note than polished guidance.

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 an output schema present, return values need not be described, and the description adequately conveys the scope of what is listed. A minor gap remains: no note on whether results are large or how they are ordered.

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

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

Schema description coverage is 100% and the single 'format' parameter is fully documented with its enum. The description adds nothing about parameter meaning, so the baseline of 3 applies since the schema carries the weight.

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 (Contraloría audit reports) and scopes it precisely to 'quarterly CSVs of audit reports approved for any public institution, plus annual control plans.' This is clearly distinct from the sibling get_contraloria_informe, but the description never restates the listing verb explicitly, leaving intent slightly implicit.

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 'Next: get_contraloria_informe' clause implies the list-then-fetch workflow and routes to the sibling. However, it gives no guidance on when to use this list versus other Contraloría-related or Ecuadorian open-data search tools; usage is only loosely 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 non-annotation behavior: that it 'flags name groups that look like periodic series' and lists the returned fields, which helps an agent anticipate output shape and the series-detection behavior.

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

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

Two tight sentences: purpose and returned content first, forward routing second. No filler, and the most decision-relevant information is front-loaded.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. The description is sufficient to invoke correctly; the only modest gap is that it never positions itself against the other dataset-scoped list tools.

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% with two enum parameters (format, source) fully documented in the schema. The description's 'format, size, URL and dates' refers to output fields rather than parameters, so it adds no parameter meaning 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?

The description names a specific verb and resource ('Files (resources) in a CKAN dataset') and enumerates the returned fields (format, size, URL, dates), so an agent can tell it apart from siblings like get_dataset_info or get_resource_info. It doesn't directly contrast with get_dataset_info, which also touches dataset contents, so it is clear but not fully sibling-differentiating.

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 only routing signal is the trailing 'Next: preview_resource_data or query_resource_data,' which points forward in the workflow but does not state when to choose this tool over alternatives such as get_dataset_info. Usage is implied by the forward pointer rather than explicitly conditioned.

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, covering the safety profile. The description adds useful context by disclosing what the listing contains (bulletin/study/report types with years and counts), but says nothing about pagination, ordering, 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 short sentences with the resource description front-loaded and the routing hint trailing. Nothing is wasted, though the 'Next:' fragment is abrupt and could be slightly more explicit.

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

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

An output schema exists, so return-value detail is not required in the description, and the annotations cover safety. Combined with the named follow-up tool, the definition is nearly complete for a zero-required-param lister; only alternative-selection guidance 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 single 'format' parameter is fully documented in the schema with its enum and default. The description adds no parameter-level detail, 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 resource (IESS document collections) and enumerates the content types (statistical bulletins, actuarial studies, audit reports) plus the shape of returned data (years and counts). An agent knows what it lists, but it does not explicitly distinguish itself from sibling listers like list_contraloria_informes.

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?

'Next: get_iess_archivos' supplies a downstream workflow hint, which implies this is the discovery step feeding a file fetcher. However, there is no explicit when-to-use statement, no when-not, and no comparison against alternative collection listers.

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 the useful fact that results carry IDs (enabling chaining to get_institucion_info), but says nothing about pagination behavior or result volume beyond what the schema already 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 tight sentence that front-loads the verb and resource with zero filler. Nothing is repeated from the title or schema and every phrase 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 a full output schema and annotations carrying the safety profile, the description need not explain return values, and it covers the core action plus the ID output. It is nearly complete; only a note on pagination or the list-vs-detail boundary would fully close the 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 all three parameters (page, query, format) are already documented in the schema, including the constraint that page is only used without query. The description adds no syntax or format detail beyond the schema, 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 pair (list/search) and resource (public institutions registered on gob.ec) plus a useful output note ('with their IDs'). It is clear on its own, but it does not differentiate itself from the obvious sibling get_institucion_info (the detail counterpart) or search_organizations.

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 'List or search' phrasing implies that passing a term searches and omitting it lists, so usage is inferable. However, there is no explicit when-to-use guidance, no mention of when to prefer get_institucion_info for a single institution, and no exclusions.

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