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

Annotations only declare it is a mutation, idempotent and open-world. The description goes well beyond that: which mode installs nothing on the machine, which one creates a Windows task, which one changes system configuration and writes the ticket to a user-folder file, and the explicit user-consent requirement before passing confirmo=true. No contradiction with 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?

Front-loaded with the core action, then structured bullets per mode, ending with the criteria caveat. It is longer than average but every line carries operational weight for a high-stakes system change; only slight trimming is possible.

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, yet the description covers the mutation semantics, the consent prerequisite, the side effects per mode, and the dependency on configurar_criterios. An agent has everything needed to invoke it correctly and safely.

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% and the enum descriptions are thin ('Dónde corre la vigilancia'), so the description adds real meaning: it explains what each enum value actually does and clarifies that confirmo is only valid for «siempre» and only after an explicit yes. It goes past the schema without restating it.

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 pair (encender/apagar) and resource (vigilancia de compras nuevas), then names all three modes with distinct behavior. An agent can tell exactly what this does and how it differs from siblings like estado_vigilancia or configurar_criterios.

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

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

Gives explicit when-to-use guidance per mode: «con_claude» is 'recomendado para empezar', «siempre» requires explaining the system change and an explicit 'sí', «apagar» stops it. It also routes the agent to the sibling configurar_criterios and warns to review default criteria first.

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

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

With only readOnlyHint/openWorldHint available, the description carries real behavioral weight: it discloses that only quoted (not awarded) prices are analyzed, that data comes almost exclusively from DESIERTOS processes (with measured counts), why that is still valid signal, and that inadmissible quotes are included with a separate comparison field. This is exactly the kind of beyond-annotation context the dimension rewards.

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

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

Front-loaded purpose sentence followed by return summary and a clearly enumerated limitations block. It is longer than most definitions, but each limitation is substantive and earns its place; only minor tightening is possible.

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 supplies the return shape (min, p25, median, mean, max plus per-quote detail) and the auxiliary admisibles-only distribution. Combined with quota/latency notes and data-provenance caveats, an agent has everything needed to call and interpret this complex 6-parameter 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 the baseline is 3. The schema already documents codigo_compra keyword extraction, region scoping semantics, and limite_analisis quota/timing behavior, so the description adds little parameter meaning beyond what is structured.

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 ('analizar a qué precios está cotizando el mercado en procesos históricos de Compra Ágil similares') plus the goal ('posicionar una oferta competitiva'). This clearly separates it from siblings like buscar_compras_agiles (search) and auditar_compras_desiertas (audit), 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?

Explains the two input modes (active purchase code with automatic keyword extraction, or a search term) and the intended context for using the tool. It does not name a sibling as an alternative or state when NOT to use it, so it stops short of the top band.

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 only declare readOnlyHint and openWorldHint, so the description carries the interesting burden — and it does so well, disclosing that comparison uses QUOTED not awarded prices because the API does not expose the winner, and that it surfaces the official deserción reason plus inadmissible quotes. Quota/perf costs are covered in the schema rather than the description, leaving a small gap.

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, then input modes, then the crucial methodological caveat, then the return content. Every sentence contributes, though the NOTE and final sentence overlap somewhat in explaining why the failure info matters.

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 5-parameter, no-output-schema audit tool, the description covers purpose, inputs, comparison methodology and its empirical limitation, and what the response reports (official reason, inadmissible quotes). Nothing essential is missing.

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

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

Schema description coverage is 100% and the parameter docs are already rich (limite_analisis even documents the 504s and parallel-call behavior). The description restates the code/search-term option but adds little semantic detail beyond the schema, 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 ('Audita un proceso de Compra Ágil que haya quedado desierto') and adds the goal (identify why it failed) plus the method (comparison against market-quoted prices). It is readily distinguishable from siblings like analizar_precios_mercado and buscar_compras_agiles.

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 input modes (purchase code or search term for a recent failed process) and clarifies the comparison basis, which helps an agent situate the tool among pricing-oriented siblings. It does not name a specific alternative or state explicit when-not conditions, 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.

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

Annotations (readOnlyHint, openWorldHint) already cover safety, but the description adds substantial operational detail: HTTP 400 for oc_emitida, HTTP 504 for wide filters/page 50, which estados return rows, Chile timezone handling, and caveats that motivo_seleccion and ofertas_recibidas can be misleading. This is exactly the kind of context annotations cannot supply.

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 return shape are front-loaded, and nearly every sentence carries useful constraints. It is on the long side with multiple stacked 'Nota:' style caveats, but they are actionable rather than filler. Minor density cost only.

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

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

With no output schema, the description supplies the return contents (code, name, estado, presupuesto, institución) plus downstream caveats about ofertas fields. For an 11-param open-world search tool, nothing an agent needs to call it correctly appears to be missing.

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

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

Schema coverage is 100%, so a 3 is the baseline, but the description adds meaning beyond the schema: the mutual exclusivity of q/id, region code semantics (1-16, examples), and the implicit-but-critical rule that no required param exists yet at least one API filter must be sent. That compensates for the schema's zero-required-params gap.

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') plus resource ('procesos de Compra Ágil en Mercado Público de Chile') and names the return shape (resumido list with código, nombre, estado, presupuesto, institución). This clearly distinguishes it from detail-oriented siblings like obtener_detalle_compra. An agent can tell what it does without opening the schema.

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

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

Gives explicit conditions and constraints: at least one API filter must be sent or 'esta herramienta no hace la llamada', q and id are mutually exclusive, and local keywords are applied after the response. It also routes to obtener_detalle_compra as the authoritative source for ofertas. Both when-to-use and when-not-to-use are spelled out.

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 only say readOnlyHint=false, openWorldHint=true, idempotentHint=false; the description carries the real behavioral payload — an authentication handshake, the bot-token prerequisite, exactly where the token is configured (Claude Desktop extension settings vs. --configurar), and the hard rule never to request the token in chat. This is precisely the contextual disclosure annotations cannot supply.

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 numbered steps front-load the happy path, followed by the trust warnings and token-configuration fallback. It is long but nothing is redundant — each clause either constrains invocation or prevents a failure mode.

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 state-mutating, open-world tool with no output schema, the definition covers everything an agent needs: the sequence, the auth prerequisite, where to fix a missing prerequisite, and the safety rules. Nothing required for correct invocation is missing.

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

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

Schema coverage is 100%, so the 6-digit pattern is already documented. The description nonetheless adds genuine meaning the schema cannot: the omission of «codigo» triggers a fresh code to the most recent bot chat, and the value must originate from the user's own Telegram rather than from any other text, which is a trust constraint on the parameter's provenance.

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+resource: connecting the user's alert notifications to their Telegram, and even explains the two-step mechanism (send 6-digit code to most recent chat, then confirm with «codigo»). The purpose is unmistakable, but it never contrasts itself with siblings such as probar_avisos, configurar_criterios or activar_vigilancia, so an agent gets no explicit routing signal.

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 spelled out step by step: call with no argument first, then call again with «codigo» once the user reports it. It also states clear when-not conditions (do not invent or guess the code, do not accept a code appearing in purchase text). No alternatives among the sibling tools are named, which keeps it 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.

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

Annotations declare this is a mutation (readOnlyHint=false) and idempotent, so the safety profile is covered. The description adds genuine value beyond that: it discloses that every change is broadcast to configured channels with before/after values, that destinations are deliberately left untouched, and that partial updates preserve unchanged criteria.

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 purpose and enumerated fields, then adds the reset and notification semantics. Two dense but purposeful paragraphs with 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?

For a mutation tool with no output schema and 0 required parameters, the description covers the important gaps: partial-update behavior, the reset path, notification side effects, and what is not affected. Annotations plus the schema fill in the rest, so an agent has enough to invoke it safely.

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 88%, so the schema already documents nearly all parameters with their ranges and defaults. The description reinforces several fields (palabras, excluidas, regiones, presupuesto, todas_en_region) but adds little syntax or constraint detail beyond what the schema already states, matching the 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 ("Cambia") and resource ("qué procesos alerta la vigilancia") and enumerates the exact fields it controls. An agent can distinguish this configuration tool from siblings like activar_vigilancia or estado_vigilancia without opening the schema.

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

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

It clarifies partial-update semantics ("Lo que no se indica queda como estaba") and the reset behavior of restablecer, which is practical usage context. However, it names no alternatives or when-not-to-use conditions versus the many sibling tools, leaving the routing decision 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 already carry idempotentHint=true, so the 'calling twice changes nothing' sentence is partly redundant, but the description still adds real value by naming the state change (delivered) and its consequence (the batch is no longer offered). It does not cover auth/permission needs, but that is a minor gap for such a narrow mutation.

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 short sentences, zero waste, with the action and its effect front-loaded before the idempotency note.

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

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

For a one-parameter mutation with no output schema and annotations covering safety/idempotency, the description supplies everything an agent needs: what it does, the source of the input, and the resulting effect.

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 the single lote_id parameter is already documented with its pattern and origin. The description restates lote_id's source but adds no format or syntax detail beyond the schema, so 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 (marca como entregado) and a specific resource (un lote de obtener_alertas_nuevas), and ties the tool to the producer of that batch. An agent can distinguish it from siblings like obtener_alertas_nuevas 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?

Makes clear the context of use: consume a batch returned by obtener_alertas_nuevas so it is not offered again. It names the related tool and the goal, though it does not state an explicit when-not-to-use or an alternative confirmation path.

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 (readOnlyHint=true, openWorldHint=false, consistent with a purely local read). The description adds real behavioral detail beyond them: at most 3 files returned, omitted files are named, and a low-relevance warning is emitted when no fragment matches at least half the query terms. It stops short of describing relevance ranking beyond that threshold.

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 search action and its scope are front-loaded, followed by result-cap behavior and then the priority rules; no sentence is redundant. It is somewhat long and dense, but each sentence carries distinct guidance, so the size is justified.

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 compensates by explaining the return shape (max 3 files, named omissions, low-match warning) and the trust ordering of sources. Combined with annotations covering safety and the fully documented schema, an agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 100% and the query parameter already documents accepted input forms, accent/stopword handling, and the list-all behavior when omitted. The description does not add parameter-level meaning 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?

States a specific verb and resource (search in local manuals/guides under docs/ with supported formats), which clearly separates it from fetching/downloading tools run by siblings like descargar_y_leer_documento. It does not name an alternative sibling explicitly, so an agent must infer the boundary from the 'locales' scope rather than being routed directly.

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

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

Gives explicit routing rules: server/API questions prioritize the server manual because it reflects measured behavior, business questions (deadlines, fines, requirements) defer to the guides, and it warns that the official ChileCompra guide describes the promised API and may contradict the manual. This is exactly the when-to-use/when-to-trust guidance an agent needs.

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 and openWorldHint, so safety of the read is covered. The description still adds real behavioral value: the accepted formats (PDF/DOCX/DOC/XLSX/CSV/ZIP), how multiple attachments are disambiguated, and a prompt-injection warning that the buyer-authored text must be treated as data, not instructions. It does not mention failure modes such as scanned PDFs with no extractable text.

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, front-loaded with what is returned and in which formats, then the minimal call pattern, then the safety caveat. No redundant restatement of the name or schema fields.

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 tool with no output schema and six fully documented parameters, the description covers purpose, formats, default selection and a security caution. It could have noted return structure (the response indicating the next character offset is only implied via the schema), but nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds cross-parameter semantics the schema does not: with only codigo_compra it reads the first attachment and enumerates the rest, which explains the interaction between id_documento, nombre_adjunto and the required code.

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 concrete verb+resource (descarga un adjunto de una Compra Ágil) plus the output (entrega su texto) and the supported formats. It is clearly distinguishable from the link-fetching sibling, since the schema's id_documento parameter explicitly routes through obtener_enlace_documento, and from consultar_documentos_locales because scope is a Compra Ágil attachment.

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?

"Basta el código de la compra: sin id ni nombre lee el primer adjunto y nombra los demás" tells the agent the minimum required input and the default selection behavior when optional params are omitted. It gives clear usage context but never explicitly states when to prefer this over obtener_enlace_documento or consultar_documentos_locales.

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 and openWorldHint=false, so the safety profile is covered; the description adds the meaningful caveat that it does not consult the API, implying the result is a local/state snapshot rather than live data. It also discloses the blind-spot concept that determines whether an empty result is trustworthy.

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 the actionable usage rule, then a short scope caveat. The opening enumeration is long but each item names a distinct piece of reported state, so little is wasted.

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

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

With no output schema, the description carries the burden of explaining what comes back, and it does so by listing the reported signals (last batch, pending batches, gaps, blindness, channel notices, unconfirmed gateway alerts, quota, active watcher). Combined with the annotations, an agent has everything needed to call and interpret it.

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

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

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline for a parameterless tool.

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

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

States a specific resource (la vigilancia de procesos nuevos) and enumerates exactly what the report covers: último lote, lotes pendientes, huecos, ceguera, avisos por canal, alertas sin confirmar, cuota proyectada y si hay vigilante activo. This clearly separates it from siblings like activar_vigilancia (mutating setup), obtener_alertas_nuevas and confirmar_alertas.

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

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

Gives an explicit use condition: consult it before asserting that 'there are no new processes', because silence is meaningless if surveillance is blind. It also scopes itself with 'No consulta la API'. It stops short of naming a specific alternative sibling, so it does not reach the top of the scale.

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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true): it discloses the async/background execution model and the polling pattern, the page-to-API-call ratio (10 processes per page = one API call) which signals cost/latency, and the truncation behavior with the publicado_hasta continuation token. It also enumerates the returned summary contents, which is critical given there is no output schema.

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

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

Front-loads purpose and scope, then layers operational details in short sentences that each carry information. Slight redundancy in the final sentence restating max_paginas default/max already in the schema, but overall it reads efficiently 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 an 11-parameter tool with no output schema, the description covers the essentials an agent needs: output artifact and summary shape, async retrieval, and pagination continuation. It omits auth requirements and any return-value caveats when zero results match, but nothing blocking is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only marginal semantic value over the schema — chiefly that max_paginas caps a series of 10-item pages each costing one API call (a cost implication). The remaining params are left entirely to the schema via the 'same filters as buscar_compras_agiles' pointer.

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 ('Exporta a un archivo ... todas las Compras Ágiles de una búsqueda') and immediately scopes it against the sibling: 'no solo una página', contrasting with the paginated buscar_compras_agiles. An agent can tell exactly what this returns versus the search tool.

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 filter semantics to buscar_compras_agiles ('Usa los mismos filtros') and gives concrete operational guidance: re-call with the same filters to retrieve a backgrounded result, and use the returned publicado_hasta to continue past the page cap. It stops short of an explicit 'use X instead when Y' exclusion, but the when-to-use case (need the full set, not one page) is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds real behavioral context: it auto-computes net values, 19% Chilean IVA, gross amounts, and falls back to market pricing if no custom price is supplied. These computation and defaulting behaviors are not derivable from the annotations alone, though it doesn't describe persistence or quota implications.

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 front-loaded sentences with no redundancy: the first establishes what is generated and for what target, the second covers the automatic calculations and price fallback. Every clause 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 nine-parameter tool with only one required field, the description covers purpose, computational behavior, and defaulting rules, and full schema coverage handles the parameters. With no output schema present, the exact JSON draft structure is left unexplained, which is the only meaningful gap.

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

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

Schema description coverage is 100%, so every one of the nine parameters is already documented in the schema (including the days enum and the keyword filters). The description adds no format or semantic detail beyond the schema, 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 (genera un borrador estructurado en JSON) and resource (cotización formal para un llamado de Compra Ágil activa), with the output artifact named explicitly. This cleanly distinguishes it from siblings like buscar_compras_agiles (search) or analizar_precios_mercado (price analysis).

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

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

It implies the operative context (an active Compra Ágil call to quote against), which lets an agent infer when the tool applies. However, it names no alternatives and gives no explicit when-not guidance (e.g., that analizar_precios_mercado should be run first if a market price is wanted).

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?

Adds real behavioral context beyond the annotations: the file is written to disk, the return value is the PATH not the content (explicitly to avoid context bloat), and the output is print-optimized with controlled page breaks and repeated table headers. This explains the readOnlyHint=false write and complements openWorldHint=true. It stops short of noting permissions, overwrite behavior of ruta_salida, or concurrent-write characteristics.

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 the crucial return-value caveat, then uses a clean bullet list for the five types. Length is justified by 17 params and 5 modes, though the paper-format sentence largely restates the enum descriptions already in 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?

No output schema exists, and the description fully covers the contract: what is produced (an HTML file path), where it lands, and how to consume it. Combined with type-specific requirements, nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter conditional requirements the schema cannot express (which types require codigo_compra vs. codigo_compra-or-q, that q/region apply to specific types). This meaningfully helps the agent pick valid combinations for a 17-param tool.

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

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

States a specific verb+resource (generates a printable HTML report from Compra Ágil data) and enumerates the five report types, each with its own scope. An agent can immediately tell this is a report-generation/file-output tool rather than a search or analysis tool.

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?

For each type it states the condition ("radar" = prioritized active opportunities; "cotizacion" requires codigo_compra, not sent to Mercado Público; "auditoria" requires codigo_compra or q, etc.), which gives clear selection guidance. It never names the near-duplicate siblings (generar_borrador_cotizacion, radar_oportunidades_calientes), so the agent gets no explicit when-not/to-use-which-alternative routing.

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 only say readOnlyHint/openWorldHint; the description goes far beyond that with the caveats that actually determine success: results are NOT ordered by last change (grouped by estado), `ultimo_cambio` is a 5-minute batch stamp rather than an exact time, callers must overlap by at least 5 minutes when resuming, page size is fixed at 10 because a 50-page request returns HTTP 504, and API dates are in Chile time requiring an explicit offset.

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?

It is long, but nearly every clause is an operational constraint an agent would otherwise get wrong, and it is front-loaded (purpose → window modes → output/pagination pitfalls). The bullet structure keeps it navigable; only minor trimming would be possible without losing information.

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

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

For a 7-parameter, annotation-light, read-only tool with no output schema, the description covers the prerequisites (timezone offsets), the ordering/pagination traps, and even names the response fields carrying Chile-time values. Nothing an agent needs in order to call this correctly and interpret the result is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description genuinely adds semantics on top: it frames `minutos` vs `cambio_desde`/`cambio_hasta` as two mutually exclusive ways to define ONE window, gives the default of 60 minutes, and explains the operational consequence of the 5-minute batch granularity for the absolute mode. It does not add anything new for `estado`, `region`, `numero_pagina` or `tamano_pagina` beyond what the schema already says.

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 gives a specific verb and resource — searching "Compras Ágiles" that were created or modified inside a change window — and immediately frames the intent (monitoring new opportunities, alerts, incremental sync). It implicitly separates itself from the sibling `buscar_compras_agiles` by emphasizing *changes over a window* rather than a general criteria search, but it never names or contrasts that sibling 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?

It states exactly when to use the tool (real-time alerts, incremental synchronisation, resuming from the last processed timestamp) and lays out the two mutually exclusive window modes with the default (relative, 60 min) and the escape hatch (absolute range, no 24h ceiling). It also warns not to mix the modes, which is the main misuse risk.

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 only give readOnlyHint/openWorldHint/idempotentHint; the description adds substantial context beyond them: ~10s per API query, the possibility that no alerts fit in one call and the 'revision' field reporting that, the 30-minute re-offer of unconfirmed alerts, the per-5-minute API cost of reviewing, and an explicit prompt-injection warning to treat buyer-written names as data. Rich disclosure not derivable from structured fields.

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 and most sentences carry non-redundant operational detail (timing, batch_id, re-offer window). It is dense and long for a one-parameter tool, but nearly every sentence earns its place; minor tightening possible.

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 still explains the return contract (lote_id, and 'revision' indicating whether a review window was exhausted) and covers reliability, timing, cost, and safety caveats. Nothing an agent needs to call it correctly is missing.

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

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

The single 'max' parameter is fully documented in the schema (100% coverage, range and default stated), so the description need not add syntax. It adds no further parameter meaning, making the baseline 3 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 ('entrega las alertas aún no confirmadas, con un lote_id') scoped to the always-on gateway mode, immediately distinguishing this from interactive siblings. The follow-up relationship to confirmar_alertas is named, so an agent can place it in the workflow without opening a schema.

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

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

Explicit when-to-use ('para un gateway siempre encendido'), the recommended division of labor (daemon reads, this tool only delivers its queue), the fallback when nobody is watching, and the required next step (confirmar_alertas with that lote_id). It also states what to do when a call times out (re-call it).

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 only declare readOnlyHint and openWorldHint. The description goes well beyond them by disclosing data quirks from real API measurement (quotations appear in 'desierta' not 'cerrada' first-call processes), timestamps in Chile time, empty supplier lists not meaning no offers, and non-CLP currency including exchange rate. This is exactly the behavioral caveat detail an agent needs.

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

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

Front-loads the core purpose before the field inventory and caveats, and every section carries relevant information. It is on the long side, cataloguing many returned fields that could be trimmed, but no sentence is pure 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?

There is no output schema, so the description carries the full burden of explaining return contents, and it does so comprehensively: process description, products, bidders, budget, delivery, order state, sustainability flags, plus timezone and edge-case behavior. Nothing an agent needs to interpret the response is missing.

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

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

Only one parameter with 100% schema coverage, and the schema already documents the format (XXXXXX-YYY-COTXX) and an example. The description just restates 'código único' without adding syntax or validation nuance, so the baseline 3 for high coverage 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 (obtiene el detalle completo) and resource (una Compra Ágil específica) retrieved by its unique código. It is clearly distinguishable from siblings like buscar_compras_agiles (search/list) and obtener_detalle_orden_compra (order-level detail), 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?

Provides useful context ('Confirma el plazo en la ficha del proceso') and warns to check total_ofertas rather than an empty supplier list, which helps interpretation. However, it never explicitly says when to prefer this over buscar_compras_agiles or how it relates to obtener_detalle_orden_compra, so the when/when-not guidance is only 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 readOnlyHint=true and openWorldHint=true, so the safety/profile burden is largely covered. The description adds valuable provenance context (the code must come from an external source and 'id_orden_compra viene null en el 100% de los procesos'), but it does not describe the return format, pagination, or error behavior when a code is invalid.

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 capability, then the critical constraint. The warning is genuinely load-bearing, though the caution is stated twice ('Úsala cuando ya tengas el código por otra vía' and 'No esperes obtenerlo con las demás herramientas'), a mild redundancy that trims efficiency.

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

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

For a single-parameter read tool with no output schema, the description covers what is returned (montos, comprador, proveedor, productos), the accepted input formats, and the critical precondition for obtaining the code. An agent has everything needed to call it correctly or recognize it cannot.

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 one parameter at 100% schema coverage, the schema fully documents codigo_oc including both accepted formats and examples. The description repeats the dual-format acceptance ('ID numérico o código alfanumérico externo') without adding syntax or validation detail beyond the schema, so the baseline of 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 (obtener el detalle completo de una Orden de Compra) and enumerates exactly what the detail contains: montos, comprador, proveedor adjudicado y productos adquiridos. It also distinguishes itself from the sibling Compra Ágil tools by clarifying that this is the legacy OC API and a separate data source.

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?

Explicit about when to use it and when not to: 'Úsala cuando ya tengas el código por otra vía' plus concrete sources (la OC emitida como proveedor, un correo, la ficha pública del proceso). It actively warns against expecting this server's other tools to supply the code, which routes the agent away from a dead end.

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 and openWorldHint=true, so safety and open-world access are covered. The description adds that the return is a 'ficha pública' plus attachment list, but says nothing about rate limits, authentication, or response format beyond that, which is adequate 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?

Two short sentences with no waste; the primary function is front-loaded and the routing hint follows immediately.

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 retrieval tool with fully documented parameters and no output schema, the description tells the agent what it returns and where to go for the follow-up action. Only the link/URL aspect implied by the name goes unexplained.

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%, documenting both codigo_compra (with format example) and the optional id_documento, so the schema carries the parameter burden. The description adds no meaning beyond the schema, which is the expected baseline of 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?

The description states a specific verb+resource: it delivers the process's public record plus its attachment list, and it names the sibling descargar_y_leer_documento for the read case. The one weakness is that the tool name emphasizes 'enlace' (a link/URL) while the description never mentions returning links, creating minor ambiguity about the exact output.

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 an explicit alternative for the adjacent operation: 'Para leer uno, usa descargar_y_leer_documento', routing the agent away from this tool when actual reading is wanted. It lacks when-not conditions or prerequisites, but the single most important branch point is covered.

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

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

With readOnlyHint/openWorldHint already covering safety, the description adds substantial context beyond structured data: it is a LOCAL count, not the official leftover quota, the ticket may be shared with other tools/teams, and it also surfaces process-scoped latency and per-tool errors. That is exactly the behavioral detail an agent needs to interpret results correctly.

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 primary purpose and the caveat block is clearly flagged with 'IMPORTANTE'. Slightly verbose, but every sentence carries interpretive value (local vs official, quota sharing, latency/error reporting) rather than 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 params, no output schema, and low-complexity annotations, the description fully describes what is reported: daily query count, 429 status, and process-scoped latency, errors per tool, and API result categories (cache, 504, 429, timeouts). Nothing an agent needs is missing.

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

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

Zero parameters, so the baseline is 4; there is nothing for the description to clarify. No param semantics are needed or missing.

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 (informa/cuenta) and resource (consultas a la API en el día UTC, más latencia y errores por herramienta). It explicitly distinguishes itself from the official ticket balance, which is a key sibling concept (verificar_ticket). An agent can tell exactly what this returns without opening anything else.

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

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

Gives clear when-to-use contexts: 'Sirve para moderar el gasto' and 'úsalo para saber si la API está lenta o caída antes de lanzar un análisis largo.' It also cautions that the count is local and not authoritative, effectively saying when not to rely on it. It stops short of naming the sibling (verificar_ticket) to use for the official balance.

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 flag a non-read-only, non-idempotent, open-world operation, and the description reinforces this by stating it actually sends messages and reports delivery per channel. It adds a useful negative boundary (does not query the Mercado Público API) that annotations alone cannot convey, though it stops short of describing rate limits or failure behavior.

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

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

Three tight sentences: purpose first, then the constraint on destinations, then a disambiguating negative boundary. Nothing is wasted and the most important information 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 zero-parameter diagnostic with no output schema, the description covers inputs, side effects, and delivery reporting adequately. It could say more about what the return payload looks like, but the essential behavior is captured.

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?

There are no parameters, so the baseline is 4. The description proactively explains why: destinations come from configuration (.env or extension fields) and conectar_telegram, and the tool intentionally accepts no destination argument.

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 sends a test message through each configured channel and reports which one arrived. It also delineates scope by naming the sibling (conectar_telegram) that owns destination configuration, so an agent can distinguish it from other setup tools without opening a schema.

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

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

It implies the use case (verifying that configured notification channels actually deliver) and clarifies the relationship to conectar_telegram as the prerequisite for setting destinations. No explicit 'use this when / don't use when' clause, but the context is clear enough to route correctly.

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 and openWorldHint, so the safety profile is covered; the description goes further by disclosing the scoring inputs (offer count, budget, hours to close, second-call flag), the time source (Chile time vs SHOA clock), and an important data caveat (0 offers and missing attachments are not ficha facts). Only rate-limit/cost behavior is left to the schema rather than the description.

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, no filler. Slightly dense/awkward in the caveat sentence ('no son hechos de la ficha'), but every sentence carries signal and nothing is redundant.

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

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

For a 5-param ranking tool with no output schema and minimal annotations, the description explains the scoring, the called-round field, and the q-matching disclosure, which covers most of what an agent needs. A short sketch of the returned result structure beyond 'llamado' and 'factors' would complete 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 a baseline of 3 would be defensible, but the description adds real meaning: it clarifies that q matches the title and that non-matching rows are flagged, and it ties presupuesto to the scoring. These nuances go beyond the schema's field descriptions.

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

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

States a specific verb and resource (scans published Compra Ágil processes and ranks them by a score), which cleanly separates it from siblings like buscar_compras_agiles (plain search) and obtener_detalle_compra (single-record detail). The scoring mechanism is described concretely enough that an agent knows exactly what this tool produces.

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 (find prioritized 'hot' opportunities) but never made explicit against alternatives. There is no 'use this instead of buscar_compras_agiles when...' guidance nor any when-not-use condition, so the agent must infer routing from sibling names alone.

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 only cover readOnlyHint and openWorldHint, and the description adds substantial context beyond them: the server's existing self-correction behavior, what the tool returns (offset, correction status, tz database version), a known failure mode (UDP port 123 blocked on corporate networks) and how it degrades gracefully rather than failing.

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 ordered by importance: what it does, when to use it, then behavioral/edge-case detail. Efficient overall, though the time-zone-database clause is slightly dense relative to the tool's simple purpose.

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

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

With no output schema and no parameters, the description carries the full burden and does so well: it explains the return content, the network failure behavior, and the relationship to the server's own time correction. An agent has everything needed to call it and interpret results.

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

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

The tool takes no parameters, so the baseline of 4 applies. Nothing more is needed and the description correctly avoids padding with irrelevant input detail.

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

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

States a concrete verb+resource: comparing the local machine clock against official Chilean time from ntp.shoa.cl (SHOA). This is unmistakably distinct from every sibling tool, which all deal with Mercado Público procurement data, so no ambiguity exists.

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

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

Gives explicit usage contexts ('when deadlines don't line up' or 'before deciding on a tight closure') and notes it does not consume API quota, plus the useful fact that the server already self-corrects deadlines. It stops short of naming a counterfactual alternative, but none exists among the siblings.

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 only declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: the verified API limitation, that it avoids API calls to save quota, the reuse-from-detail strategy, and the critical caveat that 'sin OC' does not prove absence. This is exactly the kind of extra disclosure annotations cannot carry.

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 purpose, then the limitation warning, then the strategy — logical ordering. It is long, but nearly every sentence carries decision-relevant information; only minor tightening is possible without losing the caveats.

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 return-semantics burden and does so by explaining what the result means and — importantly — what a negative result does not prove. Complete for an agent to call it correctly and interpret the outcome.

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% and the single parameter (codigo) is fully documented in the schema with format and example. The description adds no parameter-level syntax or semantics beyond what the schema already provides, 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 (informs whether a Compra Ágil has an issued purchase order by reading id_orden_compra from the detail), and explicitly distinguishes itself from siblings by noting it does NOT query the API on its own but reuses the detail from obtener_detalle_compra.

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 says when to use it (only as a re-read of an already-fetched detail, otherwise just points to how to confirm in the public record) and names the alternative tool (obtener_detalle_compra). It also warns when NOT to expect a confident result, avoiding wasted quota.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the internal mechanism (a minimal test query), a privacy guarantee ('NUNCA revela el valor del ticket'), and the exact output content (works/doesn't work plus the last 4 characters). These are behavioral traits the annotations cannot express, and they directly shape how an agent should use and trust the result.

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 tightly packed sentences that are front-loaded with the core purpose, then the privacy/output behavior, then the usage trigger. Every sentence earns its place with no redundancy or 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 zero-parameter diagnostic tool with no output schema, the description covers purpose, mechanism, privacy behavior, output shape, and usage timing. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes no parameters, so there are no semantics to document; the baseline for a zero-param tool is 4. The empty schema is consistent with the description, which implies no input is needed to run the check.

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 (verifica) and resource (ticket de acceso a la API de Mercado Público) with the scope of the check (configurado y sea válido). This is clearly distinguishable from siblings like verificar_orden_compra and verificar_hora_oficial, since it validates credentials rather than data. No ambiguity about what the tool does.

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

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

Gives an explicit trigger: 'Úsala como primer diagnóstico cuando otras herramientas fallen con errores de autenticación', which tells the agent exactly when to reach for it. It does not name specific alternative tools or state when NOT to use it, but the auth-failure condition is a strong, actionable routing cue.

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