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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds substantive behavior beyond them: identical rules to Sifende validation, the official SET rounding rule (guaraníes, lower multiple of 50), IVA-inclusive prices, and the fact that it performs a purely local computation. It does not describe the shape of the returned result beyond montoPago, which is the only remaining 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?

Four short sentences, front-loaded with the core purpose, then when-to-use, then a pricing caveat, then scope. Each sentence carries information, though 'Los precios incluyen IVA' is partly redundant with the schema and could be trimmed.

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 calculation tool with a rich, fully-documented input schema and no output schema, the description covers purpose, timing, rounding rules and side-effect scope adequately. It only names one return field (montoPago), so an agent lacks the full result shape, but the essential calling context is present.

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 (items, comision, tipoCambio, monedaOperacion, descuentoGlobalPorcentaje) is already documented in the schema. The description adds only the general note that prices include IVA, which duplicates the schema's precioUnitario wording and adds no parameter-level meaning. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Calcula el total de un documento') and enriches it with the exact rule set used (Sifende validation rules, SET rounding to the lower multiple of 50). It also distinguishes itself from the issuing sibling by noting 'no emite nada ni llama a la API', so an agent can tell it apart from emitir_documento 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 an explicit when-to-use: 'Usala para obtener el montoPago exacto de una venta al contado antes de emitir'. It scopes the tool (local calculation, no API call) but does not name an alternative tool or state when NOT to use it (e.g., non-cash sales), leaving that 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=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing what the response contains — included, consumed, reserved, and available documents, whether extra documents are allowed, and the estimated cost in guaraníes — which matters since 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?

A single front-loaded sentence that opens with the action and resource, then lists the returned fields. Every clause carries information; no filler or repetition.

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 parameters and no output schema, the description does the necessary work of enumerating the returned fields and is backed by read-only/open-world annotations. The only gap is that it never clarifies whose plan is returned (presumably the authenticated taxpayer) or the response format.

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, so the schema-baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing parameter 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 specific verb ('Muestra') and a precise resource (el plan vigente del contribuyente y su consumo del período), then enumerates the exact data points returned (documentos incluidos/consumidos/reservados/disponibles, documentos adicionales, costo estimado en guaraníes). The resource is naturally distinct from siblings like consultar_contribuyente or consultar_documento, but the description never explicitly differentiates itself from them.

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 by the content: an agent can infer this is the tool for checking plan quota/consumption status. However, there is no explicit when-to-use statement, no prerequisites (e.g., whether authentication determines the taxpayer), and no named alternatives among the many sibling 'consultar_*' tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds meaningful context beyond that: the data is implicitly scoped to the caller's API key (hence zero parameters) and the response contents are enumerated. It does not mention rate limits or error behavior, but for a read-only lookup the safety profile is adequately covered.

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

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

Two sentences, no filler: the first states what is returned and the second states why it matters. The return-field list is front-loaded and 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?

There is no output schema, so the description carries the burden of describing return values — and it does, listing six concrete fields. Combined with the annotations covering safety, an agent has everything needed to call and interpret this 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?

Zero parameters, so the baseline is 4. The description explains why no input is needed — the taxpayer is derived from the API key — which is useful framing the empty schema cannot convey on its own.

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 ('Devuelve los datos') and a specific resource ('el contribuyente dueño de la API key'), then enumerates the returned fields (RUC, razón social, tipo, ambiente, actividades económicas, domicilio). An agent can distinguish it from siblings like informacion_servidor or consultar_padron, though the description never explicitly contrasts them.

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?

'Sirve para confirmar con qué RUC y en qué ambiente se va a emitir' gives a concrete usage context — pre-issuance verification. No explicit exclusions or named alternatives are provided, so it falls short of the 5 bar.

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 readOnlyHint and openWorldHint, so safety is covered. The description goes further by disclosing what the response carries (SIFEN authorization protocol, mensajeRechazo on rejection) and the polling cadence/ceiling, which are real behavioral traits. It stops short of explaining error semantics or whether ERROR is retryable.

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, all load-bearing: purpose and states first, return contents second, polling protocol last. Front-loaded and free of filler.

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

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

There is no output schema, so the description carries the return-value burden and does so adequately by naming the state vocabulary and the rejection-reason field. For a single-parameter read tool, 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?

Schema description coverage is 100% and the cdc parameter is fully documented in the schema (44-digit pattern). The description only restates the lookup key, adding no format or syntax 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 (Consulta) and resource (estado de un documento electrónico), identifies the lookup key (CDC), and enumerates the exact terminal/non-terminal states it returns. An agent can distinguish this from siblings like consultar_evento or consultar_padron 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?

Gives explicit operational context: call it every 5 seconds after emitting until the state is terminal, capped at 5 minutes. This is strong when-and-how guidance, though it does not name an alternative tool for cases where the document was not just emitted or for bulk listing.

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

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

With no output schema, the description usefully discloses what the call returns (status APROBADO/RECHAZADO, response code and message). Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuine return-value context beyond them.

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 tight sentences with the identification-and-return detail front-loaded and the usage hint second. No redundant or filler text.

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-id read-only lookup with no output schema, the description covers both what it returns and when to use it, which is nearly everything the agent needs. Minor gap: it doesn't state behavior when the id does not exist.

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 single eventoId parameter is fully documented in the schema and the description only restates its meaning (eventoSifenId). Baseline 3 is appropriate when the schema does the heavy lifting.

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 (detalle de un evento por su id) and enumerates exactly what it returns (estado, código, mensaje de respuesta de SIFEN). This clearly differentiates it from the sibling listar_eventos, which lists rather than fetches a single event by id.

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 final sentence gives an explicit use case: confirm the result of a cancelación, nominación, or inutilización. It tells the agent when to reach for this tool, though it doesn't name an alternative tool for other scenarios (e.g. listing events).

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 is covered without the description. The description adds the hierarchical dependency between nivel and id plus the fact that results feed receptor addresses, but it says nothing about result size, ordering, caching, or failure behavior for "departamentos" which lists everything.

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 short sentences, front-loaded with the resource and then the per-level rules; nothing is redundant padding and the critical per-mode constraint comes before the closing context sentence.

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 read-only lookup with full schema coverage and annotations, the description covers purpose, mode semantics and id requirements. The only gap is that no output schema exists and the description never indicates what a result item looks like (code plus name), leaving the agent to infer the return 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 coverage is 100% and the schema already documents both `id` (required for distritos/ciudades, with which entity's id) and `nivel` (enum). The description restates the same rules in prose, reinforcing but not extending them beyond the schema, 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 names a specific resource (SIFEN geographic catalog for domiciles) and enumerates its three modes (departamentos, distritos, ciudades) with their scoping rules. No sibling tool touches geography, so the agent can distinguish it from the rest of the toolset immediately.

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 concretely when each nivel applies and that `id` is required for the two sub-levels, which is exactly the decision the agent must make before calling. It also gives the downstream purpose ("Los códigos se usan en el domicilio del receptor"), though it names no alternative tool or exclusion cases.

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=true), so the bar is lower. The description adds genuine value by disclosing the return fields and the fact that field names mirror the document receiver — important since there is no output schema — plus the accepted input-format tolerance. It does not mention lookup-failure behavior (e.g., not-found vs. error) or any rate/coverage limits.

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 dense sentences, front-loaded with the operation and return shape; nothing is padding. There is slight overlap between the 'same field names as the receiver' clause and the 'use it to complete the receiver' clause, which keeps it just short of ideal.

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 lookup with full schema coverage, the description covers purpose, return content, and input flexibility, which is sufficient. The only gap is what the agent should expect when the identifier is absent from the padrón, which matters for downstream error handling.

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 explicitly adds format tolerance beyond the schema examples: dots and check digit are both optional. That is meaningful disambiguation for a free-text identifier that an agent might otherwise over-validate.

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 ('Busca un RUC o una cédula en el padrón de la SET') and enumerates exactly what comes back (razón social, tipo de contribuyente, domicilio), which separates it from siblings like consultar_contribuyente or consultar_documento. An agent can identify the operation and its payload 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 a concrete use case ('Usala para completar el receptor de una factura'), which is clear context for when to reach for it. It does not, however, exclude or name alternatives, even though several siblings (consultar_contribuyente, consultar_documento) could plausibly be confused with 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?

Adds substantial behavior beyond annotations: it writes a local file (explaining why readOnlyHint=false while destructiveHint=false), polls up to esperarSegundos and signals a retry if the PDF isn't ready, watermarks output as 'SIN VALIDEZ FISCAL' under a sandbox key, and warns that the embedded base64 payload is context-heavy. None of this is recoverable from 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?

Three sentences, front-loaded with the primary action and return value, then edge cases (polling/retry, sandbox watermark, base64 cost). No filler; every clause carries actionable 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?

With no output schema, the description correctly states the return (local path plus optional embedded PDF) and covers the tricky async/retry case. It omits what happens when the document is not APPROVED or on auth failure, but for a 3-parameter tool this is close to complete.

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

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

Schema coverage is 100% (baseline 3), and the description adds real meaning on top: esperarSegundos is framed as the timeout after which the tool advises retrying, and incluirBase64 is given a concrete decision rule (client can't read the file) plus a cost warning absent from the schema text.

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 (descarga), resource (KuDE / representación gráfica en PDF), scope (documento APROBADO) and outcome (guarda en archivo local y devuelve la ruta). This clearly differentiates it from read-oriented siblings like consultar_documento or obtener_ejemplo_documento.

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 context: only for APPROVED documents, and explains the conditional behavior when the PDF is still being prepared (wait then retry). It also scopes incluirBase64 to 'solo si el cliente no puede leer el archivo'. It does not explicitly name a sibling alternative to route away to, 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and 'No hace llamadas a la red' largely restates openWorldHint=false. The description does add useful context about what state is exposed (write-tools-enabled flag, environment, version), but no auth, caching, or latency behavior is disclosed, so it stays at minimum-viable-plus.

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 short sentences, front-loaded with the returned fields, then the usage trigger, then the local-execution guarantee. Every sentence carries distinct information and there is no filler.

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

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

With no output schema and no parameters, the description fully carries the burden and does so: it names the three values returned (environment, write-enabled, version) and the pre-issuance use case. An agent has everything needed 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?

The tool takes zero parameters, so per the rubric the baseline is 4; there are no arguments whose semantics need explaining. Nothing in the description is required to compensate for a schema 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 ('Muestra') and enumerates exactly what is returned: the connected environment (Sandbox/SIFEN test/production), whether write tools are enabled, and the version. This is clearly distinguishable from the sibling consultar_* domain-query tools, which return taxpayer/document data rather than server metadata.

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: 'Llamala antes de emitir para saber si el documento tendrá validez fiscal', which tells the agent when to call it and why. It does not name a when-not condition or an alternative tool, but the pre-issuance ordering is unambiguous.

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 adds genuine behavioral detail beyond them: dual mode selection by presence/absence of 'nombre', and the delayed-failure trait of approximate names. It omits any note on caching or response size, but nothing contradicts 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?

Three sentences, zero waste, front-loaded with the resource and examples before the param behavior and the usage directive. Every sentence carries distinct 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?

With no output schema, the description correctly supplies the return semantics (names without a parameter, values with one). For a single-optional-parameter read-only lookup, an agent has everything needed to call it correctly and interpret the result.

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 optional parameter's description already documents the omit-to-list-names behavior. The description restates that semantics rather than adding format, casing, or case-sensitivity rules beyond the schema, 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 (returns valid values of API enumerations) and enumerates concrete examples (tipoDocumento, tipoPago, unidadMedida, afectacionTributaria...). It also explains the two operating modes, so an agent can distinguish it from every sibling tool, none of which deals with enumeration 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?

Gives a prescriptive when-to-use rule: 'Usala siempre antes de enviar un valor de enumeración', plus the consequence of skipping it ('un nombre aproximado falla recién al emitir'). No alternatives or when-not conditions are named, but no plausible alternative tool exists for this job.

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 is covered externally. The description adds that results are paginated and carry SIFEN status, which is modest extra context, but says nothing about ordering, volume, or result shape. Reasonable at 3 given the annotation baseline.

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 tight sentences, front-loaded with what is listed and followed by the filter instruction. Nothing 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?

For a read-only paginated list with all three parameters documented and no output schema, the description covers purpose, scope, and filter sourcing adequately. It could add one note on result ordering or pagination semantics to be fully complete.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine meaning for tipoEvento by pointing to listar_enumeraciones as the source of valid values. Pagination parameters are otherwise left entirely to the schema, so it stays just above baseline.

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 ('Lista los eventos registrados') and enumerates concrete event types (cancelación, inutilización, nominación) plus SIFEN status, so the agent knows exactly what domain is covered. It does not explicitly distinguish itself from the singular sibling 'consultar_evento', which is the only gap keeping it below 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?

The description tells the agent how to supply the filter ('Filtrá por tipoEvento con un valor de listar_enumeraciones'), which is useful routing. However, it gives no when-to-use guidance relative to alternatives like consultar_evento, so usage 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=false, and the description adds real context beyond them: data is fictional/synthetic, two enum values (nota_remision, autofactura) return a docs link instead of a payload, and the payload must be mutated before emission. It doesn't describe response shape or whether the link is a URL string, 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?

Three tight sentences: purpose first, then the per-value behavior split, then the required pre-emission action. No filler and the most decision-relevant information (which types work) 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?

No output schema exists, so the description carries the return-value burden; it partially discharges this by explaining the document-vs-link split and the fictional-data caveat. It stops short of describing the example's structure or format, but is sufficient for correct invocation.

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

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

Schema coverage is 100% with a documented enum, so baseline is 3, but the description adds semantics the schema does not: it maps which enum values yield a full example versus which yield a documentation link. That materially changes what the agent should expect per parameter value.

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 (devuelve un documento de ejemplo con datos ficticios) and enumerates exactly which document types are produced versus which return a documentation link. An agent can distinguish it from siblings like consultar_documento or calcular_totales without inspecting 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?

Explicitly frames the output as input for emit_documento and instructs the agent to replace receptor/ítems/CDC before emitting, which is genuine when-to-use guidance. It lacks an explicit statement of when *not* to use it or which sibling to prefer when a real document is needed, 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.