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

With no annotations, the description must carry behavioral disclosure, and it does add real context: pagination granularity (15 rows/page, 1..8 pages), session reuse semantics, and the returned fields. It omits auth requirements, rate limits, and any safety/mutation profile, so it is solid but not complete.

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?

Uses a clear Args/Devuelve structure with the purpose sentence front-loaded, and the length is justified by 12 parameters. No filler sentences, though the arg list is dense rather than prose-optimized.

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 12-parameter, no-annotation, no-output-schema tool, the description compensates well by naming the returned row fields and the pagination/session mechanics. Remaining gaps (auth, rate limits, result count limits) are minor for a read-only search.

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

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

Schema coverage is 0%, so the description carries the full parameter burden and mostly succeeds: it marks 'objeto' as OBLIGATORIO, supplies its four allowed values (Bien/Consultoria de Obra/Obra/Servicio), gives dd/mm/aaaa formats for the four date params, and explains pagina/paginas/ses behavior. A few entries (sigla, entidad, tipo) are near-tautological, keeping it from a 5.

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

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

States a specific verb (Busca) and a precisely named resource (ANUNCIOS DE CONTRATACION FUTURA / ACF publicados en el SEACE), so an agent can tell it apart from buscar_procesos at a glance. It does not explicitly name or contrast with the sibling tools, which keeps it just below a 5.

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

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

There is no when-to-use/when-not guidance and no mention of the alternatives in the sibling set (buscar_procesos, buscar_pac, etc.). The only usage-like hint is behavioral (the 'ses' reuse rule), not selection guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses page size (15 rows), the maximum consecutive pages per call (1..8), and the session-reuse semantics of 'ses'. It omits permissions, error behavior, and rate limits, but for a search/read tool the pagination and session behavior are the traits an agent most 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?

Front-loaded with the purpose, then cleanly split into an Args block and a Devuelve block, which is easy to scan. Slightly verbose in the ses and anio explanations, but no wasted sentences.

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

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

There is no output schema, so the explicit list of returned row fields (nro, fecha, entidad, descripcion, tipo, codigo, objeto, id_interno) is appropriately included and completes the picture. Combined with the parameter and pagination details, this is sufficient for a search tool, though the required/optional mismatch on anio is unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: all six parameters (ses, anio, tipo, objeto, pagina, paginas) get meaning beyond the bare schema, including an example year, candidate objeto values, an example tipo, and page sizing. Some parameters (e.g., tipo) are only illustrated rather than enumerated, and it labels anio OBLIGATORIO while the schema marks nothing required.

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 ("Busca CONDICIONES DE CONTRATACION del SEACE") and even expands the CCO acronym (contratos estandarizados de encargos y compras corporativas), so an agent knows exactly what entity is being searched. It does not explicitly differentiate itself from close siblings like buscar_ocos, buscar_acf, or buscar_contratos, which keeps it from 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 useful operating guidance: anio's valid values live in listar_filtros, and it explains that re-searching with different filters reuses the same 'ses' without emitting a new id. However, there is no explicit statement of when to choose this tool over sibling tools such as buscar_ocos or buscar_contratos, so usage is largely 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?

With no annotations, the description carries the full burden and does so well, disclosing the critical non-obvious trait that the API does not paginate and returns the full year (~50k records) without filters, plus the maximo cap of 1..300. It also documents the full return shape and routes the caller onward via id_documento to url_documento_contrato.

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?

Front-loads the purpose and the pagination warning before the argument list and return shape, and every line of the Args/Devuelve blocks is load-bearing given 15 undocumented parameters. It is long, but the length is justified rather than padded.

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

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

For a 15-parameter, filter-heavy search tool with no output schema and no annotations, the description covers purpose, mandatory filtering behavior, all parameter semantics, and the return structure, including the cross-tool handoff for id_documento. Nothing essential an agent needs before calling it 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 0%, so the description must compensate, and it does: every one of the 15 parameters gets meaning, including enum semantics for 'objeto' (0/62/63/64/65), date format hints (dd/mm/aaaa) for desde/hasta, format examples ('LP-SM-13-2025-SEDAPAL-1'), and how to source cod_seleccion. This is far beyond the bare schema.

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

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

States a specific verb and resource ('Busca CONTRATOS PUBLICADOS en la API de contratos del SEACE'), so the agent knows it searches published contracts. However it does not explicitly differentiate itself from close siblings like detalles_contratos, detalle_contrato, or contratos_expediente; that separation is only implied.

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 strong operational context: the API does not paginate, an unfiltered call returns ~50k records, and a narrowing filter should always be passed, with 'texto' flagged as most effective. It also points to listar_filtros(categoria='tipos_contrato') for cod_seleccion values. It lacks explicit when-to-use-vs-alternative sibling routing, so it falls 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?

With no annotations, the description carries the full burden and adds real context: the 'ses' is a GLOBAL session shared across tools, and omitting it opens a temporary one. The return shape is also disclosed. It stops short of stating read-only/auth/rate-limit behavior, but for a lookup tool this is substantially informative.

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?

Front-loaded purpose sentence, then a compact Args/Devuelve structure. Every line earns its place, and the crucial session semantics and return shape are conveyed without 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?

With no output schema and no annotations, the description steps in to document the return dict ({ok, ses, total, filas:[...]}) and how to consume it. Nothing an agent needs to call this correctly or chain it 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 0%, yet the description compensates fully for all four params: nombre (with an example), ruc (exactly 11 digits), sigla, and ses (shared/global, temporary if omitted). Each parameter gains meaning richer than the bare schema types.

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

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

States a specific verb (Busca), a precise resource (ENTIDADES del Estado peruano), the source (buscador SEACE), and the search keys (nombre, RUC o sigla). This is unmistakably distinct from siblings like buscar_procesos or buscar_ocos, which target different SEACE resources.

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

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

Explicitly routes the agent downstream: use the returned 'ruc' for buscar_ocos and the exact name for buscar_procesos(entidad=...). It does not state when to prefer this tool over alternatives or prerequisites, so it stops short of a full when/when-not spec.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses pagination limits (15 rows/page, 1..8 pages per call), the global continuous 'index', session reuse semantics for follow-up calls, and notably what the source does NOT return (no publication date or amount per row). It does not cover permissions or rate limits, but the disclosed behavior is substantive.

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?

Purpose is front-loaded in one line, followed by clearly delimited Args and Devuelve sections. For a 10-parameter tool this is appropriately sized, with no filler sentences, though the prose is dense and could be slightly tighter.

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

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

There is no output schema, so the Devuelve section correctly documents the returned row shape (index, nro, entidad, numero, descripcion, id_interno) plus the fields deliberately absent. Combined with per-parameter docs and pagination/session semantics, the definition is largely self-sufficient, with the required-vs-optional ambiguity and missing sibling routing the only real gaps.

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

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

Schema coverage is 0%, so the description must compensate, and it documents all 10 parameters with formats and ranges: objeto value list (Bien/Consultoria de Obra/Obra/Servicio), date format dd/mm/aaaa, page size, and page-count bounds. However, it labels objeto as 'OBLIGATORIO' while the schema declares zero required parameters and a null default, creating a minor consistency ambiguity.

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 opening line states a specific verb and resource: 'Busca EXPRESIONES DE INTERES (EI) publicadas en el SEACE'. The resource (expresiones de interés) is clearly distinct from siblings such as buscar_procesos, buscar_requerimientos, and buscar_contratos, so an agent can route correctly 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?

Usage is only implied by the tool name and the parameter set; there is no explicit statement of when to pick this tool over buscar_acf, buscar_requerimientos, etc., nor any when-not guidance. The 'ses' explanation does document continuation/re-search behavior, which is useful context but not selection guidance.

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

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

With no annotations, the description carries the full behavioral burden and does substantial work: it discloses pagination (15 filas por pagina), a batch range (paginas 1..8), and non-obvious session semantics (a prior 'ses' enables 'siguiente_pagina', differing filters re-execute while reusing the same ses, no new id is emitted). It omits permission/auth context and does not explicitly declare read-only, keeping it below 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?

Front-loads purpose then organizes details into Args and Devuelve sections, with each param line earning its place given 0% schema coverage. Slightly verbose but appropriately sized for a 7-param tool with no structured documentation.

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?

Although there is no output schema, the Devuelve section enumerates the returned fields (nro, entidad, tipo_orden, numero, objeto_descripcion, fecha_ini, fecha_fin, monto, ruc, entidad_rap, situacion, plazo), and all params are explained. The missing auth/permission behavior and the schema's silent required=0 versus the description's OBLIGATORIO leave a small gap.

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

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

Schema coverage is 0%, so the description must compensate, and it documents all 7 params with formats and examples (anio '2026', mes '9' or 'setiembre', ruc entidad-o-contratista, entidad 'nombre exacto', pagina row count, paginas 1..8). It also flags anio/mes/ruc as OBLIGATORIO, which conflicts with the schema's all-optional required=0 — a mismatch that prevents a top score.

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

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

States a specific verb (Busca) plus the exact resource (ORDENES DE COMPRA Y ORDENES DE SERVICIO, OC/OS) and its source registry (SEACE). This clearly distinguishes it from siblings like buscar_contratos, buscar_procesos, and buscar_requerimientos 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?

Usage context is implied rather than stated, but there is one useful routing hint — 'ruc... hallalo con buscar_entidades' tells the agent where to obtain a required value. There is no explicit when-to-use/when-not guidance versus buscar_contratos or buscar_cco, so it stops short of the 4-5 tier.

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

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

With no annotations the description carries the full behavioral burden, and it does disclose useful traits: the data is public, the required-entity constraint, and the exact shape of each row (entidad, ubigeo, última versión, cantidad de procesos, valor en Soles). What it omits is operational detail such as read-only/safety confirmation, result limits, or pagination.

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?

Front-loaded with purpose, then cleanly separated Args and Devuelve sections; each sentence earns its place, including the detalle_pac pointer. Slightly verbose in the return dict enumeration, but no genuine 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 two-param search tool with no output schema and no annotations, describing the return dict and the required-entity constraint is appropriately thorough. The remaining gap is the absence of any hint about result volume/pagination for a search that can return many rows.

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

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

Schema description coverage is 0%, so the description must compensate and it does: entidad is 'nombre o parte del nombre' with the example 'SEDAPAL' plus the reason it is required, and año carries an example ('2026') plus the valid catalog range 2019..2026. Both parameters are fully documented beyond the bare schema types.

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

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

States a specific verb (Busca) plus a precisely scoped resource: PAC (planes anuales de contrataciones) públicos del SEACE, filtered por entidad y año. It also enumerates the returned per-row fields and names the drill-down sibling (detalle_pac), so an agent can separate it from buscar_acf, buscar_contratos, or detalle_pac without opening another schema.

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

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

Explains the operational constraint that drives usage (the PAC searcher obliga a elegir institución o ubigeo, hence entidad is required) and points to detalle_pac for the process listing. It lacks explicit when-not guidance versus other search siblings like buscar_acf or buscar_procesos, 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?

With no annotations, the description carries the full burden and does so well: it discloses server-side filtering, the session-continuity model (same 'ses' reuses the search, no new id emitted), pagination mechanics (15 rows/page, globally continuous index), and the sentinel values for unpublished amounts ('Reservado' / '---'). It even flags that 'campos' holds the raw JS row.

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?

Front-loaded with purpose, then session policy, then a parameter list, then the return shape — a logical order for a 16-parameter tool. It is dense and lengthy, but nearly every line is load-bearing given 0% schema coverage; minor redundancy in the per-parameter examples keeps it from a 5.

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

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

For a 16-param, no-annotation, no-output-schema tool, the description supplies purpose, session/pagination behavior, all parameter semantics, and an explicit return-field listing (including how 'index' feeds ficha_proceso). Nothing essential for correct invocation appears to be 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 0%, so the description must compensate, and it documents all 16 parameters with meaning and examples (e.g. 'anio' obligatory on first call, 'version' sends '3', 'objeto' enumerates Bien/Consultoria de Obra/Obra/Servicio, 'paginas' bounded 1..8, 'ses' semantics). This goes well beyond the bare schema and resolves several ambiguities.

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 ("Busca PROCESOS DE SELECCION en el Buscador Publico del SEACE") and gives concrete examples of the record types returned (licitaciones, adjudicaciones abreviadas, comparaciones de precios). This clearly distinguishes it from siblings like buscar_contratos, buscar_entidades or ficha_proceso.

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 explicit operational guidance: the session policy tells the agent to re-call with the same 'ses' and 'pagina' to continue pagination, and that differing filters start a new search. It also points to listar_filtros for valid 'tipo' values and to ficha_proceso for the row indexes. It lacks explicit "when not to use this vs. sibling X" exclusions, 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?

No annotations are provided, so the description carries the burden: it discloses pagination behavior ('15 filas por pagina'), the paginas limit (1..8), session reuse semantics via 'ses', and explicit return fields plus limitations ('no expone fecha de publicacion ni monto por fila'). It does not cover auth/rate-limit behavior, but for a read-oriented search tool this is strong disclosure.

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 front-loaded with the purpose sentence, then organized into Args and Devuelve sections. Despite length, every line earns its place by documenting parameters, pagination, and return fields for a 10-parameter 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?

With 10 parameters, 0% schema description coverage, no annotations, and no output schema, the description must be self-sufficient. It documents arguments, return columns, pagination, session reuse, and known limitations, leaving nothing critical unexplained for calling the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents all 10 parameters including objeto as OBLIGATORIO with four enum values, fecha format dd/mm/aaaa, pagination details, and the special 'ses' session mechanism. This adds substantial meaning beyond the bare schema.

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

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

The description states a specific verb and resource: 'Busca en la DIFUSION DE REQUERIMIENTOS del SEACE (bienes y servicios que las entidades requeriran)'. This clearly scopes the tool to public procurement requirement announcements, distinguishing it by resource from siblings like buscar_procesos or buscar_contratos, but it does not explicitly name those alternatives.

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 lists arguments and return fields but never says when to use this tool versus sibling search tools, nor when not to use it. Usage is only implied from the purpose statement and parameter list.

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

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

With no annotations, the description carries the full burden and does well: it discloses the conditional id requirement (OBLIGATORIO with 'provi'/'distri'), the accepted nivel values, and the exact return shape including 'nota'. It never states auth or rate-limit behavior, but for a read-only catalog lookup that is a minor gap.

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

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

Front-loaded with the resource description, then organized under clear Args/Devuelve sections. Efficient overall, though the parenthetical cross-references could be trimmed slightly.

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

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

No output schema exists, yet the description documents the return dict shape ({'ok','nivel','catalogo':[{codigo,nombre}],'nota'}) and explains how the returned 'codigo' feeds other tools. For a 2-parameter catalog tool this leaves nothing an agent needs 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 0%, so the description must compensate entirely, and it does: it enumerates the three 'nivel' values with their distinct semantics and explains 'id' as the parent-level code with concrete examples ('19' Pasco, '2503') and its conditional obligation.

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 (the SEACE geographic catalog) and enumerates exactly what it contains: departamentos, provincias y distritos. It also names the downstream consumers (buscar_contratos, resumen_georef), which cleanly separates it from every sibling in the list.

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?

Makes the use case explicit: it fills 'depa' in buscar_contratos and resumen_georef, and it spells out the conditional requirement of 'id' for 'provi' and 'distri'. It does not name an explicit alternative tool for the same job, 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?

With no annotations, the description carries the burden and does well: it discloses the return shape ({'ok','ses','index','filas'}) and the key edge case that 'filas' is empty when the process publishes no CUI ('Sin informacion'). It does not explain failure behavior when 'ses' is expired or 'index' is out of range.

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?

Front-loaded with purpose, then clearly separated Args and Devuelve sections with zero filler. Every line carries information an agent needs to chain or interpret the call.

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, no-output-schema tool, the description supplies the dependency relationship, the parameter meaning, and the return-structure plus empty-case semantics. Nothing essential for correct invocation or result interpretation 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 0%, so the description must compensate, and it does: 'ses' is defined as the session from buscar_procesos and 'index' as the global 0-based row index of that search. This is exactly the chaining context the bare schema lacks, though neither param's type/validation or out-of-range behavior is detailed.

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 ('CODIGOS SNIP/CUI') and verb ('Leyendo') and ties it to the popup 'Codigos' of the buscador, so an agent knows exactly what is fetched. It implicitly distinguishes itself from siblings by depending on buscar_procesos output, though it never explicitly contrasts with ficha_proceso or detalles_contratos.

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 makes the workflow clear: 'ses' must be the session returned by buscar_procesos and 'index' is the row index from that search, which tells the agent when this tool applies. There are no explicit exclusions or named alternatives (e.g., use ficha_proceso for full detail), 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?

With no annotations, the description carries the full burden, and it does disclose two useful behavioral facts: only published contracts are returned, and the response is a list envelope containing 'total' plus per-contract objects. It omits auth needs, rate limits, pagination for large expedientes, and error behavior, which keeps it below 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?

Front-loaded purpose followed by clearly labeled Args and Devuelve sections, so an agent can parse it at a glance. It is slightly longer than strictly necessary but every block (input source, return shape, next step) carries information not available elsewhere.

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?

Since there is no output schema and no annotations, the description supplies the return shape ({'ok','id_expediente','total','contratos':[...]}) and routing to detalle_contrato, which makes it callable as-is. It lacks any note about result volume/pagination for expedientes with many contracts, a minor gap for a list endpoint.

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

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

Schema coverage is 0% and the only schema text is a title, so the description must compensate, and it does: it defines the parameter's source ('id_expediente' de buscar_contratos) and gives a concrete example value ('1171246'). It does not describe format validity/type beyond the example.

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 ('Todos los CONTRATOS publicados de un expediente de seleccion') and states the scope constraint ('todos'/'publicados'). It also implicitly separates itself from siblings by naming buscar_contratos as the id source and detalle_contrato as the per-contract follow-up.

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 tells the agent where to get the required id ('id_expediente' de buscar_contratos) and what to call next with the returned 'id_contrato' (detalle_contrato), giving a clear data-flow context. It does not state when NOT to use this tool versus broader contract searches, so it stops short of full when/when-not guidance.

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

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

Since there are no annotations, the description provides comprehensive behavioral transparency. Specifically, it states that the URLs provided in the output are 'descarga directa del PDF (sin token),' which is a critical operational detail for the agent.

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

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

Although detailed, the structure (using 'Args:' and 'Devuelve:') is highly efficient. Every sentence adds specific value regarding scope, prerequisites, or expected output structure, justifying the length.

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 definition is maximally complete. It details the scope of the input, lists nearly every nested resource the tool retrieves (disputes, actions, guarantees), and explicitly defines the structure and behavior of the complex return data.

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

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

Schema coverage is 0%, so the description must compensate. It successfully clarifies that `id_contrato` is a specific reference to a published contract and provides a concrete example ID format, greatly improving parameter understanding.

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 purpose is extremely clear: to provide the 'Detalle COMPLETO' of a published contract. It specifies the resource type (contract) and the scope of the detail, clearly differentiating it from simpler list/search tools listed in the siblings.

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

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

The description provides specific guidance on how to acquire the necessary input parameter (`id_contrato`), stating that it should come from `buscar_contratos` or `contratos_expediente`, which is invaluable for routing and prerequisite knowledge.

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

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

With no annotations, the description carries the full burden and does disclose the return shape and semantics: ok/url/cabecera/item/acciones and the meaning of each action (convocatoria publication, adjudicado, contrato, etc.). It omits error behavior, permissions, and rate limits, but the critical 'what you get' behavior for this read operation is covered.

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?

Purpose is front-loaded, then structured Args and Devuelve sections. Dense but no filler; the return-value spec is a slightly run-on nested literal but remains parseable.

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

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

For a 3-parameter tool with 0% schema coverage and no output schema, the description supplies both parameter provenance and a full return-value breakdown, which is what an agent needs. The remaining gap (error/edge-case handling) is minor.

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

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

Schema description coverage is 0%, yet the description fully compensates: 'ses' is sourced from buscar_procesos, 'index' is the 0-based global row index, and 'nro_item' is the 1-based ordinal within ficha_proceso items. The explicit 0-based vs 1-based distinction is exactly the kind of detail that prevents off-by-one invocation errors.

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 opening 'ACCIONES REALIZADAS POR ITEM de un proceso' states a specific verb+resource: it returns the action lifecycle of a single procurement item. This is distinguishable from siblings like historial_proceso (process-level history) and ficha_proceso (item listing), though the description never names a sibling explicitly to sharpen the contrast.

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 documents the prerequisite chain: 'ses' comes from buscar_procesos and 'nro_item' derives from the 'items' order in ficha_proceso, so an agent knows it must call those tools first. However, it gives no explicit when-not-to-use guidance or direct alternative comparison.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It does reveal the return payload ('ok', 'ses', 'procesos' with fields) and implies a read-only lookup, but says nothing about permissions, rate limits, or failure modes for an entity/year with no PAC.

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?

Well front-loaded: the purpose line comes first, then Args and Devuelve sections. Slightly verbose in the header, but every section earns its place with no filler.

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

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

For a 3-parameter tool with no output schema, the description supplies both the parameter workflow and the return structure, which is what an agent needs to call it correctly. Only the behavioral/side-effect profile is thin.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: 'entidad' is tied to buscar_pac semantics, 'index' is explained as a 0-based row from buscar_pac's result (normally 0), and 'anio' is identified. This adds real meaning beyond the bare schema titles.

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

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

The description opens with a specific verb+resource in caps ('LISTADO DE PROCESOS PROGRAMADOS del PAC') and clarifies it searches the PAC by entity/year and pulls the detail. It distinguishes itself from buscar_pac by describing the index parameter as a row from that sibling's result, though it never states outright how the two tools differ in purpose.

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

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

Usage is implied through the workflow: 'index: fila del resultado de buscar_pac', meaning this tool is meant to run after buscar_pac. No explicit when-to-use/when-not guidance or mention of alternatives other than the implicit chaining.

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

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

With no annotations, the description carries the full burden and does well: it discloses the 10-item cap, deduplication of duplicate ids, partial-failure semantics (non-numeric ids routed to 'faltas' while the rest still process), and per-element 'ok' flags. It does not mention auth/permission needs or rate limiting, so it is not fully exhaustive.

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?

Uses an Args/Devuelve structure that is front-loaded with the core purpose. Slightly verbose in the returns block, but nearly every clause (cap, dedupe, faltas routing) carries information an agent needs.

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

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

There is no output schema, so documenting the return shape is necessary and done here (detalles/faltas/nota with per-element ok). Combined with parameter and failure-mode coverage, the definition is close to complete, though it omits auth/permission preconditions.

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

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

Schema coverage is 0%, so the description must compensate, and it does: 'ids' is explained as a list of numeric id_contrato values with duplicate handling and a cap, and 'maximo' is bounded to 1..10. Both of the two parameters gain meaning beyond the bare JSON 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 operation – batch-fetching contract details in one call – and explicitly contrasts it with the sibling 'detalle_contrato' (avoids repeating it per id). An agent can distinguish this from 'detalle_contrato' and 'buscar_contratos' without opening a schema.

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

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

Gives an explicit alternative and the condition for choosing it: 'usa detalle_contrato si solo necesitas uno'. It also states the call cap (10 per call) and that duplicates are processed once, which are usage-shaping constraints, not just description.

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

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

With no annotations, the description carries the full burden and does so well: it documents the return shape, flags that cabecera fields are optional, notes an edge case (emergency processes or unpublised items yield empty 'items'), and routes the agent to url_documento for signed PDF URLs. It omits permission/auth requirements, but the behavioral picture for this read operation is largely complete.

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?

Purpose is front-loaded in the first line, followed by clearly labeled Args and Devuelve sections. The return documentation is dense and long, but justified because no output schema exists and the structure is genuinely complex.

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

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

For a tool with an undocumented schema, no output schema, and no annotations, the description supplies the workflow prerequisite, both parameter meanings, the full return structure, an edge case, and a follow-up tool link. Only auth/permission context is missing, which is minor for this retrieval tool.

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

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

Schema description coverage is 0%, so the description must compensate and does: 'ses' is defined as the session from buscar_procesos, and 'index' as the 0-based index of that search's row. Both parameters gain meaning not present in the bare schema.

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

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

States a specific verb+resource: the selection record ('ficha de seleccion') of a SEACE process, enumerating its components (cabecera, items, cronograma, documentos). This clearly tells an agent what it gets. However, it does not explicitly differentiate from close siblings like fichas_procesos, historial_proceso, or detalle_item, so an agent must infer 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 Args section implies the workflow: 'ses' is the session returned by buscar_procesos and 'index' is the row index from that search, effectively stating a prerequisite. But there is no explicit when-to-use vs alternatives guidance against the many sibling lookup tools. Usage is implied rather than prescribed.

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

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

With no annotations the description carries the full burden, and it delivers real behavioral context: caps of 50 (resumen) / 8 (completa), duplicate indices processed once, and partial-failure semantics (failed indices in 'faltas' with motivo while the rest are returned). It does not discuss permissions or rate limits, which is the only gap.

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

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

Front-loaded purpose sentence followed by tightly organized Args and Devuelve blocks. No filler; every clause carries operational information (caps, dedup, fallback routing).

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

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

There is no output schema, so the description correctly outlines the return keys ('ok', 'ses', 'profundidad', 'fichas', 'faltas', 'nota') and the partial-failure model. It stops short of explaining the 'ok'/'nota' fields, a minor omission for a 3-param tool at this complexity.

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

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

Schema description coverage is 0%, so the description must compensate and does: it defines 'ses' (session returned by buscar_procesos), 'indices' (global 0-based indices, dedup behavior, size caps), and 'profundidad' (values 'resumen'/'completa' and exactly what each yields). Every parameter gets meaning beyond its bare type.

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 action and scope: batch-retrieve fichas/resúmenes for the SAME search in one call, explicitly framed as avoiding repeated ficha_proceso calls. It makes the distinction from the ficha_proceso sibling explicit, and the dependency on a session from buscar_procesos is named.

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 when (batch over one search to avoid repeated per-index calls) and the when-not ("usa ficha_proceso individual si solo necesitas una"). The routing is explicit and actionable, so the agent can choose between the two tools without inference.

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

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

With no annotations, the description carries the behavioral burden and does disclose the return shape and that ses is a prior session. It does not state read-only semantics explicitly, nor error behavior for invalid ses/index. The return-value disclosure is the main added value beyond the token nature of params.

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?

Structured with clear Args and Devuelve sections; front-loaded description of the resource followed by parameter and return documentation. No filler, though slightly verbose in the header line.

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

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

With no output schema, the description supplies the return structure (ok, url, cabecera, historial), which an agent needs. Both required params are explained, leaving only edge-case behavior undocumented.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it defines ses as the session returned by buscar_procesos and index as the 0-based global row index from that search. This meaningfully documents both parameters beyond the bare schema titles.

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 ('HISTORIAL DE CONTRATACIONES del proceso') and clarifies it returns each convocatoria with its etapa and estado. It associates itself with buscar_procesos through the ses/index dependency, aiding differentiation, though it does not explicitly contrast with siblings like ficha_proceso.

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 on buscar_procesos (ses returned by it, index from its search rows) implies the workflow context of when to call it. However, there is no explicit when-not-to-use guidance or named alternative for retrieving per-process data.

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

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

With no annotations, the description carries the full load and does well: it discloses that ses is GLOBAL and shared across tools, that omitting it opens a temporary page, and that the CCO searcher only exposes recent years (2024-2026). Missing only things like rate limits or 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?

Purpose is front-loaded in one line, followed by clearly labeled Args and Devuelve sections. It is somewhat long but every section (categoria values, return shape, CCO year caveat) contributes actionable 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?

No output schema exists, so the description responsibly spells out the return shape ({'ok', 'combos'...} and the 'codigos' variant). With no annotations it also covers the key behavioral facts, leaving it 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 coverage is 0%, so the description must compensate, and it does: it enumerates all accepted 'categoria' values and explains the role of 'ses' as an optional cached-session handle. This adds substantial meaning beyond the bare undtyped properties.

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

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

States a concrete verb+resource: it returns the exact values of the SEACE search-engine combos and the JSON contracts API catalogs. An agent can tell this is a reference/lookup tool rather than one of the many buscar_* search siblings, though it does not name a specific sibling it competes with.

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 ties 'tipos_contrato' explicitly to buscar_contratos via the 'codSeleccion' value, making the downstream use case clear. It also explains the 'ses' reuse for a previous search. It stops short of stating when NOT to use it, so it is clear context rather than full routing 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?

No annotations are provided, so the description carries the burden, and it does disclose meaningful behavior: the 'objeto' drill-down does not paginate and is truncated to the first 100 contracts ('mostrados'). It also describes the return shape for both modes. It stops short of stating auth/permission requirements, which keeps it below 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?

Structured into a purpose sentence plus Args/Devuelve blocks, and the key mode distinction is front-loaded. Slightly verbose, but each section (params, return shape, truncation limit) earns its place since there is no output schema.

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

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

For a 3-param tool with no annotations and no output schema, the description covers both modes, all parameter values, the return payload keys, the 100-record cap, and the fallback tool. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0%, yet the description documents every parameter with examples and derivations: anio format ('2026'), depa as a catalogo_ubigeo code ('19' Pasco), and objeto as an object-type code with the full value set ('62' Bien, '63' Consultoria, '64' Obra, '65' Servicio). This fully compensates for the schema gap.

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

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

States a specific resource and scope: a georeferenced summary of published contracts for one department and year, and explicitly distinguishes two operating modes (no 'objeto' = counts/amounts by object type; with 'objeto' = drill-down list). This is precise enough to separate it from siblings like buscar_contratos and detalle_contrato.

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?

Tells the agent exactly when to add 'objeto' (drill-down) and when not to (aggregate summary), names detalle_contrato for the contract sheet, and routes overflow to buscar_contratos with depa+objeto. Alternatives and their triggering conditions are 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?

With no annotations, the description carries the full burden. It discloses the return shape ({'ok','tipos':[{codSeleccion, descSeleccion}]}), which is useful, but says nothing about read-only nature, caching, or any other behavioral trait. Adequate but thin for an unannotated tool.

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

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

Structured with clear Args and Devuelve sections, front-loaded with the tool's identity. Every line is relevant; only the mixed Spanish/English drift adds minor noise.

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

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

For a one-parameter catalog tool with no output schema and no annotations, the description supplies both the input meaning and the return structure, plus the link to buscar_contratos. Reasonably complete for its complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the single parameter 'anio' as the year of the catalog with an example ('2026'), adding real meaning beyond the bare string schema and its default.

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

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

The description states a specific resource: the exact catalog of selection types from the contracts JSON API ('Catalogo EXACTO de tipos de seleccion'). It's clear what the tool returns, though it doesn't explicitly contrast itself with sibling catalog tools like listar_filtros or catalogo_ubigeo.

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: by noting that 'codSeleccion' is the value of 'cod_seleccion' in buscar_contratos, it hints the catalog is meant to feed valid codes into that sibling. There is no explicit 'when to use this vs alternatives' or 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?

With no annotations provided, the description carries the full behavioral burden and does so well: it says the URL is signed on the fly, has short validity, the server does not download the file, and distinguishes timeout behavior for a nonexistent uuid from instant rejection of a malformed uuid.

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 front-loaded with the purpose, then cleanly separated into Args and Devuelve sections. Every sentence adds useful information, including the non-obvious timeout and no-download behavior.

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

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

For a one-parameter read tool with no annotations and no output schema, the description provides everything needed: parameter source, return keys, URL validity, no file download, and error-case 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 0%, but the description fully compensates for the single parameter: it explains that uuid is the document uuid listed in ficha_proceso and gives a concrete example UUID.

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: it returns a signed URL for downloading a SEACE process document, with examples such as integrated bases. This clearly distinguishes it from sibling tools like url_documento_contrato, which handles contract documents.

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 tells the agent where the uuid comes from: the document listed in ficha_proceso. However, it does not explicitly compare itself with the sibling url_documento_contrato or state when not to use this tool.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the return is a direct GET of the PDF and that the server does not persist it, but it says nothing about authentication, rate limits, or error/invalid-id behavior, which is notable for an API-backed lookup with zero annotation coverage.

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 short and front-loaded with the purpose, then uses labeled Args and Devuelve sections to structure the remaining content. Every part is relevant, with no padding 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?

For a single-parameter lookup with no output schema, the description is nearly complete: it explains the input's origin and example and describes the return shape {'ok','url','nota'}. The main omission is the relationship to the sibling url_documento, which would help disambiguation.

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

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

Schema description coverage is 0% and the schema only names the field 'Id Documento', so the description must compensate. It does so reasonably well by identifying the parameter as the contract's idDocumentoContrato and giving a concrete example value ('153203160'), adding real meaning beyond the schema.

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

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

The description states a specific verb and resource: returning the download URL for a CONTRACT document from the SEACE JSON API, with the resource scoped to contracts. It is clear what the tool produces, though it does not explicitly distinguish itself from the sibling url_documento, leaving the contract-vs-generic-document distinction 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?

There is no guidance on when to use this tool versus the near-identical sibling url_documento, nor any stated prerequisites or sequencing. The agent must infer usage purely from the name and the 'documento de un CONTRATO' phrasing.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return shape ({'ok','url'}) and that the result is a public page, which is genuinely useful, but it says nothing about failure behavior for an invalid or unknown RUC, whether the URL is verified to exist, or whether any lookup/network call occurs.

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 front-loaded sentence delivers the core purpose immediately, and the Args/Devuelve structure is compact with no filler. Formatting is slightly fragmented but every line carries information.

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

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

For a single-parameter, no-annotation tool, the description covers the what, the argument, and the return shape, which is adequate. It omits error/edge-case behavior for unresolvable RUCs and does not anchor the tool relative to its many sibling URL builders, leaving the agent to infer selection.

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

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

Schema description coverage is 0%, so the description must compensate: it clarifies that the 'ruc' argument belongs to a proveedor or consorcio, which the bare schema does not. However, it gives no format, length, or validity constraints (e.g., 11-digit RUC), so the gap is only partially filled.

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 outcome (the provider's public profile URL on the OECE 'perfilprov' portal) and the input it derives it from, so an agent knows exactly what it gets. It does not distinguish itself from the similar URL-building siblings such as url_documento or url_documento_contrato, which keeps it below a 5.

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

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

There is no explicit statement of when to choose this tool over the sibling URL constructors, nor any prerequisite or exclusion. The closest it comes is naming the domain entity (proveedor/consorcio), which only implies the use case.

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