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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'Es un cálculo local, sin llamar a la API', which is valuable confirmation rather than contradiction. It also discloses the non-obvious rounding behavior (lower multiple of 50) and that prices include IVA. It does not describe the shape of the returned totals beyond mentioning montoPago.

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 verb and resource, then rounding rule, use case, and locality. Every sentence carries actionable information with no filler.

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

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

For a local computation tool with no output schema and fully documented parameters, the description covers rules, locality, and the key use case. It could be slightly stronger by stating what the returned totals contain (beyond montoPago), but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema; the description adds no per-parameter syntax or constraints. The note that prices include IVA and that field names match emitir_documento is helpful but closely mirrors what the schema already states.

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 ('Calcula el total de un documento') and scopes it to Sifende validation rules and the official SET rounding in guaraníes. An agent can distinguish it from the sibling read/query tools (consultar_documento, listar_eventos) because it produces a computed total rather than retrieving stored data.

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 to use it 'para obtener el montoPago exacto de una venta al contado antes de emitir', giving a concrete triggering condition and workflow position. It does not state when NOT to use it (e.g. for crédito or for already-issued documents), so it falls short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true 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, so the safety profile is covered. The description usefully clarifies that the scope is bound to the caller's API key (no parameters to choose a contribuyente), which is real added context, but it says nothing about failure modes (invalid/expired key) or response shape beyond the field list.

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: the first front-loads the action and the returned fields, the second adds a single clarifying identity fact. Nothing is wasted and nothing important is buried.

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 burden of describing what comes back, and it does so by enumerating the six field categories. It stops short of describing structure or error behavior, which keeps it from a 5 for a zero-argument, no-output-schema 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?

The tool takes zero parameters, so the baseline is 4. The description reinforces this by explaining that the subject is implicitly 'dueño de la API key', which explains why no identifier is needed.

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

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

States a specific verb and resource ('Devuelve los datos del contribuyente dueño de la API key') and enumerates the returned fields (RUC, razón social, tipo, ambiente, actividades económicas, domicilio). The added line 'Es el emisor de todos los documentos' clarifies what the resource conceptually is, so an agent can distinguish it from siblings like consultar_padron or informacion_servidor.

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

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

Usage is only implied: 'Es el emisor de todos los documentos' hints this is the root entity to consult before working with documents, but there is no explicit when-to-use, when-not-to-use, or named alternative among the eleven siblings. An agent must infer the 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 already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with a read-only external query. It adds real value by disclosing what is returned: the SIFEN authorization protocol and, for rejected documents, the mensajeRechazo reason. It does not mention rate limits, retry expectations for PENDIENTE, or response shape beyond the status 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?

A single front-loaded sentence with the key resource first and the outcome space immediately after. The state enumeration is dense but every item earns its place because it defines what callers must branch on.

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 one parameter, no output schema, and light annotations, the description carries most of the burden of describing returns and does so well by naming the state space plus the authorization protocol and rejection reason. It stops short of describing the full response structure or whether PENDIENTE should be re-queried.

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 cdc parameter is fully documented in the schema with its 44-digit pattern. The description only restates 'por su CDC', adding no format, validation, or acquisition guidance (e.g., how to obtain a CDC) beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource: consulting the status of an electronic document identified by its CDC. The enumeration of possible states (PENDIENTE, APROBADO, APROBADO_OBSERVACION, RECHAZADO, CANCELADO, ERROR) makes the output domain unambiguous. It does not explicitly contrast itself with siblings such as consultar_evento, so it falls short of a 5.

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

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

There is no explicit statement of when to use this versus alternatives like consultar_evento or descargar_kude. Usage is only implied: the distinction between PENDIENTE and terminal states hints that the caller should poll until a terminal state is reached. That implication is genuinely useful but never stated as guidance.

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

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

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; the description corroborates and reinforces this in plain language ("No hace llamadas a la red") and, more usefully, discloses the returned fields so the agent knows exactly what diagnostic data it gets back. It does not add anything about frequency, cost, or failure modes, but for a zero-argument read-only probe that is a minor 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?

Two sentences, both front-loaded with the highest-value information (what environment, whether writes are enabled) followed by the network-behavior note. Nothing redundant and nothing padded.

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

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

With no output schema and no parameters, the description carries the full burden of explaining return values, and it does so at a summary level (environment, write-enabled flag, version). It stops short of describing the shape of those values (e.g. how the environment is labeled in the response), which is the only remaining 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?

The tool takes no parameters, so there is nothing to disambiguate; the baseline for a 0-parameter tool is 4. The description correctly implies it is argument-free by describing only outputs.

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 concrete resource (the server's connected environment), and enumerates the exact payload: environment name, whether write tools are enabled, and version. No sibling tool (calcular_totales, consultar_evento, listar_eventos, etc.) returns server metadata, so an agent can tell immediately this is the diagnostic/config tool rather than a SIFEN data query.

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

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

Usage is only implied: the mention of "si las herramientas de escritura están habilitadas" hints you check this before attempting writes, and the returned environment names (Sandbox, pruebas con SIFEN, producción) signal a pre-flight check. But the description never states when to call it, what it should precede, or that it is safe/cheap to call repeatedly as a first step.

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 genuinely new behavioral context: the two distinct operating modes (no param = list names, with nombre = list values) and the late-failure mode when an invalid enum reaches emission.

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 compact sentences, front-loaded with what the tool returns, then the enumeration examples, then the behavioral rule. Every sentence carries information and none is filler.

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

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

For a single optional-parameter read tool with no output schema, the description covers both invocation modes and the motivation for calling it. The only gap is the return shape (array of strings vs. objects), which the agent must infer.

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 property description already says "Si se omite, lista los nombres". The description restates the same no-param/with-param semantics rather than adding format, case-sensitivity, or fuzzy-matching details, 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 and resource ("Devuelve los valores válidos de las enumeraciones de la API") and enumerates concrete examples (tipoDocumento, tipoPago, unidadMedida...). No sibling tool does anything similar, so an agent can route here 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?

Gives an explicit usage trigger: "Usala antes de enviar un valor de enumeración", plus the consequence of skipping it ("un nombre aproximado falla recién al emitir"). No when-not guidance or named alternative is needed since the sibling list has no overlapping tool, but that omission keeps it from 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=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.