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

With no annotations, the description carries the full behavioral disclosure burden. It accurately indicates a read-only catalog search and the level of the taxonomy, but it does not explain whether searches are exact or partial, whether codigo and nombre are alternatives or combinable, or what pagination behavior to expect.

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

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

A single sentence with no filler, front-loading the action and resource before listing the search keys. Every word contributes to understanding the tool's purpose.

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 description captures the core purpose but omits invocation details such as whether at least one search key is required and the role of categoria/pagination parameters. The presence of an output schema reduces the need to document return values, but agent invocation guidance remains partially under-specified.

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 covers 'codigo' and 'nombre' as search keys but remains silent on 'categoria', 'pagina', and 'items_por_pagina', leaving those roles to be inferred from names and defaults.

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 uses a concrete verb ('Busca') and a specific resource ('productos del catálogo de bienes y servicios (nivel 5)') and names the search criteria ('por nombre o código'). This clearly differentiates it from sibling search tools like buscar_procesos and buscar_proveedores.

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

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

The description implies when to use the tool: when searching catalog products by name or code. It does not explicitly state exclusions or alternatives, but the resource-specific wording makes the use case clear enough.

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 of behavioral disclosure, but it only restates the search criteria. It does not reveal pagination behavior (despite the pagina and items_por_pagina parameters), how multiple filters combine, whether at least one filter is needed, or result limits. It is not misleading, but it is too thin to be more than minimally 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?

A single front-loaded sentence with zero waste: verb and resource come first, the domain-defining parenthetical earns its place, and the filter dimensions are enumerated compactly. Every element contributes to understanding, and nothing is repeated from the 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?

The output schema covers return values, and all six parameters are optional with sensible defaults, but the description still lacks pagination semantics, filter-combination behavior, and any differentiation from the obtener_convocante sibling. It is the minimum viable description for a multi-parameter search tool; an agent would benefit from clarification of how the filters interact and when to prefer the singular fetch 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 is the sole source of parameter meaning. It usefully maps four of the six parameters (nombre, codigo_sicp, nivel, tipo_entidad) to real-world concepts. The remaining two (pagina, items_por_pagina) are self-explanatory from their names and default values, so the partial coverage adequately 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 ('Busca'), a specific resource ('entidades convocantes'), and clarifies the domain term with the parenthetical '(instituciones que contratan)'. It then enumerates the four search dimensions (nombre, código SICP, nivel, tipo), so an agent knows exactly what the tool does without needing to open the schema.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention the closely related sibling obtener_convocante or the other buscar_* search tools, and gives no exclusions or preferred-usage context. The only weak hint is the verb 'Busca', which implies a search rather than a get-by-ID use case, but that is left entirely 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 present, so the description carries the full burden of disclosing behavior. 'Busca' implies a read/search operation, but the description does not mention pagination behavior, result semantics, side effects, or any operational caveats.

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

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

The description is a single sentence with no filler, so it is concise. However, its terseness leaves important gaps in usage and parameter semantics, making it under-specified rather than effectively compact.

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

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

An output schema exists, but the tool has six optional parameters and zero parameter documentation, and the description provides no usage context or clarification of domain-specific jargon. The definition is not complete enough for an agent to invoke the tool correctly in all cases.

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 none of the six parameters are described in the tool description. The description does nothing to compensate for the missing parameter documentation, leaving the agent to infer meanings from parameter names alone.

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

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

The description uses a concrete verb and resource: 'Busca intenciones de contratación', which distinguishes it from the sibling search tools by target resource. However, the parenthetical 'excepciones con difusión posterior' is cryptic and not explained, so the exact scope is not fully transparent.

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 instead of sibling search tools like buscar_procesos, buscar_proveedores, or buscar_convocantes. No contexts, exclusions, or alternative recommendations are given.

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

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

No hay anotaciones, así que la descripción lleva toda la carga. Revela que devuelve un 'record package OCDS con paginación', pero no menciona límites de resultados, orden, comportamiento con parámetros vacíos o posibles errores. Es información útil pero incompleta para una herramienta con 13 parámetros y sin anotaciones.

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?

Texto breve y directo, con la información clave al inicio: qué busca y la condición de uso importante ('Se requiere al menos un filtro'). Las restricciones de formato y el tipo de respuesta están en pocas líneas sin relleno.

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?

Hay output schema y los parámetros son opcionales aunque se exige al menos uno. La descripción cubre los elementos esenciales: filtros, formato de fecha, tipo_fecha y paginación. Para un buscador con 13 parámetros y 0% de cobertura en el schema, podría profundizar en valores válidos y ejemplos, pero la descripción es funcionalmente completa para invocar la herramienta correctamente.

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?

La cobertura de descripción del schema es 0%, por lo que la descripción debería compensar. Menciona 'filtros del estándar OCDS', el formato de fechas, el campo tipo_fecha y la paginación, pero no explica la mayoría de los 13 parámetros. El agente debe inferir qué hace cada campo desde el nombre o desde conocimiento externo.

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?

La descripción usa el verbo 'busca' con el recurso 'procesos de contratación pública' y menciona filtros OCDS, lo que permite distinguirla claramente de herramientas como obtener_licitacion o contar_licitaciones. Aunque no nombra explícitamente a un sibling, el alcance es específico y accionable.

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?

Indica claramente que se requiere al menos un filtro y especifica el formato de fechas y valores aceptados para tipo_fecha. No menciona alternativas ni cuándo preferir otros buscadores, pero el contexto de uso queda suficientemente claro para una herramienta de búsqueda.

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 disclosure burden. It only says 'Busca'; it does not state that results are paginated, whether filters can be combined, whether matching is exact or partial, or any read-only/safety cues. This is a significant gap for a tool 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 a single concise sentence with the verb and resource front-loaded. There is no filler, no repeated schema infomation, and every word contributes to understanding what the tool does.

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 moderate-complexity search tool with an output schema and self-descriptive optional parameters, the description is minimally viable: an agent can likely invoke it with at least one of the named criteria. However, with no annotations and no guidance on pagination/filter semantics or when to prefer obtener_proveedor, it is 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?

With 0% schema description coverage, the description does partial compensating work by listing the main search parameters in plain language: nombre, RUC, categoría, and sancionado. It omits the two pagination parameters (pagina, items_por_pagina), though those are reasonably self-evident from their names/defaults. It adds no detail on optionality or how multiple filters interact.

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

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

Identifies a specific action ('Busca') and a clear resource ('proveedores del Estado'), and enumerates the key search criteria (nombre, RUC, categoría, sancionado). This makes it distingushable from most sibling tools, which target processes, convocantes, catalogo, etc. It does not explicitly contrast with obtener_proveedor, but the verb difference makes that distinction usable.

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

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

There is no when-to-use guidance, no mention of alternatives, and no exclusion such as 'use obtener_proveedor if you already have a RUC'. The description implies this is the search entry point for suppliers, but leaves all selection logic 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 hay anotaciones, por lo que la descripción debe cargar con la transparencia. 'Cantidad de licitaciones' comunica que es una operación de conteo y no una mutación, y el vínculo con resumen_licitaciones declara el comportamiento de filtrado. No se mencionan autenticación, límites ni si el conteo es exacto, pero para una herramienta de conteo la conducta básica queda clara.

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?

Es una sola oración sin palabras de relleno que comunica la operación y el contexto de filtros de forma compacta. La información esencial está al frente y no hay contenido redundante.

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?

La herramienta tiene cinco parámetros sin descripción, no hay anotaciones y la descripción se limita a diferir a resumen_licitaciones en lugar de explicar los filtros o su formato. Aunque existe un esquema de salida, el agente no tiene suficiente información autónoma para invocarla correctamente sin consultar la herramienta hermana.

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?

La cobertura del esquema es 0%, así que la descripción debería compensar explicando los cinco parámetros, pero solo dice que son los mismos filtros que resumen_licitaciones sin definirlos. Los nombres 'desde', 'hasta', 'categoria', 'comprador' y 'modalidad' son sugerentes, pero la descripción no aporta significado adicional sobre formatos o valores válidos.

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?

La descripción identifica claramente el resultaddo (una cantidad) y el recursso (licitaciones), y al remitir a los 'mismos filtros de resumen_licitaciones' ayuda a diferenciarlo de las herramientas que devuelven registros individuales o listas. No llega a 5 porque asume que el agente ya conoce qué filtros usa resumen_licitaciones.

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?

El frasse 'según los mismos filtros de resumen_licitaciones' implica que esta herramienta es el equivalente de conteo de resumen_licitaciones, lo que da un contexto de uso. Sin embargo, no explica explícitamente cuándo elegirla frente a buscar_procesos u otras alternativas ni qué filtros compartidos aplican.

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 behavioral burden. 'Obtiene' clearly indicates a read operation rather than a mutation, but no further behavior such as error cases, access requirements, or return limitations is disclosed.

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

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

The description is a single front-loaded sentence that directly states what is retrieved and how. It contains no redundant or wasted words.

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

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

This is a simple get-by-id tool with only one required parameter and an output schema, so the description does not need to explain return values. Taken together with the schema, it is sufficient for correct invocation, though it lacks sibling comparison context.

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?

Input schema coverage is 0%, and the description only says 'dado su id', which adds little beyond the parameter name 'id_adjudicación'. It does not explain the format, origin, or domain meaning of the ID.

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 ('obtiene') and resource ('datos de una adjudicación (proveedor adjudicado)'), making the operation and entity clear. The parenthetical distinguishes the award entity from sibling tools like obtener_proveedor and obtener_licitación.

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

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

The phrase 'dado su id' implies this tool is for retrieving an award when its ID is known. However, it does not explicitly state when to choose this over sibling obtener_* or buscar_* tools, nor does it mention 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 behavioral disclosure burden. 'Lista' clearly signals a read-only listing operation with no side effects, but the description does not explicitly state read-only behavior, data source, or any ordering/completeness guarantees. For a simple zero-parameter list tool this is adequate though minimal.

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

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

The description is a single, front-loaded sentence with parenthetical examples that add value without redundancy. Every word contributes to clarifying the tool's purpose.

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 parameterless taxonomy-listing tool with an output schema available, the description is complete. It states the subject matter and gives examples of the categories, and nothing else is needed to invoke 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?

The tool has zero parameters and the schema has 100% coverage by virtue of having an empty properties object. There is no parameter detail to add, so the baseline of 4 applies; the description reasonably focuses on the returned concept rather than parameters.

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 uses a specific verb ('Lista') and a clear resource ('categorías de contratación') with concrete examples ('bienes, servicios, obras, consultorías...'). It clearly identifies what the tool returns and differentiates it from related taxonomy tools like obtener_modalidades or obtener_parametros.

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

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

The description implies usage: call this when you need the list of procurement categories. However, it does not explicitly state when to use this tool versus alternatives such as obtener_modalidades or buscar_catalogo, and no exclusions or alternative routing are provided.

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 disclosure burden. It conveys a non-destructive fetch through 'obtiene', and the output scheme covers return shape. It does not disclose auth requirements, error behavior, or any side effects, which is acceptable but minimal for this simple get-by-id.

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?

One sentence with no redundancy; the operation and its key are front-loaded and the sentence earns its place. Appropriate size for a simple tool.

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

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

Given the tool's simplicity (one required parameter, output schema present), the description is nearly complete. It does not mention access prerequisites or the meaning of 'firmado' (signed) as a state, but these are minor for a fetch-by-ID 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 has 0% description coverage, but the description maps the single parameter to the domain concept 'código de contratación', clarifying that id_contrato is the contracting code rather than any internal ID. No format, example, or value constraints are given, but for a single string ID this is adequate.

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: 'Obtiene los datos de un contrato firmado' (gets signed-contract data). The resource is distinct from sibling tools (proveedor, licitación, adjudicación), and the query key is named ('código de contratación'). Slight lack: does not explicitly mention siblings by name.

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

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

No when-to-use guidance or exclusions are provided; the only signal is the verb 'obtiene' implying a lookup. Sibling tools cover related procurement objects, but no routing conditions distinguish them. The usage context is implied, not stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Obtiene los datos' clearly signals a read operation, but it does not explain behavior for missing codes, permissions, or rate limits. This is acceptable for a simple getter, but not deeply transparent.

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 descrciption is a single direct sentence with no padding. It is easy for an agent to parse and the key information is present.

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

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

For a simple get-by-identifier tool with one parameter and an output schema, the description covers the essentials. However, it lacks explicit sibling guidance and behavior when the entity is not found, preventing a higher score.

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 description compensates by identifying the parameter as 'código SICP', giving real meaning to the schema title 'Id Convocante'. It does not provide format or examples, but for a single required parameter this is enough to invoke correctly.

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

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

The description uses a specific verb ('obtiene'), a clear resource ('entidad convocante'), and the access criterion ('código SICP'). This distinguishes it from search-oriented siblings, though it does not explicitly mention alternatives like buscar_convocantes.

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

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

Usage is implied: call this when you already have a SICP code and need the convocante's data. There are no explicit exclusions or guidance about when to prefer sibling tools such as buscar_convocantes.

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 burden. 'Obtiene' implies a read-only operation, but the description does not mention behavior for invalid or missing IDs, authentication needs, or response details. It is not misleading, but it is minimal.

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 one short sentence with no filler. The operation, resource, and parameter are all front-loaded, and every word contributes value.

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

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

For a simple one-parameter get-by-ID tool, the description covers the essential call pattern, and an output schema exists to explain return values. It lacks explicit sibling differentiation and edge-case behavior, but those are secondary 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. It does add meaning by describing the parameter as a numeric ID, and it is the only parameter, so an agent can infer what to pass. Still, no format example or further clarification is given beyond the schema's bare title.

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 uses a specific verb ('Obtiene') and resource ('datos de una licitación'), and clarifies that it operates by numeric ID. It is clear, though it does not explicitly distinguish itself from sibling tools such as buscar_procesos or resumen_licitaciones.

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

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

The phrase 'dado su id numérico' implies this is for direct, single-record lookup when the ID is already known. However, it does not explicitly say when to use this tool instead of a search tool, nor does it name an alternative.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It clearly describes a read-only listing operation, but it does not mention any additional behavioral traits such as authentication needs, pagination, or whether the list is exhaustive. For a simple parameterless list tool this is acceptable, though not rich.

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

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

The description is a single concise sentence that is front-loaded with the verb and object. It contains no filler, repeats no schema information, and every word contributes to understanding the tool's purpose.

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

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

The tool is very simple: zero parameters, an output schema exists, and the description states what is returned. The only slight gap is that it does not explain how these modalities relate to other tools or whether the list is used as an input elsewhere, but this is not necessary for invoking 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?

The input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics to explain. The description correctly focuses on the tool's purpose instead of inventing parameter details. This matches the baseline for a no-parameter tool.

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

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

The description uses a specific verb ('Lista') and a clear resource ('modalidades de contratación'), with illustrative examples such as 'licitación pública' and 'contratación directa'. This distinguishes it from sibling tools like obtener_categorias or obtener_parametros by specifying exactly what kind of list it returns.

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 the tool should be used when an agent needs the list of contracting modalities, but it does not explicitly state when to prefer it over alternatives or provide any exclusions. There is no mention of related tools such as obtener_categorias or buscar_catalogo, so the usage guidance is adequate but minimal.

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?

There are no annotations, so the description carries the behavioral burden. It discloses that the tool lists data and optionally filters, but it does not describe pagination, response format, filter matching behavior, or side effects. For a simple read-only listing toul this is partially sufficient but still leaves gaps.

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

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

The description is a single concise sentence with the action, resource, and optional filter upfront. Every word adds value and there is no redundant 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?

The tool is simple, has one optional parameter, and an output schema is present. The description covers the core purpose and the filter. However, with no annotations and no usage guidance, it leaves some surrounding context undocumented, though not enough to make invocation impossible.

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 adds meaning by explaining that 'dominio' is an optional filter. It does not explain the possible values, format, or exact matching behavior, though the example ('aseguradoras autorizadas') gives some context.

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 uses a specific verb ('Lista') and resource ('parámetros/dominos de la API') with a concrete example ('aseguradoras autorizadas'). It is clear about what the tool does, though it does not explicitly contrast with sibling tools that also return catalogs.

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 states that filtering by 'dominio' is optional, which implies the main use is listing all parameters/domains. However, it gives no explicit guidance on when to prefer this tool over similar sibling tools, 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?

With no annotations, the description carries the full behavioral burden. 'Obtiene' expresses a read-only retrieval, but it adds no detail about error handling, missing records, authentication, or other behavioral traits beyond the basic fetch operation.

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

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

The description is a single sentence with no filler or redundant restatement. It front-loads the action and resource, then clarifies the input.

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

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

For a simple get-by-id tool with one required parameter and an output schema, the description is largely complete. It identifies the resource, the action, and the input. It could improve by noting alternatives or specific error behavior, but these are minor for this simplicity level.

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 clarify the parameter. 'Dado su id' directly explains that id_protesta is the identifier of the protest/download, which is meaningful even though it closely mirrors the parameter name. It doesn't provide format details, but with one parameter this is sufficient.

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 ('Obtiene') and resource ('datos de una protesta/denuncia'), and explicitly says the input is an id. This clearly distinguishes it from sibling obtener_* tools, which target different resource types.

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

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

The phrase 'dado su id' implies this tool is for fetching a specific protest by id, rather than searching, which distinguishes it from the buscar_* siblings. However, it does not explicitly state when to use this versus the buscar_* tools or mention 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, but it adds little beyond the verb 'obtiene,' which essentially restates the tool's name. It discloses no error behavior for unknown or malformed RUCs, no uniqueness guarantee, no format requirements, and no side-effect or access considerations. Nothing is misleading, but almost no behavioral context is added.

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

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

The description is a single 12-word sentence, front-loaded with the verb, then the resource, then the lookup key. There is no filler, redundancy, or digression; every word earns its place.

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

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

For a simple tool with one required string parameter and an output schema present, the description conveys the essential invocation pattern. However, it omits guidance on the boundary with buscar_proveedores and leaves RUC format expectations unstated, so the definition is adequate but has clear 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 description coverage is 0%, so the description must document the ruc parameter, yet it only says 'dado su RUC,' which echoes the parameter name. It does not explain the expected format (e.g., the 11-digit Peruvian RUC structure), whether leading zeros or separators are significant, or any constraints on the value. The meaning added over the bare schema is minimal.

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 uses a specific verb ('Obtiene') with a clear resource ('los datos de un proveedor del Estado') and the identifying key ('dado su RUC'). This distinguishes it from sibling obtener_* tools (which target licitaciones, contratos, adjudicaciones, etc.) and from buscar_proveedores, which is the search counterpart rather than a direct retrieval by identifier.

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 RUC-keyed lookup implies the use case: retrieve a specific supplier when its RUC is known. However, the description never explicitly states when to choose this over buscar_proveedores, which also concerns suppliers, and it gives no exclusions or alternative routing. The guidance is present only by inference from the parameter name.

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

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

With no annotations, the description carries the behavioral disclosure burden. It indicates a read/retrieve operation ('Obtiene') and the nature of the result ('completo'), but it does not mention error handling, permissions, or rate limits. For a simple get-by-ID tool, this is adequate but does not go beyond the surface behavior.

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

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

The description is a single, well-structured sentence that front-loads the action and resource, then clarifies the input with an example. Every word is necessary; there is no fluff or repetition. It is appropriately sized for a one-parameter read tool.

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

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

For a tool with one parameter, no annotations, and an existing output schema, the description covers the essential invocation details: what it returns and how to specify the OCID. The only notable gap is the lack of explicit routing guidance against sibling tools, though the word 'completo' partially compensates. Overall, an agent can select and call 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?

The schema provides only type and title with no description, yielding 0% coverage, so the description must compensate. It explains that the parameter is an OCID and gives a realistic example ('ocds-03ad3f-487119-1'), which is highly informative. It does not fully specify format rules, hence a 4 rather than 5.

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

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

The description states a clear verb ('Obtiene'), a specific resource ('proceso de contratación completo (record OCDS)'), and the required input ('dado su OCID'), with a concrete example. It distinguishes itself from sibling tools like obtener_licitacion or obtener_contrato by emphasizing that it returns the complete record. No ambiguity remains about what the tool does.

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 clearly implies the tool is used when you have an OCID and want the complete contracting process record, as opposed to the more specific sibling tools. However, it does not explicitly name alternatives or state when not to use it, so the contrast is implied rather than declared. The condition 'dado su OCID' provides clear context, but exclusions are missing.

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 behavioral burden. It communicates that the operation is a filtered, minimal summary, which strongly implies a read-only query, and nothing suggests destructive behavior. However, it does not clarify how filters combine, what 'resumen' actually includes, or what happens when no filters are supplied.

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 one concise, front-loaded sentence: the core purpose comes first, followed by a compact enumeration of the optional filters. There is no filler or redundancy.

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

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

The output schema exists and all parameters are optional, so the description conveys the basic operation and filter surface. However, with no annotations and a large set of sibling tools, it omits when-to-use guidance and leaves the distinction from counting and full-search tools implicit.

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

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

Schema description coverage is 0%, so the description must compensate. It maps the five parameters into semantic groups: categoria, modalidad, comprador, and date range (desde/hasta). It does not specify date formats, allowed values, or how multiple filters interact, but the parameter names themselves are mostly self-explanatory.

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

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

The description clearly identifies a 'minimum summary of licitaciones' and lists the main filtering dimensions, so an agent can tell what resource is being returned. It stops short of full distinction from siblings like buscar_procesos or contar_licitaciones, and it uses a noun phrase rather than an explicit action verb.

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

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

There is no guidance on when to use this tool versus the many sibling tools such as obtener_licitacion, buscar_procesos, or contar_licitaciones. The optional filters imply a query-style use case, but no alternatives or exclusions are mentioned.

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