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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and open-world. The description adds substantial value beyond those structured fields: it enumerates the specific detection flags, the external data sources consulted, and the legal basis, and notably cautions that results are 'indicios para verificar, no prueba' – a critical behavioral caveat about output interpretation that annotations do not convey. No output schema exists, so disclosing that results are indicators rather than proof is exactly the kind of context needed.

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 core action, followed by a compact list of flags and the legal basis. It is dense but every clause (sources, flags, legal articles, indicator disclaimer) earns its place without 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 read-only analysis tool with no output schema, the description covers the data sources, the concrete signals examined, the legal grounding, and the interpretation caveat. The main residual gap is that it does not sketch the structure of the audit report returned, though the indicator disclaimer partially compensates.

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

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

Schema coverage is 100% with only one required parameter, and the schema already documents codigo_proceso as the official process code. The description adds no new syntax or format detail beyond what the schema provides, so the baseline 3 is appropriate.

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

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

States a specific verb and resource: it audits all offers in a process, cross-referencing each bidder against its official RPE record and the DGCP disqualified list. This is clearly distinguishable from siblings like dgcp_buscar_ofertas or dgcp_radiografia_proveedor, which are lookup tools rather than cross-analysis of an entire process.

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 it applies (forensic collusion audit for a process) but does not explicitly state when to use it versus alternatives such as dgcp_inteligencia_proceso or dgcp_radiografia_proveedor, nor does it state exclusions or prerequisites.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by stating that it generates a clarification request ready for the portal inbox and that pasting the pliego extract enables a complete analysis.

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 core purpose, then uses a tight bullet list to detail legal checks before closing with an input instruction. Every sentence contributes useful information, and there is no redundant or filler content.

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 complex legal-audit tool with no output schema, the description explains what it checks, the legal basis, and the expected output (a clarification request). It is nearly complete, though it does not describe the return format or any limitations of the analysis beyond the input guidance.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds meaning for 'extracto_pliego' by explaining that it should contain the PDF's specifications and that providing it enables a complete analysis; 'codigo_proceso' is left to the schema.

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

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

The description uses a specific verb and resource: reviewing a process for signs of a directed tender ('pliego dirigido') or improper barriers. It enumerates the exact legal checks (trademarks, exclusivity, subjective criteria, deadlines), which clearly distinguishes it from sibling tools such as dgcp_auditoria_colusion or dgcp_generador_recurso_impugnacion.

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

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

It gives clear context for when to use the tool: auditing a procurement process for directed-tender signals, and it instructs the agent to paste the pliego extract for complete analysis. However, it does not explicitly name when not to use it or point to alternative sibling tools for related tasks.

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?

Con readOnlyHint=true, destructiveHint=false e idempotentHint=true ya declaradas, la descripción añade detalles no cubiertos por anotaciones: que ciertos filtros son exactos en servidor, que institucion se resuelve a código oficial, y la limitación de la API (solo ~3,000 contratos recientes sin filtro). No menciona paginación ni formato de salida, pero cubre bien las restricciones clave.

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?

Dos frases bien estructuradas, con la información de filtros exactos y la advertencia de cobertura limitada colocadas en orden de importancia. No hay relleno y cada oración aporta información operativa.

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?

Para una herramienta de solo lectura con 9 parámetros opcionales, sin esquema de salida, la descripción cubre lo esencial: qué devuelve, qué filtros son exactos y la limitación de la API. Queda un pequeño vacío sobre los parámetros de rango de monto y el parámetro limite, pero no impide el uso correcto.

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 del 78%, lo que da una base alta. La descripción añade valor semántico al aclarar que codigo_proceso, rpe e institucion son filtros exactos en servidor y que institucion se resuelve a su código oficial, información que el esquema solo insinúa. Sin embargo, no cubre monto_min/monto_max, estado_contrato ni limite.

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 (buscar) and resource (contratos adjudicados/firmados por el Estado) y enumera los datos que devuelve (quién ganó, cuánto, cuándo, forma y plazo de pago). Se distingue claramente de hermanos como dgcp_buscar_licitaciones u dgcp_buscar_ofertas.

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?

Explica cuándo usar filtros exactos y advierte que sin esos filtros solo se analizan los ~3,000 contratos más recientes porque la API no filtra por fecha ni por texto. No nombra explícitamente alternativas (p.ej. dgcp_inteligencia_proceso), pero da contexto operativo suficiente para elegir parámetros.

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

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower; the description still adds real behavioral context: 'abierto' pulls the COMPLETE universe rather than a sample, institucion is server-side resolved to an official code, ordering defaults, and that times are in RD timezone. It stops short of mentioning rate limits or pagination of results.

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 behavior, then bulleted filters, then the sibling-routing line last. Each bullet earns its place and nothing is redundant with the schema or annotations.

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

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

For a 13-parameter search tool with no output schema, the description covers defaults, filter quirks, ordering, timezone, and routing. It does not describe the shape of returned results, which leaves a modest gap even though no output schema exists to cover 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 100%, so baseline is 3, but the description contributes semantics beyond the schema: 'termino' accepts comma-separated alternatives matching any, institucion resolves to the purchasing unit code, and the default orden. This meaningfully enriches how parameters should be used.

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: searching Dominican State public procurement processes via DGCP API filters. It also explicitly distinguishes itself from dgcp_ultimas_licitaciones, so an agent can route 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 names the alternative for recency queries ('para la ultima licitacion o lo nuevo de hoy usa dgcp_ultimas_licitaciones') and explains default behavior for estado and orden. It does not address other potentially confusable siblings like dgcp_buscar_contratos or dgcp_buscar_ofertas, so it falls short of full when-not coverage.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuine non-obvious context: exact server-side filtering semantics for codigo_proceso and rpe, and the data-quality caveat that estado_evaluacion is almost always 'Pendiente' so the winner must be read elsewhere. Return format and pagination limits are not described.

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

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

Three tight sentences: what the tool returns, the two key filters, and the critical caveat. Front-loaded and free of 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 nine-parameter read-only search with no output schema, the description covers purpose, the two highest-value filters, and an important evaluation-status gotcha. It could note result ordering/defaults and how monto/proveedor/institucion narrow results, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 78%, so the schema already documents most parameters. The description reinforces codigo_proceso and rpe behavior (exact server filter, returns ALL matches) but says nothing about orden, limite, termino, monto_min/max, proveedor, or institucion beyond what the schema states, so baseline 3 fits.

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 ('Ofertas que las empresas presentaron en procesos de compra') and even summarizes the payload ('quien compitio y a que precio'). It distinguishes itself from the sibling dgcp_buscar_contratos by naming it as the place to find the actual winner, so an agent can route without opening schemas.

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 when-to-use routing: codigo_proceso returns all bids for one process, rpe returns all bids for one company, and points to dgcp_buscar_contratos when the winner is needed. It does not cover when NOT to use this tool versus other search siblings (licitaciones, proveedores), so it stops short of explicit exclusions.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds real behavioral context: exact server-side matching for identifiers, name lookup inferred from recent contracts and bids, and a flag for officially disqualified or suspended suppliers. It omits pagination/limit behavior, but that is a minor gap given the 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?

Three sentences, front-loaded with the record contents, then search mechanics, then the disqualification warning. Mostly efficient, though the opening field enumeration is somewhat list-like 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?

For a 6-parameter, zero-required lookup with no output schema, the description usefully describes returned fields and search modes. However, it never explains how to call the tool when no identifier is supplied or how multiple matches are handled, leaving a real gap for a tool with all-optional 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 coverage is 83%, so the schema already documents most parameters (rnc, rpe, estado, termino, provincia). The description adds the server-side exact-match semantics for numeric lookups and the name-resolution heuristic, but says nothing about 'limite' or the provincia-requires-estado constraint. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Buscar proveedores' in the Registro de Proveedores del Estado) and enumerates the fields returned (RPE, RNC, estado, MIPYME/MICM, rubro, ubicacion, contacto, constancia). It is clearly a registry lookup, but it never distinguishes itself from the sibling dgcp_radiografia_proveedor, which also profiles suppliers.

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

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

Explains the two search modes (exact RPE/RNC on the server vs. name resolved through recent contract/bid activity), which implies usage but not when to prefer this tool over dgcp_radiografia_proveedor or other supplier-oriented siblings. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds meaningful beyond-annotation context: it names the exact legal sources and thresholds version (Resolución PNP-03-2026) and the specific article references (Art. 101, 81), so an agent knows which rulebook is applied. It doesn't describe output format or unit assumptions, keeping it below 5.

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

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

A single front-loaded sentence plus a compact numbered list of outputs — efficient and structured. Slightly dense with legal citations, but no wasted sentences.

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

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

For a read-only calculator with 4 well-covered params and no output schema, the description gives enough: it enumerates what will be computed and the legal basis. It stops short of describing return shape (fine, no output schema) and of usage routing, so not a 5.

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

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

Schema description coverage is 100% (every param documented, enum on tipo_objeto), so the baseline is 3. The description references the budget input and the modality-verification logic, but adds no new meaning beyond what the schema already states for es_mipyme / modalidad_planteada.

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 computational action (calculate, based on Ley 47-25, Dec. 52-26 and 2026 thresholds) for a given budget, and enumerates the three concrete outputs (modality + minimum deadline, possible fractionalization, guarantee percentages). This clearly differentiates it from siblings like dgcp_simulador_puntuacion or dgcp_buscar_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 inputs imply when it applies (you have a budget and want modality/plazo/garantías), but there is no explicit statement of when to use this vs. alternatives, no prerequisites, and no exclusions. Usage is only inferable from the listed outputs.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description still adds meaningful behavior: the output is explicitly a draft requiring completion on official pliego forms, and legal-article-conditional adjustments (Arts. 38-39, 174-175 Ley 47-25) are disclosed. It does not describe the output's format or whether anything is persisted, which keeps it from a 5.

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

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

Three tight sentences that lead with what gets generated, then the conditional MIPYME logic, then the draft caveat. The document enumeration is long but every item is load-bearing information about the output, so it stays dense rather than padded.

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

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

For an 11-parameter, 7-required generator with no output schema, the description does the important work: it identifies which documents come back and warns that the result is an incomplete draft. What is missing is the shape of the return (plain text, file link, structured sections) and any note on how the optional ITBIS/MIPYME flags change the generated content.

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 64% and the description names no parameters directly. It does implicitly map conceptual inputs onto two optional parameters (es_mipyme via the MIPYME adjustment clause, aplica_itbis via the ITBIS reference), and 'datos reales del proceso' gestures at codigo_proceso, but the remaining required fields like rnc, rpe and cedula_representante get no added meaning beyond the schema.

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

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

States a specific verb (genera borradores) and enumerates the exact artifacts produced: carta de presentación, declaración jurada de inhabilidades, oferta económica con ITBIS y checklist del expediente. This clearly separates it from every sibling, all of which are search/analysis tools rather than document generators.

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

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

It gives useful context (a draft to be completed, built from real process data and the pliego's standard forms) and conditions the guarantee/advance calculations on MIPYME status. However, it never states when to reach for this tool versus alternatives such as dgcp_calculadora_legal or dgcp_simulador_puntuacion, and offers no exclusions or prerequisites, leaving route selection implicit.

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

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

Annotations mark it readOnly/idempotent/non-destructive, consistent with a drafting/calculation tool. The description adds real depth beyond annotations: deadline computation (10 dias habiles per Arts. 204-205/207-208), the warning that recursos do not suspend the act (Art. 201), and the Ley 340-06 notice behavior. However it doesn't clarify output format or whether missing fecha_notificacion yields an error or skipped calculation.

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 single verb phrase followed by a tight bulleted breakdown of the three recourses with articles and deadlines. Every bullet earns its place by adding legal specifics an agent would need; 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 drafting tool with 11 params, 6 required, no output schema and no return-value info, the description is quite complete on legal behavior. Remaining gaps: no explanation of what documento is produced or how output is structured, which matters since there is no output schema.

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

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

Schema coverage is 73%, and the schema already documents key params (tipo_recurso enum, fecha_notificacion pattern, incluir_medida_cautelar, hechos, agravios). The description reinforces the tipo_recurso semantics and the fecha_notificacion deadline use, but adds no new meaning for the undocumented params (rpe_recurrente, rnc_recurrente). Baseline 3 fits.

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 (Redacta/redacta el recurso) and resource (recurso administrativo bajo Ley 47-25), and distinguishes the three recourse types with their scope and governing articles. Clearly differentiated from sibling tools like dgcp_calculadora_legal or dgcp_generador_propuesta_sncc.

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

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

Explains each recourse type's sequence (reconsideracion primero y obligatorio, jerarquico impropio contra su decision, medida cautelar como instancia separada) and deadlines, giving a clear map of when each applies. Lacks an explicit 'do not use this when...' exclusion, but the sequencing is strongly implied.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real value beyond that: it discloses the response content (countdown, UNSPSC line items, direct document links, awarded contracts) and that computed legal checks such as the Art. 101 minimum term and possible fraccionamiento are performed — but says nothing about cost, latency, or partial-failure behavior for a call that fans out to many queries.

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 one sentence, then a numbered list of the returned sections. The list is long but every item is load-bearing, since there is no output schema to describe the payload; minor verbosity in the legal-regime phrasing.

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 correctly compensates by enumerating what the dossier contains, which is exactly what an agent needs to decide the call is worthwhile. It is close to complete; only the absence of any note on response size or when partial data may be missing keeps it from a 5.

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

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

Schema description coverage is 100% and there is a single parameter, so the schema (with format example 'MIP-CCC-LPN-2026-0005') already carries the parameter burden. The description adds no syntax, validation, or lookup guidance beyond what the schema provides — baseline 3.

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

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

States a specific verb and resource — 'Arma el expediente completo de una licitacion en una sola llamada' — and then enumerates the seven sections it assembles. The 'una sola llamada' framing distinguishes it from the narrow sibling lookups (dgcp_buscar_licitaciones, dgcp_buscar_contratos, dgcp_buscar_ofertas) that this tool aggregates.

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

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

Usage is implied rather than stated: the agent can infer this is the one-shot dossier builder versus the single-purpose siblings, but there is no explicit 'use this when you need everything at once; use X when you need only offers' routing. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint/openWorldHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: results are sorted by nearest closing date and it reports the percentage of open processes covered. It does not mention rate limits or result format, but adds meaningful traits over the annotations.

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

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

A single dense paragraph, front-loaded with the core question it answers, followed by mechanism and differentiator. Every sentence carries information, though it is a fairly long run-on block that could be broken up.

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

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

No output schema exists, so the description must convey return behavior; it does so by stating ordering (nearest closing) and coverage reporting. With 6 parameters and 0 required, it explains the main default flow (RPE-derived rubros), though it does not spell out defaults for limite or behavior when no codes/RPE are resolvable.

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 83% (high), so the baseline is 3. The description goes further by explaining the relationship between the RPE-based auto-selection and manually supplied codes ('Toma TODOS los rubros UNSPSC registrados de tu empresa en el RPE (o los codigos que indiques)'), clarifying how rpe_o_rnc and codigos_unspsc 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?

States a specific verb+resource+scope: 'licitaciones ABIERTAS ahora mismo puedo ofertar' by crossing registered UNSPSC rubros against recently published processes still receiving offers. It also contrasts itself with a word-based search ('encuentra oportunidades que una busqueda por palabras pierde'), which distinguishes it from search-style siblings.

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

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

Frames usage around the question 'which open tenders can I bid on now' and implicitly excludes keyword-search approaches by noting it finds what word searches miss. However, it does not explicitly name an alternative sibling (e.g. buscar_licitaciones vs ultimas_licitaciones) or state when-not-to-use, so it falls short of full explicit guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful content context (the plan is forward-looking, fields returned) but says nothing about pagination, result caps implied by 'limite', or data freshness. Adequate but not rich beyond annotations.

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

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

Two sentences, front-loaded with the core resource definition. The field enumeration is long-ish but earns its place because there is no output schema, so it tells the agent what comes back. Minor redundancy, otherwise tight.

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, describing the returned fields (description, budgeted amount, modality, start date, MIPYME flag) is exactly the right compensation, and annotations carry the safety profile. The remaining gap is behavioral: the 'limite' parameter and result-capping are unexplained anywhere.

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 75% (anio, termino, institucion documented; limite bare). The description does not touch any parameter - it only lists returned fields - so it adds no meaning beyond the schema. With high-ish coverage, the baseline 3 is correct and it doesn't compensate for the undocumented 'limite'.

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

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

Names a specific resource (the published PACC / annual procurement plan) and its content, with a clear verb sense of 'what the institution PLANS to buy.' The closing line 'Permite anticiparse a las licitaciones antes de que se publiquen' differentiates it from the licitaciones/contratos siblings, which cover already-published events.

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 anticipation framing ('anticiparse a las licitaciones antes de que se publiquen') clearly signals when to reach for this tool - for forward-looking planning rather than searching published tenders. It stops short of explicitly naming an alternative sibling or stating when NOT to use it, so it's not a 5.

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

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

Annotations already establish readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description still adds behavior beyond them: results are computed over 'los contratos más recientes' (a recency window, not all history) and the response includes concrete examples with institución, proveedor and fecha — useful since there is no output schema. Rate limits or caching behavior are not 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?

Two tightly packed sentences, front-loaded with the core action and price statistics before the use-case justification and the prerequisite pointer. No filler, though the first sentence is long and could be split for faster scanning.

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 usefully outlines the returned content (per-unit-of-measure statistics plus institution/supplier/date examples) and the scope over recent contracts. It leaves the exact aggregation window and result cardinality unspecified, but an agent has enough 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 100% and every parameter (termino, codigo_unspsc, unidad_medida) is documented in the schema with format hints and examples. The description adds no parameter-level syntax or defaults beyond that, so the baseline 3 applies.

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

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

States a specific resource and scope: unit prices the State actually paid for a given UNSPSC code, with named statistics (mínimo, p25, mediana, p75, máximo) broken down by unit of measure. It is clearly distinguishable from siblings like dgcp_buscar_contratos or dgcp_inteligencia_proceso, which are referenced as the source of UNSPSC codes rather than as competing price 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 concrete use cases ('fijar el precio de una oferta o detectar sobreprecios') and tells the agent where the required codigo_unspsc comes from ('salen en dgcp_inteligencia_proceso'), which routes the workflow correctly. It stops short of explicit when-not-to-use conditions or a named sibling for an alternative price source.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so safety is covered. The description adds real value on the read side with no output schema present: it discloses the returned payload (total contract amount, main clients, latest contracts, win/bid success rate, disqualification alert). It omits ambiguity behavior (what happens if a name matches several companies) and any limits on volume.

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 front-loaded sentence with a colon-delimited payload list; every clause names actual output content rather than filler. It is dense but nothing is redundant, and the purpose precedes the enumeration.

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 carries the burden of describing the return shape and does so thoroughly across ficha, alerts, rubros, contracts and bids. Gaps are minor: no mention of how ambiguous name matches are resolved, pagination, or freshness of the underlying data.

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

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

Schema description coverage is 100% for the single parameter, so baseline is 3. The description restates 'RPE, RNC o nombre' almost verbatim from the schema and adds no format rules or disambiguation semantics for the free-text name path, which is the one genuinely ambiguous input.

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 (a state supplier) and an exact input key (RPE, RNC or name), then enumerates what the profile contains: RPE record, suspension alert, UNSPSC rubros, contracts and bids. That enumeration implicitly separates it from single-facet siblings like dgcp_buscar_contratos or dgcp_buscar_ofertas, but no sibling is named explicitly, so it stops short of a 5.

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

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

Usage is only implied: the 'complete and exact profile of a company' framing suggests a per-supplier aggregate lookup, which is the obvious reading next to 16 sibling tools. There is no explicit statement of when to prefer this over dgcp_buscar_proveedores (search) or the individual contract/bid search tools, and no prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds value by disclosing the concrete contents of the profile (payment-term vs legal 30-day limit, top-5/HHI concentration, MIPYME quota, modality mix, Art. 101 timeline audit), which tells the agent what behavior to expect beyond a generic 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?

Front-loaded with a one-line purpose followed by a compact bullet list of the four computed dimensions; every bullet carries distinct information. Slightly dense but 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?

With no output schema, the description usefully compensates by itemizing what the scorecard contains. For a read-only, single-parameter tool it is essentially complete; only the choice among sibling analytical tools is left unaddressed.

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

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

With a single parameter and 100% schema description coverage, the schema already documents that the field accepts name, acronym or code, with examples. The description's 'filtro por su codigo oficial de unidad de compra' arguably narrows this to codes only, adding little and slightly under-describing the actual flexibility.

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 analytical artifact (a purchasing/payment profile) and enumerates its dimensions, so an agent knows exactly what this tool produces. It does not, however, name or differentiate itself from the obvious sibling dgcp_radiografia_proveedor (the supplier-side analog), so it stops short of full sibling disambiguation.

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: it is a per-institution analytical scorecard, and the parenthetical tells the agent how to target it (official purchase-unit code). There is no explicit 'use this when...' statement and no mention of when a sibling such as dgcp_inteligencia_proceso or dgcp_radiografia_proveedor would be the better choice.

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

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

Annotations already establish a safe, idempotent, closed-world read, so the description's job is to add substance. It does: it discloses the exact scoring formula, the 85%-100% search band, what each scenario returns (margin and total score), and that the recommendation respects the user's minimum margin — none of which is visible in the schema or annotations.

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

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

Three sentences, front-loaded with the core action and formula, followed by the output/recommendation, then the sibling routing and the verification caveat. No filler and nothing redundant with 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?

For a 7-parameter tool with no output schema, the description compensates by describing the return content (per-scenario margin and score, plus a recommendation) and the scoring logic. All inputs are documented in the schema, so the agent has what it needs to call this 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 100%, so baseline is 3, but the description adds real meaning about how inputs are used: the scenario band relates to monto_referencial, and it tells the agent where precios_competidores values should come from rather than being invented. It does not clarify peso_economico vs peso_tecnico interaction, so it is not a full 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?

Names a specific verb and artifact: it simulates price scenarios between 85% and 100% of the budget using the inverse-proportionality formula, and outputs margin plus total score per scenario with a recommendation. It also distinguishes itself from siblings by pointing at dgcp_buscar_ofertas and dgcp_precios_referencia as the tools for real rival prices.

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

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

Explicitly routes the agent: 'Para precios rivales reales usa dgcp_buscar_ofertas ... o dgcp_precios_referencia', which tells it when this simulator is the wrong source of data. It also warns to verify the exact formula in the pliego, but does not state when the simulator should be skipped entirely.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context the annotations do not: the DGCP data-refresh cutoffs (00:00, 07:00, 14:00, 21:00) and the resulting lag for anything published after the last cutoff. It does not cover pagination or result-size 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?

Three tight sentences: capability and ordering, usage triggers, then the data-freshness caveat. Nothing is padding, and the most decision-relevant information (what it returns and the recency scope) is front-loaded.

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

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

For a six-parameter, zero-required read tool with no output schema, the description covers purpose, triggers, ordering and the important data-lag caveat. Return-content hints (date/time and time remaining to bid) partially compensate for the missing output schema; nothing critical is absent, though pagination/size behavior is left to the schema.

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

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

Schema description coverage is 100%, so the six parameters are already fully documented in the schema, establishing the baseline of 3. The description adds no syntax, defaults, or interaction details beyond the schema (its mention of ordering and cutoffs is not parameter-related).

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 ('Devuelve lo ULTIMO publicado en compras publicas de RD') plus the ordering ('del mas reciente al mas antiguo') and returned fields. It implicitly distinguishes itself from the dgcp_buscar_licitaciones search sibling via the recency framing, 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?

Provides concrete trigger phrases in quotes ('dame la ultima licitacion', 'que salio hoy', 'lo nuevo de esta semana') that map cleanly onto recency-intent queries. It gives clear when-to-use context but no explicit when-not-to-use or named alternative, so it stops short of a 5.

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