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 value: pagination semantics (15 rows per page, 'index' global and continuous) and session reuse behavior (re-searching with different filters keeps the same 'ses' without emitting a new id). It says nothing about authentication, rate limits, or error conditions, and read-only nature is only implied by 'Busca'.

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 purpose sentence is front-loaded, then Args and Devuelve are cleanly separated, and each parameter line carries distinct information. It is dense but appropriate for a 12-parameter tool with no schema descriptions.

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-param tool with 0% schema coverage, no annotations and no output schema, the description covers parameters, pagination, session behavior, and even enumerates return fields (entidad, fecha_publicacion, tipo, objeto, descripcion, condiciones, nro_items, plazo_dias, fecha_aprox_conv). Only tool-selection guidance against siblings 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 is the only documentation, and it defines all 12 parameters: objeto with its four allowed values, tipo, entidad, sigla, descripcion, the four date filters with the dd/mm/aaaa format, pagina (15 rows/page), paginas (range 1..8), and ses (session semantics). This fully compensates for the empty 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: search future contracting announcements (ACF) published by entities in SEACE, with the acronym expanded. It does not explicitly contrast itself with the many sibling search tools (buscar_procesos, buscar_pac, buscar_ocos), though the reference to buscar_procesos for return format implies a family relationship.

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-to-use guidance and no named alternative for ACF-specific queries versus buscar_procesos or buscar_pac. The only usage signal is that 'objeto' is flagged OBLIGATORIO, which is a parameter constraint rather than tool-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. It does disclose useful traits: pagination size (15 rows/page), the 1..8 page batching limit, and the session semantics where a re-search keeps the same 'ses' without emitting a new id. It never states read-only vs mutating behavior, auth requirements, or rate limits, so a mutation-safety signal is absent.

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 separated Args and Devuelve sections; each line earns its place. Slightly verbose but well organized and scannable.

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 'Devuelve' block correctly enumerates the returned fields (nro, fecha, entidad, descripcion, tipo, codigo, objeto, id_interno). Purpose, parameters, and return shape are all covered. The only gap is the required-vs-optional discrepancy on 'anio' and the absence of any safety/permission note.

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 largely does: it defines anio format and value source, lists the objeto options (Bien / Consultoria de Obra / Obra / Servicio), gives tipo examples, and explains pagina/paginas/ses semantics. One flaw: it labels anio OBLIGATORIO while the schema marks it optional with default null, a mild mismatch that could mislead. Overall strong compensation for the empty 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: searching SEACE 'CONDICIONES DE CONTRATACION', with an inline gloss defining the acronym (contratos estandarizados de encargos y compras corporativas). This is clearly distinguishable from generic siblings like buscar_contratos or buscar_procesos. However, it never explicitly contrasts itself with those siblings, so an agent still has to infer which search tool to pick.

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

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

Usage is only implied. It points to listar_filtros as the source of valid 'anio' values and explains the 'ses' reuse path for paging or re-querying, which gives some operational context. But there is no explicit when-to-use-this vs buscar_contratos/buscar_ocos, and no statement of 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?

With no annotations, the description carries the full burden and does well: it discloses the non-pagination gotcha, the ~50k-row default volume, server-side filtering, and the row cap (1..300). It stops short of auth requirements, rate limits, or error behavior, so it is strong 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?

The critical warning is front-loaded in caps, followed by clean Args and Devuelve sections. It is long, but the length is justified by 15 undocumented parameters and the absence of an output schema; little is redundant.

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

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

For a 15-parameter tool with no annotations and no output schema, the definition covers parameters, return shape, volume/pagination behavior, and cross-tool routing. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 0% and the description compensates fully, documenting all 15 parameters: required 'anio', the effectiveness ranking of 'texto', name-or-RUC semantics for entidad/proveedor, the objeto code map ('62' Bien, '63' Consultoria, '64' Obra, '65' Servicio), 'depa' '0'=todos, dd/mm/aaaa date formats, and the maximo 1..300 bound.

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 with scope: 'Busca CONTRATOS PUBLICADOS en la API de contratos del SEACE.' An agent can tell this is a search tool for published contracts, distinct from detail-oriented siblings like detalle_contrato or detalles_contratos, though those siblings are not named explicitly.

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

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

Gives clear operating context: the API does not paginate and unfiltered calls return the whole year (~50k records), so a narrowing filter should ALWAYS be passed, with 'texto' flagged as most effective. It also routes to sibling tools (listar_filtros for cod_seleccion, url_documento_contrato for id_documento), but does not state when to prefer whole-tool alternatives like buscar_procesos.

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 usefully discloses the session model ('GLOBAL y compartida entre tools; si se omite se abre una temporal') and the exact return shape, but says nothing about it being a read-only network call, error behaviour, or rate limits.

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

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

Front-loaded purpose sentence followed by clearly labelled Args and Devuelve sections; each parameter line earns its place. Slightly verbose in the ses parenthetical but overall efficient.

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

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

With no output schema, the description supplies the return contract ('ok', 'ses', 'total', 'filas': [{index, ruc, tipo_documento, nombre}]) and how to consume it downstream, so an agent has everything needed to call and chain this tool.

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

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

Schema coverage is 0%, so the description must compensate, and it documents all four parameters: nombre with an example ('SEDAPAL'), ruc as an exact 11-digit value, sigla, and ses as an optional shared previous session. It adds real meaning over the bare schema, though it does not clarify matching semantics (partial vs exact) for nombre/sigla.

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 resource (ENTIDADES del Estado peruano) plus the search axis (nombre, RUC o sigla) and the source (buscador SEACE). It clearly distinguishes itself from data tools like buscar_ocos/buscar_procesos by being the entry point that yields the RUC those siblings consume.

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 downstream: 'Usa el ruc para buscar_ocos y el nombre exacto para buscar_procesos(entidad=...)', which tells the agent how this fits the workflow. It stops short of stating when-not to use it (e.g. when you already know the entidad), so it is clear context without exclusions.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: 15 rows per page, global continuous 'index', a 1..8 range for multi-page fetches, and the session rule that re-filtering re-executes the search while keeping the same 'ses' without emitting a new id. It also warns what the EI search does NOT return (no publication date or amount per row). Missing: read-only/auth expectations, though 'Busca' strongly implies a read.

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 structured with Args and Devuelve sections, purpose front-loaded in the first line, and one line per parameter. The 'ses' explanation is slightly dense but earns its space given the non-obvious session 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 10-parameter tool with no annotations and no output schema, the description covers purpose, every parameter, pagination, session reuse, and the returned row shape including id_interno. It even flags absent fields, so an agent knows not to expect dates or amounts per row.

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 entirely, and it documents all ten parameters: enumerated objeto values (Bien / Consultoria de Obra / Obra / Servicio), date format dd/mm/aaaa for desde/hasta, page size, the 1..8 range for 'paginas', and the 'ses' continuation semantics. Minor caveat: it calls objeto OBLIGATORIO while the schema marks nothing required, an upstream-vs-schema mismatch.

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 EXPRESIONES DE INTERES') plus the exact source system (SEACE), which cleanly separates it from the many other buscar_* siblings that target processes, contracts, requirements, or entities. An agent can identify the resource 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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The only usage-like content is operational (how to continue a prior search via 'ses' or fetch consecutive pages), not 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?

With no annotations, the description carries the full burden, and it does disclose return columns, page size (15 filas por pagina), the paginas range (1..8), and the session-reuse rule (re-executing with the same 'ses' without emitting a new id). It does not state permissions/auth or read-only status, but the behavioral coverage is well above average for a search tool.

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

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

Front-loaded purpose followed by structured Args/Devuelve blocks, so an agent can scan it quickly. It is somewhat verbose, but nearly every line (format examples, return fields, session rule) carries information an agent would otherwise lack.

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 supplies the return field list, pagination rules, and session semantics, which is substantial. Minor gaps remain (no-results/error behavior, explicit read-only statement, and a mismatch where the text calls anio/mes/ruc OBLIGATORIO while the schema marks them nullable).

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 all 7 parameters: marks anio/mes/ruc as required with format examples ('2026', '9' o 'setiembre'), explains entidad as exact name, defines pagina/paginas semantics, and clarifies ses reuse behavior. This fully compensates for the empty 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 (Busca) and resource (ORDENES DE COMPRA Y ORDENES DE SERVICIO, OC/OS) plus the source system (SEACE). This clearly distinguishes it from siblings like buscar_contratos, buscar_procesos, and buscar_cco.

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 concrete guidance: RUC 'hallalo con buscar_entidades', and explains the ses parameter for requesting siguiente_pagina or re-searching with different filters. It lacks explicit when-not-to-use or a direct sibling alternative for order-vs-contract queries, but the operational 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 well: it explains that entidad is required because the site forces choosing institution or ubigeo, and that the year catalog only spans 2019..2026. It omits auth/permission needs and any pagination behavior, which keeps it short of 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 the purpose, then structured Args and Devuelve blocks. Slightly verbose in the row-field enumeration, but each section earns its place and there is 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?

No output schema and no annotations exist, yet the description documents the return envelope (ok, entidad, anio, total, filas with item/entidad/ubigeo/ultima_version/cantidad_procesos/valor_proceso_soles) and the drill-down path. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 0%, so the description must compensate and it does: it defines entidad (name or partial name, example 'SEDAPAL', required and why), and anio (example '2026' with the valid range 2019..2026). This adds real meaning 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) and resource (PLANES ANUALES DE CONTRATACIONES / PAC) scoped to SEACE, plus the two filters (entidad, anio). It also names the sibling detalle_pac for the follow-up drill-down, so an agent can distinguish it from buscar_procesos and the other buscar_* 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?

Gives clear context (public PAC lookup by entity+year) and explicitly routes the agent to detalle_pac(...) to get the individual scheduled processes. It does not spell out when-not-to-use or contrast with buscar_entidades/buscar_acf, but the follow-up alternative is named.

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 most of it well: 15 rows per page, 'index' is global and continuous across pages, 'Reservado'/'---' both mean the amount is unpublished, 'descripcion' filtering happens server-side, and 'paginas' is capped at 1..8. It does not mention authentication, rate limits, or how long a 'ses' stays valid, so the behavioral profile is strong but not 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?

The purpose and session policy are front-loaded, and the per-argument list is dense rather than padded — with 16 undocumented parameters, enumerating them is justified. There is minor redundancy between the standalone 'POLITICA DE SESION' paragraph and the 'ses'/'pagina' argument lines, which restate the same continuation rule.

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, but the 'Devuelve' block lists the returned keys ('ok', 'ses', 'total', 'siguiente_pagina', 'filas', etc.) and explains that 'index' is what ficha_proceso consumes. Combined with the parameter documentation and pagination rules, an agent has everything needed to call and page through this 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% across 16 parameters, and the description compensates for nearly all of them: 'anio' is flagged as mandatory on the first call, 'tipo' defers to listar_filtros, 'objeto' enumerates its four allowed values, 'version' explains the 'Seace 3' -> '3' mapping, 'nro_seleccion' notes it is sent without nomenclature, and 'pagina'/'paginas'/'ses' explain pagination mechanics. This adds substantial meaning the bare schema cannot convey.

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

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

States a specific verb and resource ('Busca PROCESOS DE SELECCION en el Buscador Publico del SEACE') and immediately enumerates the covered selection types (licitaciones, adjudicaciones abreviadas, comparaciones de precios), so the domain is unmistakable. It also names the sibling that supplies filter values (listar_filtros) and the one that consumes the returned index (ficha_proceso), separating itself from the other buscar_* 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?

Gives an explicit session policy: reuse the same 'ses' with the requested 'pagina' to continue, or send identical filters, while different filters start a new search — this is real when-to-do-what guidance. It also points to listar_filtros for valid 'tipo' values. It stops short of saying when to prefer this tool over sibling searches such as buscar_contratos or buscar_pac.

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 real behavior: page size (15 filas), the global/continuous 'index', the 1..8 'paginas' limit, and the session-reuse rule where re-searching with different filters keeps the same 'ses'. It also warns that no publication date or amount is exposed per row. Auth/rate-limit behavior is still absent.

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 front-loaded purpose sentence followed by clearly delimited Args and Devuelve blocks. Every parameter line earns its place given the 10-param surface; the only minor redundancy is restating the session re-run rule twice in different 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 10-parameter tool with no annotations and no output schema, the definition covers parameters, pagination, session semantics, and the returned row shape plus a caveat about missing fields. It is close to complete, with authentication/error behavior the main omission.

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

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

Schema coverage is 0%, so the description must compensate and does: all 10 parameters are explained with meaning beyond their titles, including the OBLIGATORIO marker and enumerated values for 'objeto' (Bien / Consultoria de Obra / Obra / Servicio) and the dd/mm/aaaa date format. This is strong compensation for an undocumented schema.

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

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

The description names a specific verb (Busca) and a precise resource (DIFUSION DE REQUERIMIENTOS del SEACE), and scopes it as 'bienes y servicios que las entidades requerirán'. This distinguishes it from the many sibling buscar_* tools by data source, though it never names an alternative explicitly.

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

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

Usage is implied through the pagination and 'ses' mechanics, but there is no explicit when-to-use vs when-to-use-another-buscar_* guidance. An agent must infer that this tool covers the requirements-diffusion source rather than procesos, contratos, or PAC.

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 disclose the return contract ({'ok', 'nivel', 'catalogo': [{codigo, nombre}], 'nota'}) plus the mandatory-id rules — valuable since there is no output schema. It stops short of stating error handling, auth needs, or that the operation is read-only.

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 clearly separated Args and Devuelve blocks; each line adds information rather than restating the schema. Slightly bulky as a block, 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?

For a two-parameter catalog tool with no annotations and no output schema, the description supplies the purpose, the parameter semantics, the downstream integration point, and the return shape — everything an agent needs to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate fully, and it does: 'nivel' is enumerated with its three values and their meanings, and 'id' is described as the parent-level code with concrete examples ('19' Pasco, '2503'). This goes well beyond the bare 'Id'/'nivel' titles in the schema.

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

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

States a specific resource — the SEACE contracts API geographic catalog of departamentos/provincias/distritos — and immediately links it to the downstream tools it feeds ('llena depa en buscar_contratos y resumen_georef'). An agent can distinguish this catalog tool from the search/listing siblings 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?

The 'nivel' options are spelled out with the condition that selects each one ('provi' requires a parent department id, 'distri' requires a province id), and the description explains its role as the code-source for the other tools. It gives clear context but names no explicit when-not-to-use case or alternative 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return shape and the meaningful edge case ('filas' empty when the process publishes no CUI, site shows 'Sin informacion'), but says nothing about read-only nature, network/scraping failure behavior, or auth/rate constraints.

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

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

The Args/Devuelve structure is compact and front-loaded, with purpose stated before parameters and return value. No filler sentences; slightly terse 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 2-parameter tool with no output schema and no annotations, the description covers the input dependency chain and the returned dict plus its edge case, which is enough to call it correctly. It could still say more about failure modes, but nothing essential to 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 coverage is 0% (bare 'Ses' and 'Index' titles), so the description must compensate and largely does: ses is the session returned by buscar_procesos, and index is the 0-based global row index of that search result. That is exactly the semantic context the schema lacks.

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

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

The description states a specific verb and resource: retrieving the SNIP/CUI codes tied to a process from the 'Codigos' popup, scoped by a search session and row index. It distinguishes itself from the broad buscar_procesos family by being the popup-level detail fetch. It stops short of naming a sibling it is not, 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?

It implies a required two-step flow by defining ses as 'sesion devuelta por buscar_procesos' and index as the row index of that search, which effectively tells the agent this must follow a search. However, it never states when to prefer this over sibling detail tools like ficha_proceso or historial_proceso, nor any 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?

No annotations are provided, so the description carries the full burden. It discloses the return envelope ('ok', 'id_expediente', 'total', 'contratos'), which is genuinely useful given there is no output schema, but it says nothing about permissions, pagination, error behavior, or whether only 'publicados' contracts are guaranteed. Some value added, meaningful gaps remain.

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 core purpose in the first line, then a compact Args block and a Devuelve block. Every sentence carries information: scope, parameter provenance, return shape, and the next-step tool. 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 single-parameter lookup with no annotations and no output schema, the description covers the essential needs: what it returns, where the id comes from, and which tool consumes the result. Only the absence of pagination/error/permission notes keeps it from being 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 0%, so the description must compensate, and it largely does: it defines 'id_expediente' as the selection expediente id, names where to obtain it (buscar_contratos) and gives a concrete example value ('1171246'). It stops short of stating the accepted format or length constraints 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?

States a specific resource and scope: all published contracts for a selection expediente, noting that one process may contain several. It also differentiates from siblings by naming buscar_contratos as the source of the id and detalle_contrato as the follow-up tool, so an agent can place it precisely in the lineage.

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 routes the agent: get 'id_expediente' from buscar_contratos, then use detalle_contrato once you have an 'id_contrato'. That gives context for when this tool is the right step, though there is no explicit statement of when NOT to use it or any prerequisite/precondition caveats.

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 structure and a genuinely useful behavioral detail (document URLs are direct PDF downloads without a token), but never states that this is a read-only operation, nor mentions auth needs, rate limits, or error behavior.

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

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

Front-loads the purpose, then uses explicit Args and Devuelve sections. The return-value enumeration is long but earns its place since there is no output schema. Little wasted prose.

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 read tool with no output schema and no annotations, the description compensates well by describing the return payload shape in detail. Minor gaps remain (read-only status, pagination/limits), but nothing essential for calling 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 coverage is 0%, so the description must compensate, and it does: it names the source tools for id_contrato and supplies a concrete example ('2377490'). This gives the agent enough to supply the value correctly, though it does not describe the ID's format constraints 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?

States a specific verb+resource ('Detalle COMPLETO de un contrato publicado de la API JSON del SEACE') and enumerates the returned sections (cabecera, items, garantias, acciones, documentos). It distinguishes itself by being the full-detail endpoint versus the search tools it references, though it never explicitly contrasts with the sibling 'detalles_contratos' 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?

It helpfully tells the agent where the required id comes from (buscar_contratos or contratos_expediente) and gives an example value, which implies the usage flow. However it gives no explicit when-to-use vs when-not guidance and does not route away from the similarly named 'detalles_contratos'.

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 so by spelling out the complete return envelope ('ok', 'url', 'cabecera', 'item', 'acciones') and the semantic meaning of each action record (convocatoria publication, award, contract). It implies a read-only retrieval but never states side effects or auth requirements explicitly, 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 header states the resource, followed by clearly labeled Args and Devuelve blocks. It is dense but every line carries information. The all-caps lead line is slightly awkward, but there is 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 annotations and no output schema, the description supplies parameter sourcing, index base conventions, and the full return structure, so an agent has what it needs to call and interpret it. It does not cover error/failure behavior beyond the 'ok' flag, leaving a small gap.

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

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

Schema coverage is 0%, yet all three parameters are explained with precise semantics: 'ses' is the session from buscar_procesos, 'index' is the global 0-based row index, and 'nro_item' is 1-based following the order of 'items' in ficha_proceso. The explicit 0-based vs 1-based distinction is exactly the kind of detail the bare schema omits.

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

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

The description names the specific resource — the actions/lifecycle of a single item within a process — and clarifies it is reached via buscar_procesos and ficha_proceso. It is a noun phrase rather than a verb+resource, but the return shape ('ciclo de vida completo del item') makes the intent unambiguous. It is reasonably distinct from siblings like ficha_proceso or historial_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?

It clearly documents the call chain: 'ses' must come from buscar_procesos, 'index' is the row index from that same search, and 'nro_item' comes from ficha_proceso -> items. That gives an agent a clear precondition context. It stops short of explicit when-not-to-use guidance or naming an alternative sibling.

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 supply the return dict shape ({'ok','ses','procesos':[...]}) plus the workflow dependency on buscar_pac, which is genuinely useful given no output schema. It says nothing about permissions, error/out-of-range index behavior, or result-size limits, so the safety and failure profile remains undisclosed.

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

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

The description is front-loaded with the purpose in caps and organized into Args/Devuelve blocks, so an agent can scan it quickly. There is minor redundancy: the summary already mentions 'mes y fuente de financiamiento', which reappears as mes_programado/fuente_financiamiento in the return list.

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 annotations and no output schema, the description covers purpose, all parameters, and the return structure, which is most of what an agent needs. Missing edge-case handling (invalid index, empty PAC) keeps it from being 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 0%, so the description must compensate, and it does: entidad ('nombre de la entidad, igual que buscar_pac'), anio ('anio del PAC'), and index ('fila del resultado de buscar_pac, 0-based; normalmente 0') are all explained, including the non-obvious index semantics. It could add format expectations (e.g., whether anio is a bare year string), but the gap is small.

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

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

The description names a specific verb+resource ('LISTADO DE PROCESOS PROGRAMADOS del PAC de la entidad') and states the scope ('busca en el PAC por entidad/anio y baja el detalle'). It explicitly differentiates itself from the sibling buscar_pac by positioning itself as the drill-down step whose index comes from that tool's result rows.

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 clearly implied: the tool searches the PAC by entity/year and downloads detail, and the 'index' arg is described as a row of buscar_pac's result (0-based, normally 0), which spells out the intended call sequence. It stops short of explicit when-not-to-use guidance or naming alternatives beyond the parent 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 and does well: it discloses the 10-id cap, duplicate deduplication, the partial-failure contract (non-numeric ids land in 'faltas' while the rest still process), and per-item 'ok' flags. It stops short of auth/rate-limit or ordering guarantees, but the operational semantics are unusually well 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?

The scoping sentence is front-loaded, followed by clearly labeled Args/Devuelve sections. Every line is information-dense, though the return-value prose is slightly long and could be tightened.

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

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

No output schema and no annotations exist, so the description supplies the return shape itself ('ok', 'detalles' with per-item fields, 'faltas', 'nota'). For a two-parameter batch tool this is complete enough to invoke 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: 'ids' is documented as a list of numeric id_contrato values with dedup behavior and a 10-per-call cap, and 'maximo' is bounded to 1..10. 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: batch retrieval of contract details ('Lote de DETALLES de contratos publicados en UNA llamada'). It explicitly distinguishes itself from the sibling detalle_contrato, so an agent can route between the batch and single-item 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?

Gives explicit when-to-use ('evita repetir detalle_contrato por cada id') and a clear when-not/alternative ('usa detalle_contrato si solo necesitas uno'). The condition that selects each tool is spelled out rather than 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 well: it discloses that optional header fields appear only when the process publishes them, that items may be empty for emergency processes, and that a signed PDF URL requires a separate call to url_documento(uuid). It does not cover auth requirements, rate limits, or failure modes, so it stops short of 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 with the resource identity, then cleanly partitioned into Args and Devuelve sections. It is dense but every element (optional-field caveat, empty-items caveat, url_documento pointer) earns its place given the absent 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?

With no output schema and no annotations, the description does the heavy lifting by enumerating the full return shape (ok, url_ficha, cabecera, items, cronograma, documentos) and noting edge cases. It is nearly self-sufficient, lacking only error/authentication 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%, yet both parameters are fully explained: 'ses' is the session returned by buscar_procesos and 'index' is the 0-based row index from that same search. This compensates completely for the empty schema and tells the agent exactly how to obtain and format each value.

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 (FICHA DE SELECCION de un proceso del SEACE) and enumerates what it contains: cabecera, items, cronograma, documentos. The provenance of its inputs from buscar_procesos implicitly distinguishes it, but it never contrasts itself with the similarly named sibling fichas_procesos, leaving ambiguity for the agent.

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 supplies a useful calling chain by stating that 'ses' comes from buscar_procesos and 'index' is the row index of that result, which implies when to use it. However, it gives no explicit when-to-use guidance relative to alternatives such as fichas_procesos or historial_proceso, and no exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses caps (50 with 'resumen', 8 with 'completa'), dedup of duplicate indices, and partial-failure behavior (failed indices land in 'faltas' with a reason while the rest are still returned). It doesn't cover auth/permission needs beyond the 'ses' provenance, but the operational limits and failure semantics are well surfaced.

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 in the first clause, then organizes details under Args and Devuelve. Dense but every section earns its place; the only minor cost is the structured block format making it slightly long for three parameters.

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 or annotations exist, so the description must explain returns, which it does by listing the result keys ('ok', 'ses', 'profundidad', 'fichas', 'faltas', 'nota') and the 'faltas' shape. Together with param and cap details this is sufficient for correct invocation, with only the inner 'fichas' payload left to the referenced profundidad modes.

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: 'ses' is tied to buscar_procesos output, 'indices' is defined as global 0-based indices of that search with dedup and cap rules, and 'profundidad' is explained as 'resumen' (search-row fields) vs 'completa' (full ficha as in ficha_proceso). All three parameters are meaningfully documented.

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+scope: a batch of process fichas/summaries from the SAME search in ONE call. It also explicitly distinguishes itself from the sibling ficha_proceso by noting it avoids repeating that call per index, so an agent can route correctly 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?

Explicitly gives the when (multiple indices from the same search, in one call) and the when-not (use ficha_proceso individually if you only need one). Nothing about selection is left 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?

No annotations exist, so the description carries the full burden. It partially compensates by disclosing the exact return shape ({'ok','url','cabecera','historial':[...]}), which tells the agent what it gets back. It says nothing about auth needs, rate limits, or failure modes for a scraping-style 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?

Purpose is front-loaded in the first line, followed by an Args/Devuelve breakdown. The formatting is efficient and every line earns its place; slightly list-like but not 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?

With only 2 params, no output schema, and no annotations, the description supplies both parameter meaning and a return-value sketch. An agent has enough to invoke it correctly; only auth/error behavior is unaddressed, which is minor for this scope.

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% (only titles 'Ses' and 'Index'), so the description must compensate, and it does: ses is defined as the session returned by buscar_procesos and index as the global 0-based row index from that search. The 0-based convention and provenance are genuinely added 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 specific verb+resource ('HISTORIAL DE CONTRATACIONES del proceso') and clarifies the unit returned: each convocatoria with its etapa and estado. It also anchors itself to a sibling ('ses, index de buscar_procesos'), so an agent can tell it apart from buscar_procesos and ficha_proceso without opening a schema.

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

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

The description implies a prerequisite flow (you must first run buscar_procesos to obtain ses and index), which is useful. However it never explicitly states when to use this tool versus ficha_proceso, fichas_procesos, or detalles_contratos for related process data, so selection among siblings remains inferred.

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

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

With no annotations, the description carries the behavioral burden and does disclose non-obvious traits: the session is GLOBAL and shared across tools, an omitted session opens a temporary page and reuses a cached one, and CCO only exposes recent years (2024-2026). It omits a safety/permission profile and error behavior, so not a 5.

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

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

Front-loaded with purpose and then cleanly split into Args and Devuelve sections; most content earns its place. Slightly dense and the trailing CCO-year note is a minor aside, keeping 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?

Compensates for the missing output schema by describing the return shapes ({'ok': True, 'combos': ...} and {'ok': True, 'codigos': [...]}) and fills the 0% parameter coverage. Only a safety/permission profile is absent for an unannotated tool, so 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 coverage is 0%, so the description must compensate, and it does fully: it enumerates every valid 'categoria' value ('todos', 'anio', 'mes', 'objeto', 'tipo_seleccion', 'modalidad', 'departamento', 'version', 'encargo', 'tipos_contrato') and explains 'ses' semantics and its default behavior. This is meaning the schema entirely lacks.

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

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

States a specific resource and function: exact values of SEACE search combos and catalogs from the contracts JSON API. An agent can tell this is a filter/catalog-lookup tool. It does not explicitly differentiate itself from siblings like tipos_seleccion_contratos or catalogo_ubigeo, 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 implied (fetch valid combo values before filtering) and there is a useful pointer that 'tipos_contrato' yields 'codSeleccion' for buscar_contratos. But there is no explicit when-to-use/when-not statement or direct comparison to sibling catalog tools, leaving the agent to infer context.

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 that the 'objeto' drill-down does not paginate and is truncated to the first 100 contracts ('mostrados'), and explains the return shapes. It doesn't cover permissions or data-freshness, but the pagination/truncation disclosure is exactly the behavioral context an agent needs.

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

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

Front-loads the purpose, then uses clean Args/Devuelve sections. It is dense but every line earns its place given the dual-mode behavior and the absence of an output schema; the only slight cost is overall 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?

No output schema exists, so the 'Devuelve' section must explain returns and does so fully: the two possible response shapes with their fields, plus the truncation caveat and where to get the full set. An agent has everything needed to call it and interpret results 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: 'anio' with example '2026', 'depa' as a catalogo_ubigeo code with example '19' Pasco, and 'objeto' with enumerated codes ('62' Bien, '63' Consultoria, '64' Obra, '65' Servicio). All three parameters gain meaning absent from 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 (georeferenced summary of published contracts by department and year) and explicitly defines its two distinct modes: aggregate-by-object-type without 'objeto', and drill-down list with 'objeto'. It also names the sibling it relates to ('mismos campos que buscar_contratos'), so an agent can distinguish it from the many other contract 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?

Gives explicit routing conditions: without 'objeto' you get the aggregate summary, with 'objeto' you get the drill-down list. It further redirects to siblings with conditions ('para la ficha del contrato usa detalle_contrato', 'para el resto usa buscar_contratos con depa+objeto'), so when/when-not/alternatives are all 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?

With no annotations, the description carries the full burden. It usefully discloses the return payload ('ok', 'tipos': [{codSeleccion, descSeleccion}]), which is more than most catalog tools offer. However it says nothing about whether the catalog is static/cached, error behavior, or auth needs, so the read-only safety profile is only inferred from the return shape.

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

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

Purpose is front-loaded in the first line, followed by clearly labeled Args and Devuelve blocks. It is tight with no filler, though the Python-docstring framing is slightly unusual for a tool description.

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

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

There is no output schema, and the description covers the return shape, so the agent knows what it will get back. For a single-optional-parameter catalog lookup this is largely sufficient, with only error/edge behavior left unstated.

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 'anio' is the year of the catalog and gives an example ('2026'), adding meaning beyond the bare schema title/default. It does not say what happens if the year is omitted (schema default '2026') or whether invalid years return an empty catalog.

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 ('tipos de seleccion de la API JSON de contratos') and signals it is the authoritative catalog ('Catalogo EXACTO'). It does not explicitly differentiate itself from other catalog siblings such as catalogo_ubigeo, codigos_proceso, or listar_filtros, but the verb+resource pair 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?

Usage is implied rather than stated: by noting that 'codSeleccion' is the value of 'cod_seleccion' in buscar_contratos, it hints the agent should call this to resolve codes before filtering contracts. There is no explicit when-to-use, when-not-to-use, or alternative named.

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 that the URL is signed on the fly with short validity, that the server does NOT download the file, and precise error semantics (nonexistent uuid may manifest as a timeout, whereas a malformed uuid is rejected instantly). These are exactly the behavioral traits an agent cannot get from the schema.

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

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

Front-loaded with the core purpose, then structured Args and Devuelve sections. Slightly long due to the error-handling note, but every sentence earns its place and nothing is redundant.

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

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

For a single-parameter read tool with no output schema, the description explains the return shape ({'ok','url','archivo'}), the nature of the URL, and failure modes. An agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 0% and the schema only names the field 'uuid' with no description, so the description must compensate. It does: it identifies the uuid as the document id listed in ficha_proceso and supplies a concrete example value, fully disambiguating the parameter.

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

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

States a specific verb and resource: returns a signed URL to download a SEACE process document, with concrete examples (bases integradas, integraciones). This clearly separates it from the sibling 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?

The description ties usage to a prerequisite by saying the uuid comes from the document listed in ficha_proceso, which tells the agent what to call first. It does not, however, explicitly name the alternatives (url_documento_contrato, url_perfil_proveedor) 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 burden, and it does disclose useful behavior: the returned 'url' is a direct GET of the PDF and the server does not store it. It omits any auth/permission requirements or rate-limit context, so it is adequate but incomplete for a zero-annotation 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?

Front-loads the purpose, then Args, then return shape — a clean, scannable structure with no filler. Minor redundancy in restating the parameter name, but overall efficient.

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

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

For a single-parameter, no-output-schema tool the description is nearly complete: it explains the parameter's origin and the shape of the return ({'ok','url','nota'}). Only auth/permission context is missing, which is minor given the tool's simplicity.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it names the underlying source field (idDocumentoContrato) and gives a concrete example value ('153203160'). This adds real meaning beyond the bare string parameter in 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: returns the download URL of a CONTRACT document from the SEACE JSON API. It is clear what the tool produces, but it never distinguishes itself from the sibling url_documento, so an agent must guess which URL tool to pick.

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

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

There is no when-to-use guidance and no named alternative. The description does not say when to call this versus url_documento or the various detalle_* tools, leaving selection 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?

No annotations are provided, so the description carries the burden. It does disclose the return shape ({'ok', 'url'}) and that the result is a public page, which is useful. However, it says nothing about authentication, permission requirements, or whether the RUC must already exist in the system.

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 purpose is front-loaded in the first line, followed by cleanly labeled Args/Devuelve sections. No filler; appropriately sized for a simple lookup 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?

For a one-parameter URL builder with no output schema and no annotations, the description covers input meaning and output shape adequately. Minor gaps around error behavior (e.g., what happens with an unknown RUC) 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 coverage is 0%, so the description must compensate, and it does: it clarifies that 'ruc' is the RUC of a provider OR a consortium, a meaningful distinction not present in the schema. That is solid added value for a single required parameter.

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

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

States a specific resource (supplier profile URL) and names the exact portal context (OECE perfilprov), so an agent knows precisely what it returns. It does not explicitly contrast with siblings like url_documento or url_documento_contrato, 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?

There is no guidance on when to use this tool versus the many sibling URL/document tools. Usage must be inferred entirely from the name and the brief purpose statement.

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