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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description usefully adds what the agent cannot infer: the four-step pipeline (bidder trace, RPE cross-check, red-flag detection, legal opinion) and the legal basis (Art. 14 Ley 340-06, Art. 65 Dec. 543-12). It stops short of disclosing scanning depth, latency, or what happens when the process has no bids.

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

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

Front-loaded with the purpose sentence, then a tight four-item numbered breakdown that maps to real behaviors rather than padding. Slightly long, but every numbered item carries distinct information about what is checked and what is produced.

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 return burden and does so adequately: it names the deliverable (a dictamen legal with legal grounds for descalificación de oficio or impugnación) and the detection categories. It comes up short only on output structure and any caveats about coverage limits.

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% — both codigo_proceso and paginas are documented in the schema, including the default, min, and max for paginas. The description adds no parameter-level detail (no format guidance, no effect of raising paginas on recall), 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 (audita forensemente) and a narrowly scoped resource (las ofertas de un proceso, cruzadas contra el padrón RPE), then enumerates the exact red flags it looks for. This is clearly separable from siblings like dgcp_auditor_pliego_trampa (audits the tender document) or dgcp_radiografia_proveedor (single-provider profile) without opening any schema.

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

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

The description makes the use case evident ('detectar amarres o colusión' in a specific process), but never states when to prefer it over overlapping siblings such as dgcp_inteligencia_proceso, dgcp_auditor_pliego_trampa, or dgcp_generador_recurso_impugnacion. Usage is implied by scope rather than routed explicitly, and there are no exclusions or prerequisites (e.g. process must already have bids).

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/idempotent/non-destructive, so the safety profile is covered. The description adds useful behavioral content beyond that: it discloses that the tool also auto-drafts a Solicitud Formal de Aclaración y Enmienda, which is the only hint at output since no output schema exists. It omits detail on what happens when extracto_pliego is omitted.

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

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

Front-loaded with the core purpose, then a clean numbered enumeration of the four detection/response behaviors. Slightly verbose in restating legal citations, but every item carries distinct information and nothing is padded.

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

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

For a 2-parameter, no-output-schema tool, the description communicates both the analysis dimensions and the generated deliverable, which is what the agent most needs. Minor gaps remain around behavior when the optional pliego text is absent, but overall it is fit for purpose.

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 both parameters are already documented in the schema. The description adds no format, syntax, or usage detail for codigo_proceso or extracto_pliego, 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 verb+resource (auditar un pliego de condiciones) and enumerates exactly what it detects (Art. 21 Ley 340-06, exigencias desproporcionadas, subcriterios subjetivos) plus the artifact it produces. This clearly separates it from siblings like dgcp_auditoria_colusion (collusion) and dgcp_generador_recurso_impugnacion (appeal drafting).

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 scenario of use is implied by the enumeration of trap-clause types, so an agent can infer this is for suspecting a rigged pliego. But it never states when to prefer this over dgcp_auditoria_colusion or dgcp_generador_recurso_impugnacion, nor any 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely non-obvious behavior: the API fetches multiple pages and filters locally by termino/codigo/institucion/proveedor, which tells the agent that result completeness depends on the paginas argument — context no annotation supplies.

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

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

Front-loads purpose and payoff, then the local-filtering caveat, then a compact arg list. Every line carries information; only the 'Campos VERIFICADOS' aside is slight 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 fully-optional, read-only search tool with 100% schema coverage and annotations covering safety, the description adds the one thing the schema cannot: that filtering is client-side across a bounded page scan. It hints at returnable fields (montos, formas de pago, fechas) even without an output schema. Adequate, with only the exact result shape left 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 100%, so every parameter is already documented in the schema. The description only restates the argument names ('Args: termino, codigo_proceso, institucion...') without adding format, default, or interaction semantics beyond the schema. 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 verb (Consulta) and resource (contratos firmados y adjudicados por instituciones del Estado dominicano), and the resource noun alone distinguishes it from the licitaciones/ofertas/proveedores siblings. The parenthetical API endpoint reference (/contratos) reinforces the scope.

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

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

The description frames the payoff ('permite saber quien gano licitaciones anteriores, los montos...') which implies use cases, but never states when to pick this over dgcp_buscar_licitaciones or dgcp_buscar_ofertas, nor any exclusions. Usage is inferable, not explicit.

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

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

Annotations already cover the read-only/idempotent safety profile, and the description adds substantial non-obvious behavior: client-side filtering, multi-page scanning controlled by 'paginas' (default 5 = 500 processes), and most-recent-first ordering. This is exactly the kind of context that prevents misuse.

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

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

Well front-loaded with headers and bulleted state definitions; no filler. It is on the longer side, but the length is justified by a 10-parameter tool with nuanced API behavior.

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

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

For a tool with no output schema, the description usefully enumerates returned fields (codigo, institucion, estado, modalidad, monto, fecha de cierre, MIPYME, enlace), and all parameters are documented in the schema. An agent has what it needs to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: the precise meaning of 'abierto' (published AND future closing date), the generic-term pitfall for 'termino', and the default page size. It exceeds what the structured fields alone convey.

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

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

States a specific verb ('Busca') and resource ('procesos de compra publica del Estado dominicano'), and it is clearly distinguishable from siblings like dgcp_buscar_contratos or dgcp_buscar_proveedores. The title reinforces the scope without ambiguity.

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

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

Gives strong operational guidance: the API does not filter server-side, generic terms drop results, and recommends multiple calls with varied terms per topic. It also flags that 'abierto' is the desired state ~90% of the time. It stops short of explicitly routing the agent to sibling tools for related queries.

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 the safety profile is covered. The description adds genuinely new behavioral context: 'La API descarga varias paginas y filtra localmente' discloses that filtering happens client-side over a multi-page scan, which materially affects how results behave. The note that fields were verified against the real API signals reliability but is meta rather than behavioral.

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

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

Purpose and the local-filtering caveat are front-loaded and useful, but the trailing 'Args: termino, codigo_proceso, ...' enumeration merely restates parameter names already fully documented in the schema and earns no place. The 'Campos VERIFICADOS contra la API real' line is filler. Net result is adequate but with avoidable padding.

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

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

For a ten-parameter, zero-required filter tool with no output schema, the description covers what the tool returns conceptually and one important behavioral caveat. It does not clarify that all parameters are optional combinable filters, nor how defaults (limite 10, paginas 5) interact with local filtering. Adequate but with clear gaps for a tool of this parameter complexity.

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

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

Schema description coverage is 100%, so the schema already documents all ten parameters, setting a baseline of 3. The 'filtra localmente' / multi-page remark adds real semantic value for interpreting the paginas and limite parameters (paginas controls the fetched window, limite the returned count), which the schema alone does not explain. The redundant 'Args:' name list contributes nothing extra.

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

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

The description states a specific verb and resource: it consults proposals/offers submitted by suppliers and competitors in State purchasing processes, and names the underlying endpoint (/ofertas). It clearly distinguishes the resource from sibling lookups like licitaciones, contratos, and proveedores. It stops short of explicitly naming which sibling to use instead, so it lands at 4 rather than 5.

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

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

It offers concrete use cases ('analizar montos ofertados por competidores, estados de evaluacion y que empresas participaron'), which implies when the tool is valuable. However there is no explicit when-not guidance and no routing to alternatives such as dgcp_inteligencia_proceso or dgcp_auditoria_colusion, which overlap in the competitor-analysis space. Usage is implied rather than directed.

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 read-only, idempotent, non-destructive, and open-world behavior. The description adds useful behavioral context beyond annotations, notably that the API downloads multiple pages and filters locally, and that fields are verified against the real /proveedores endpoint. It does not cover auth requirements or rate limits, but the added behavioral detail is meaningful.

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 and then adds useful behavioral notes. The 'Args:' list is somewhat redundant given the 100% schema coverage, since it just repeats parameter names, but the overall text is concise and not bloated.

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 tool with full schema coverage and annotations covering safety, the description is mostly complete. It explains purpose, verifiable fields, and local pagination behavior. It does not explain the return shape, but no output schema exists and the search nature makes a detailed return description less critical.

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 all nine parameters with types, bounds, defaults, and examples. The description merely lists parameter names under 'Args:' without adding syntax, format, or interaction details beyond the schema. The baseline score of 3 applies when the schema carries parameter semantics.

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

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

The description states a specific verb and resource: consulting/searching companies and individuals in the RPE. It clearly distinguishes the resource (proveedores) from other sibling search tools, though it does not explicitly name or contrast alternatives. This is clear but lacks the sibling differentiation that would merit a 5.

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

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

Usage is implied through the listed verification capabilities (RPE, RNC, MIPYME, rubros, contact data, constancia oficial), but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as dgcp_radiografia_proveedor. The agent can infer the tool's role, but must decide context independently.

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 the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is low. The description adds genuine context: it is a deterministic legal computation producing illegality warnings ('detecta FRACCIONAMIENTO') and cent-precision figures grounded in Ley 340-06 and Decreto 416-23, which tells the agent what kind of result 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?

Purpose is front-loaded in the opening clause, then a numbered list maps cleanly onto distinct outputs with no filler. It is somewhat long, but each enumerated item (modality, illegality detection, the three guarantee types, deadlines) carries independent information.

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

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

There is no output schema, so the description must convey return content; it does so by enumerating the four result categories including specific percentages and the statutory basis. It stops short of describing the output structure or units (though DOP is implied by the schema), leaving a small gap for a computation 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 100%, so baseline is 3. The description adds value by tying parameters to behavior: es_mipyme is linked to the 1% vs 4% Fiel Cumplimiento rate, monto_estimado frames the Ley 340-06 thresholds, and modalidad_planteada is explained as the input used to validate correctness or detect fraccionamiento.

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 ('calcula las obligaciones legales exactas bajo la Ley 340-06') and enumerates the four concrete outputs (modalidad, fraccionamiento, garantías, plazos). This clearly distinguishes it from the buscar_*, generador_* and simulador_* siblings, which retrieve, generate, or score rather than compute obligations.

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 gives clear context for when the tool applies ('para cualquier presupuesto') and enumerates the situations it covers: validating modality, detecting fractionamiento as a causal de impugnación, and deriving guarantees/deadlines. It does not, however, name alternatives or exclusions relative to overlapping siblings such as dgcp_auditor_pliego_trampa or dgcp_generador_recurso_impugnacion, so routing still requires 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered and the description does not contradict it (generation appears to return content, not mutate state). The description usefully discloses the computed content — exact ITBIS 18% breakdown and a pre-submission checklist — but says nothing about return format (documents as text? PDF?) or whether the generated output is persisted anywhere.

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 verb and scope in the first clause, then a tight numbered list of deliverables with no filler sentences. The enumeration is long but each item is a distinct artifact, so every line 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 9-parameter tool with no output schema, the description covers what is produced but not what comes back or how the two optional parameters (tiempo_entrega_dias, descripcion_servicio) affect the generated documents. Adequate for invocation, but an agent still cannot predict the response shape.

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% across all 9 parameters, so the schema already carries full parameter meaning; the description adds nothing per-parameter. Baseline 3 applies. It does implicitly tie monto_ofertado_subtotal to the ITBIS calculation, but the 18% rate is the only semantic detail the description contributes 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) and a precisely scoped resource, then enumerates the five exact artifacts produced (SNCC.F.042, declaración jurada art. 14, carta formal, SNCC.F.033, checklist). It is immediately distinguishable from every sibling, which are all 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?

Usage is implied rather than stated: the agent can infer this is the tool to run when assembling an offer package for a DGCP process, and the checklist item hints at admissibility verification. There is no explicit 'use this when…' statement, no prerequisites (e.g. valid RPE, active process code), and no exclusion of alternatives.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about the generated output: legal foundations, formal sections (Calidad, Hechos, Derecho, Agravios, Petitorio), and the inclusion of a suspension request.

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 main action and then uses three numbered points to organize legal basis, document structure, and the suspension request. It is efficient and structured, though slightly list-heavy rather than narrative.

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 legal document generator with no output schema, the description gives enough context about the generated content and legal basis. It does not specify output format (e.g., text, PDF) or that it only drafts rather than files, but the title and 'Redacta' make the generation purpose sufficiently clear.

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%, with all six required parameters documented in the input schema. The description does not add any parameter-level meaning beyond what the schema already provides, so the baseline of 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 verb (Redacta), a precise resource (Recurso Jerárquico formal con Solicitud de Medida Cautelar de Suspensión de Oficio ante la DGCP), and the legal basis. It is clearly distinguishable from sibling generators such as 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?

The description implies that this tool is for drafting a formal challenge with a precautionary suspension request, but it does not explicitly state when to use it versus alternatives like dgcp_calculadora_legal or dgcp_auditor_pliego_trampa. Usage context is inferable from the legal document type rather than 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?

Annotations already disclose readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context — it is a multi-step workflow that auto-scans history, detects competitor pricing, and computes legal guarantees — but says nothing about latency/cost of the 12-page scan or any partial-failure behavior. Adds some value beyond annotations, not rich 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?

Front-loaded with the overall purpose, then a tight numbered list where each item is a distinct capability. Slightly long but every numbered point carries information; no filler 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?

No output schema exists, so the description carries the burden of telling the agent what comes back — and it does, enumerating ficha técnica, antecedentes, competitor prices, calculated guarantees, and strategy roadmap. For a composite tool this is reasonably complete, though return format/shape remains unstated.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the schema (codigo_proceso format examples, paginas_historial default/range). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 is correct.

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 ('análisis integral 360° de una licitación pública') and then enumerates the exact five sub-analyses it performs, which cleanly distinguishes it from the single-purpose siblings like dgcp_buscar_contratos or dgcp_calculadora_legal. An agent can tell this is an aggregating orchestration tool rather than a lookup.

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 enumerated steps imply when to reach for this tool (when a full 360° dossier is needed instead of individual lookups), and the mapping to siblings such as antecedentes/garantías is discernible. However, it never explicitly says when to prefer this over calling the individual tools, nor names any exclusion or prerequisite, leaving usage 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that figures come from 'la muestra reciente' (a sample, not the full universe) — but omits rate limits, output shape and any pagination 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 lead sentence front-loads the core action and the numbered list is a tight, scannable breakdown of the four outputs. Each line carries distinct information, though it is on the longer side for a two-parameter tool.

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

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

With no output schema, the enumeration of the four result blocks effectively substitutes for one and tells the agent what to expect. For a read-only aggregation tool this is nearly complete; only the sampling/pagination behavior of 'paginas' is left 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 100%, so both parameters are already documented, including the 'paginas' default mapping to ~1,500 contracts. The description adds no syntax or format guidance for 'termino' (accepted name/RNC/RPE formats) beyond what the schema states, 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?

The description states a specific verb ('Audita integralmente') and resource ('un proveedor o competidor') and then enumerates four concrete sub-tasks (RPE ficha, contract volume, top clients, margins). This clearly distinguishes it from single-query siblings like dgcp_buscar_proveedores or dgcp_buscar_contratos by framing it as a composite audit, though it never explicitly names an alternative.

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 targets a single provider/competitor and aggregates public-procurement data about them. However, there is no explicit statement of when to prefer this over dgcp_buscar_proveedores or dgcp_buscar_contratos, and 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=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this is a read-only analytical audit computing payment behavior, but discloses nothing about cost, latency, or data scope beyond what the schema's 'paginas' field states.

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 numbered list is well front-loaded with the action verb and each item earns its place by naming a distinct computed output. Minor marketing embellishment ('quirúrgicamente', 'asfixia financiera') adds flavor rather than information, keeping it just short of a 5.

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

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

With no output schema, the description carries the burden of conveying what comes back, and the four enumerated outputs (payment terms, disbursement methods, supplier concentration index, solvency rating) do that reasonably well. It is complete enough for a 2-parameter read-only analysis tool, though the exact return structure remains unspecified.

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 both parameters are already fully documented in the schema, including the 'paginas' default of 20 and the 'institucion' examples. The description adds no parameter-level meaning beyond that, so the baseline of 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 verb ('Audita') plus a precisely-scoped resource ('comportamiento comercial y de pago de cualquier institución del Estado') and enumerates four concrete outputs. This is clearly distinguishable from search-oriented siblings like dgcp_buscar_contratos, though it never explicitly names an alternative to differentiate itself.

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 enumeration of four outputs implies what the tool is for, but there is no explicit when-to-use guidance and no mention of when to prefer it over closely related siblings such as dgcp_radiografia_proveedor or dgcp_inteligencia_proceso. The agent must infer the fit from the described 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 establish readOnly=true, idempotent=true, destructive=false, consistent with a pure computation. The description adds real value beyond that: it discloses the exact formula, the five evaluated scenarios (90–98% of referential), and the output fields (gross margin in DOP, margin %, estimated total score, strategic recommendation). It stops short of describing assumptions/edge cases.

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

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

Front-loads the core formula, then lists the generated sensitivity matrix — well ordered with no filler. The inline formula line is slightly redundant for selection but is arguably the tool's defining feature, so it largely 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 read-only computation tool with no output schema, the description conveys what is produced (scenario matrix, margins, score, recommendation) and how it's derived. Only minor gaps remain, such as what happens when competitor prices are omitted or how ties/edge cases are handled.

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 defines all six parameters with defaults and bounds. The description references the formula variables (min valid price, offer price, economic weight) but adds no format, unit, or interaction detail beyond what the schema provides. 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 verb (calcula) and resource (precio óptimo / puntuación DGCP), and spells out the exact official formula used. An agent can distinguish it from search/list siblings and the generic calculadora_legal because it names the scoring/adjudication computation specifically.

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 (bidding strategy, price optimization) but never states when to choose this over siblings like dgcp_calculadora_legal or dgcp_inteligencia_proceso, nor any exclusions or prerequisites. Usage must be inferred from the stated output rather than explicit guidance.

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