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

No annotations are provided, so the description must convey behavior. It describes the return (totals of contracts, value, paid value), which is useful. However, it does not mention whether the operation is read-only, any required permissions, rate limits, or side effects. Given the aggregation nature, it is likely safe, but transparency is moderate.

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

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

The description is two sentences, front-loaded with the action and output, and every sentence adds value. No unnecessary 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?

Given 7 parameters, 0% schema coverage, and no annotations, the description covers the main purpose and output but leaves most filter parameters unexplained. The existence of an output schema helps, but the description still lacks details on valid values for 'agrupar_por' (no enum) and how filters interact. More completeness would be beneficial.

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

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

Schema coverage is 0%, so the description must compensate. It explains the 'agrupar_por' parameter (grouping field) by listing possible values (proveedor, entidad, departamento, modalidad), but it does not explain the other 6 filter parameters (entidad, proveedor, departamento, fechas, limite). Without descriptions, the agent may not know how to use filters 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 clearly states it aggregates SECOP II contracts by provider, entity, department, or modality, and returns totals. It also provides concrete use cases (concentration detection, entity comparison, modality analysis), distinguishing it from sibling tools that are likely search-oriented.

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 use for analytical tasks like detecting concentration and comparing entities, but it does not explicitly state when not to use or name alternative tools. The context is clear but lacks exclusion criteria.

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 provided, so description must convey behavioral traits. It mentions the tool returns detailed financial data (values paid, billed, pending) and that it is the most complete dataset. However, it does not disclose safety (likely read-only), rate limits, authentication needs, or pagination behavior beyond what is in 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?

Four sentences with no wasted words. Front-loaded with the core purpose, then provides key context about data richness and priority. Efficient and well-structured.

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 13 parameters with no schema descriptions and no annotations, the description is insufficient. It lacks details on parameter usage, date formats, value constraints, and output interpretation, even though an output schema exists.

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 description is critical. Only 'nit_proveedor' is explained as offering exact search. Other parameters like 'entidad', 'proveedor', 'fecha_desde' are not described, leaving their meaning and format unclear.

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

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

The description clearly states it searches for electronic contracts in SECOP II and distinguishes from SECOP I by advising to try this first. However, it does not explicitly differentiate from sibling tools like 'buscar_procesos_secop2' which may have overlapping scope.

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

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

Provides explicit guidance to use this tool before SECOP I and suggests using 'nit_proveedor' for exact searches. It mentions this dataset is most complete for financial execution, but does not cover when to use other related tools.

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

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

With no annotations, the description carries full burden. It discloses the tool searches simultaneously across multiple datasets and prioritizes document numbers, but lacks details on pagination, rate limits, aggregation behavior, or result format. This is adequate but not rich.

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

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

The description is concise and well-structured: purpose first, then usage context, then a tip. Every sentence adds value with no fluff.

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 complexity (4 params, no annotations) and presence of output schema, the description covers the broad search purpose well but lacks parameter details for 'limite' and 'detalle', and does not mention pagination or result handling. Output schema may cover return values, but parameter gaps reduce completeness.

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

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

Schema coverage is 0%, so description must compensate. It explains 'documento' and 'nombre' search fields, but fails to describe 'limite' (limit) and 'detalle' (detail level) parameters. Missing semantics for half the parameters leaves agents underinformed.

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

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

The description clearly states the tool searches across all SECOP datasets by document number or name, explicitly listing the datasets covered (SECOP II Procesos, SECOP II Contratos, SECOP II Proveedores, SECOP I). It distinguishes from siblings by being the most comprehensive tool for investigating contracting history, while siblings are more specific.

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 advises using 'documento' over 'nombre' for reliability, and indicates the tool is for finding all contracts/processes/records for a specific contractor. It provides clear use context but does not explicitly state when to use sibling tools or 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?

Given no annotations, the description carries full burden but only states that the tool searches and includes fields like entity, provider, values, and status. It does not disclose pagination, auth needs, rate limits, or whether it is read-only. Adequate but not detailed.

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 purpose and uses three short paragraphs. It is moderately concise with no fluff, but could be slightly tighter by removing redundant platform emphasis.

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 complexity (15 parameters, no schema descriptions, no annotations), the description is insufficient. It lacks parameter details, output format (despite output schema existing), and comparisons with sibling tools like buscar_contratos_secop2. Significant gaps remain.

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

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

With 0% schema description coverage and 15 parameters, the description must compensate. It only explains the nombre_procedimiento parameter and vaguely references entity, provider, values, and status. Most parameters remain unexplained, leaving the agent to infer from names.

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

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

The description clearly states the tool searches for contracting processes in SECOP II, specifying the resource (processes) and the platform. It distinguishes itself from SECOP I by instructing to search here first, and from siblings like buscar_secop1.

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 clear context: search here first before SECOP I, and includes a tip about the nombre_procedimiento field. However, it does not explicitly state when to use alternatives like buscar_contratos_secop2 or 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 provided, the description carries full burden for behavioral disclosure. It does not state that the operation is read-only, nor does it explain pagination behavior (limite, offset) or any required authentication. The description only implies searching without deeper behavioral context.

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

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

The description is short (three sentences) and front-loaded with the main action. Each sentence adds information, though the second sentence ('Permite identificar...') is somewhat redundant with the first. Still, it remains concise and to the point.

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 has 6 parameters, no schema descriptions, and no annotations, the description is insufficient. It does not explain pagination, combining filters, or the output (though output schema exists, reducing some burden). The description leaves significant gaps for effective use.

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 only explains nombre, nit, and geographic location (departamento and ciudad loosely), but omits the pagination parameters 'limite' and 'offset'. Users must infer their purpose from 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 clearly states the tool searches for suppliers (proveedores) in SECOP II and lists specific search criteria (name, NIT, location). It differentiates from sibling tools that search contracts or processes, though it could be more explicit about the distinct resource type.

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 suggests use for verifying supplier registration ('Útil para verificar el registro de un proveedor'), but provides no guidance on when not to use it or how it compares to alternatives like buscar_por_persona or buscar_contratos_secop2.

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 provided, so description carries full burden. It discloses that data is historical and system no longer used, and that filters are AND combinable. However, it does not mention any side effects, rate limits, or data freshness. For a search tool, this is adequate but not comprehensive.

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

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

The description is short, front-loaded with purpose, includes critical usage guidance, and has no unnecessary words. Every sentence adds 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?

With 15 parameters, no schema descriptions, and no annotations, the description is insufficient to fully understand parameter semantics (e.g., valid values for 'modalidad', meaning of 'estado'). The existence of output schema does not cover parameter meaning. The description missing details for many parameters.

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

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

Schema has 15 parameters with 0% description coverage. The description only states 'All filters are optional and combinable (AND)', which is a general note but does not explain each parameter's meaning. Given the low coverage, the description should compensate but fails to do so.

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

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

The description clearly states the tool searches public procurement processes in SECOP I (historical data), and distinguishes it from siblings by explicitly mentioning it is the older system and advising to use SECOP II first.

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 explicitly tells when to use this tool (only if no results in SECOP II or contract is before ~2020) and directs to use SECOP II tools (siblings) first.

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

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

No annotations are provided, so the description must convey behavioral traits. It describes the tool as allowing direct SoQL queries similar to SQL, and provides examples. However, it does not mention whether the tool is read-only, whether it has side effects, authentication needs, or error handling. The examples only cover one parameter ($where). While it gives a basic understanding, more transparency about safety and limitations would be beneficial.

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 relatively concise, fitting the main purpose in two sentences and then providing examples. It starts with the primary purpose and then adds detail. Could be slightly more structured to separate explanation from examples, but overall efficient and not verbose.

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 7 parameters, 0% schema description coverage, no annotations, and an output schema that is present but not described, the description is incomplete. It does not explain return values or pagination (though 'limite' and 'offset' suggest it), nor does it cover all parameters. The link to documentation helps but the description itself lacks full context. For a complex tool, more completeness is needed.

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%, meaning the input schema provides no parameter descriptions. The description only adds context for the 'where' parameter via examples. Other parameters like 'dataset', 'select', 'order', 'busqueda_texto', 'limite', and 'offset' are not explained. The description should have provided meaning for all parameters to compensate for the lack of schema documentation. Without that, the agent may misuse 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 clearly states 'Consulta libre con SoQL sobre cualquier dataset SECOP,' indicating it's a free-form query tool. It specifies that it handles advanced queries not covered by other tools, and explains it allows writing SoQL clauses directly. This distinguishes it from sibling tools that likely have more constrained queries.

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 says 'Para consultas avanzadas que las otras herramientas no cubren,' providing explicit guidance on when to use this tool. It implies that for simpler or common queries, other tools should be used. It also includes a link to SoQL documentation for learning, and gives concrete examples of $where clauses, aiding correct usage.

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 behavior of distinguishing person types but lacks information on safety (e.g., read-only, destructive), authentication needs, or rate limits. For a tool with zero annotations, this is insufficient.

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 concise and structured with bullet points for return values. It is front-loaded with the tool's purpose. One minor issue: the first sentence is somewhat passive ('Cuenta personas contratadas y valores por año'), 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?

The tool has 3 parameters and no annotations but has an output schema. The description explains the output well but lacks full parameter descriptions and usage guidance. For a relatively simple aggregation tool, it is adequate but not 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%. The description mentions 'entidad' indirectly and 'por año' for 'anios', but does not explain the 'solo_personas_naturales' boolean parameter explicitly, though it relates to the natural vs legal person distinction. Given low coverage, the description should provide more detail.

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

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

The description clearly states the tool counts hired people and values per year for an entity, listing specific return fields (unique persons/providers, total contracts, total contracted value, total paid value). It also distinguishes between natural and legal persons, which differentiates it from sibling tools like 'agregaciones_contratacion'.

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 mentions 'Ideal para KPIs de contratación', implying a usage context, but does not explicitly state when to use this tool versus alternatives or provide any when-not guidance. No sibling tool names are referenced.

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, and the description only mentions listing datasets and fields. It does not disclose any behavioral traits like pagination, limits, or side effects, but the tool is straightforward with no parameters and an output schema.

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

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

The description is two sentences, front-loaded with the main action, and each sentence adds value. It is concise and well-structured.

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 no parameters and an output schema, the description fully covers the tool's purpose and its relationship to consulta_libre. It is complete for a listing tool.

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

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

No parameters exist, and the schema coverage is 100%. The description does not need to add parameter info, so baseline score of 4 is appropriate.

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

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

The description clearly states it lists all available SECOP datasets and their search fields. It uses a specific verb+resource and explains the tool's utility, making it easy for an agent to understand its purpose.

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

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

The description provides context on when to use this tool, noting it is necessary for using consulta_libre. While it doesn't explicitly exclude alternatives, the usage guidance 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?

No annotations are provided, so the description carries full burden. It discloses a simplified view with truncated object, but does not explain search behavior, pagination, or if parameters are exact/fuzzy matches.

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

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

Two sentences, front-loaded with purpose, no fluff. Every sentence adds 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?

Provides overview purpose and output structure, but lacks guidance on parameter usage (dates, matching) despite 8 parameters with 0% schema coverage. Adequate for a summary tool but incomplete for effective invocation.

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

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

Schema description coverage is 0%, yet the description does not explain input parameters. It lists output fields but not input semantics, failing to compensate for the lack of schema descriptions.

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

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

The description clearly states it provides a condensed summary of contracts with key fields, and explicitly differentiates from sibling 'buscar_contratos_secop2' which gives full detail.

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

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

The description explicitly says 'Ideal para explorar resultados antes de pedir el detalle completo con buscar_contratos_secop2', providing clear usage context and a direct alternative.

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