Identik Firma Digital

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

With no annotations, the description carries the behavioral burden well: it discloses the return values (documentId, signingUrl per signer) and critically that the document stays in draft and consumes no credit until sent. It does not cover permission requirements or limits, but the draft/credit behavior is a meaningful, non-obvious trait.

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 purpose and flow, then the payoff (return values) and the critical constraint. No filler; each sentence 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 7-parameter mutation tool with no annotations and no output schema, the description supplies the workflow, the return values, and the draft/credit semantics that an agent needs to call it correctly. Remaining gaps (auth scope) are minor against the rich schema.

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

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

Schema description coverage is 100%, so every parameter (including nested firmantes fields and the WhatsApp/personería flags) is already fully documented in the schema. The description adds no parameter-level syntax or constraints beyond what the schema 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 and resource ('Genera un documento de firma digital a partir de una plantilla') and positions it distinctly from siblings like enviar_documento and listar_plantillas. An agent can tell immediately what this creates and from what 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?

Explicitly lays out the workflow ('listar_plantillas → esta herramienta → enviar_documento') and names the alternative that completes the process. It also clarifies the condition that changes state (draft until sent), giving the agent a clear when-to-use and what-comes-next.

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 annotations, the description carries the full burden and does well: it discloses that the return is a temporary no-token URL valid for 1 hour, what the PDF contains, and that only COMPLETED documents are eligible. It omits auth/permission requirements and what happens on an incomplete document, but the temporal and scoping behaviors are unusually well specified.

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 key fact (a temporary download URL) and packs expiry, content, and the archival caveat into three dense sentences with little waste. It is slightly packed rather than perfectly spare, but every clause serves the caller.

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 takes responsibility for return semantics, telling the agent it receives a 1-hour URL rather than file bytes, plus the artifact's contents. Together with the COMPLETED precondition, an agent has everything needed to call and use this tool 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 0% and the single parameter (documento_id) is undocumented in both schema and description. The description partially compensates by constraining the eligible document to COMPLETED status, but adds no detail on the identifier's meaning or format, so it only marginally exceeds the 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 (devuelve/descargar) and resource (constancia de firma), and describes exactly what the returned PDF contains (firmantes, fechas, IP, dispositivo, sellos de tiempo, hash SHA-256). This clearly distinguishes it from the sibling descargar_documento_firmado, which returns the signed PDF itself.

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

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

Gives a hard precondition ('Sólo documentos COMPLETED') and explains the archival workflow (la constancia NO va dentro del PDF firmado: archivala junto con el documento), which tells the agent when this output matters. It does not explicitly name the sibling alternatives (e.g., descargar_documento_firmado) to route between them, so it falls 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?

With no annotations, the description carries the full burden and does disclose real behavior: the tool returns a signed URL rather than a file, and returns HTTP 410 once the retention period ('plazo de resguardo') has passed. It omits auth requirements and whether the returned URL itself expires.

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 primary return value, then the sibling-routing caveat, then the failure mode. Every sentence adds 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?

No output schema exists, yet the description still explains the return (a signed URL) and the 410 failure case, plus the sibling routing. Only the required documento_id parameter remains undocumented, which is a real but narrow 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 0% and the single parameter documento_id has no description in the schema, so the description is the only place it could be explained — yet it never mentions the parameter or its expected format/source. The schema-level constraints (positive integer) are all an agent gets.

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?

Specific verb+resource: 'Devuelve una URL firmada de descarga del PDF firmado', stating both the action and the artifact returned. It distinguishes itself from the sibling descargar_constancia by explicitly saying the constancia is not inside this PDF.

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

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

Explicitly routes the agent to descargar_constancia when the constancia is needed rather than this PDF, which is the key ambiguity between the two siblings. It lacks an explicit statement of when to prefer this over obtener_documento or how the signed-PDF state is reached.

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 annotations, the description carries the full burden and delivers real side-effect disclosure: credit consumption, the draft state without this call, default email/WhatsApp/SMS invitation behavior, and that disabling emails still leaves the document in signing state. It omits idempotency/re-call behavior (whether credit is consumed twice) and any auth or error context.

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

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

Front-loads the core action and the credit consequence, then layers the email nuances in order of relevance. It is somewhat long, but each sentence (credit, default emails, enviar_email:false, finalization emails) addresses a distinct behavioral fact rather than padding.

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

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

For a 3-parameter mutation tool with no annotations and no output schema, the description covers the important behavioral consequences an agent needs before invoking it (state transition, billing side effect, email side effects). The main remaining gap is what happens on repeated calls and what the call returns.

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 schema already documents all three parameters and the description largely restates enviar_email and enviar_email_finalizacion semantics. It adds some operational meaning by tying enviar_email:false to the workflow of self-distributing signingUrls, but this is marginal over the structured fields, 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 in domain terms: it places the document into signing state and consumes the document credit, explicitly noting that without this step it stays as a draft. It also distinguishes itself from the sibling obtener_documento by explaining that signingUrls are retrieved there.

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 for use (this is the step that finalizes a draft and consumes credit) and explains an alternative mode via enviar_email:false where the caller distributes signingUrls themselves. It does not explicitly name when not to use it versus siblings like reenviar_invitacion, leaving that inference to the agent.

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 annotations, the description carries the full behavioral burden. It implies a read-only balance lookup but never states this, nor whether it requires authorization, whether it can fail for accounts without the optional modules, or how those conditional modules affect the response. Only the conditional content hint adds any value.

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 sentence that is front-loaded with the primary content ('Saldos de la cuenta'), but the trailing conditional clause about optional modules is vague and slightly obscures rather than sharpens the 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?

For a no-parameter, no-annotation, no-output-schema tool, the description names the general content but does not describe the shape of the result or the conditions under which the optional sections appear. It is minimally adequate rather than 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?

The schema has zero parameters, which is the baseline-4 case: there is nothing parameter-wise for the description to explain or compensate for.

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 says what the tool surfaces — account balances, document credits, and optionally biometric/WhatsApp/SMS verification status — so the resource is identifiable. But it has no verb, and the conditional 'si la plataforma los usa' muddies what will actually be returned. It does not differentiate itself from siblings like traza_auditoria or listar_documentos, though the resources differ obviously.

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 guidance on when to call this versus the sibling tools, no preconditions, and no mention of scope (own account vs. another). The agent must infer that this is a status/balance lookup available at any time.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It implies a read-only listing and reveals possible status values, but does not state auth/permission needs, pagination behavior, or that no side effects occur.

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?

Single front-loaded sentence with no filler. Efficient and appropriately sized for the tool's low complexity.

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?

The purpose and status values are clear for this low-complexity list tool. However, with no output schema and no annotations, the description leaves return fields beyond status and pagination behavior unaddressed, creating minor gaps.

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 optional 'pagina' parameter is fully documented in the schema. The description adds no parameter details beyond the status enumeration, which is output-related, so the baseline of 3 applies.

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

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

Explicit verb 'Lista' and resource 'documentos del equipo', with enumerated status values. It distinguishes itself from siblings like listar_plantillas and obtener_documento by its plural team-document scope, though it does not explicitly name alternatives.

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?

No when-to-use guidance, prerequisites, or explicit alternatives are provided. Usage is only implied by the verb and resource combination.

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 annotations, the description carries the burden and does disclose what is returned (id and signers) and that templates originate in the web UI. It does not state that the call is read-only/non-mutating, nor how pagination behaves despite the 'pagina' parameter, leaving behavioral gaps.

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, front-loaded with the verb and resource, with the workflow note second. No filler, though the second sentence is arguably marginal given no sibling is named.

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 list tool with no output schema or annotations, the description covers purpose and returned fields but omits pagination semantics and confirmation that it is a safe read. Adequate but with clear gaps for an agent planning pagination over 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?

There is a single optional parameter whose schema description coverage is 100% ('Página (por defecto 1)'), so the schema already documents it. The description adds no page-size, ordering, or filtering semantics beyond what the schema provides, 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 ('Lista las plantillas del equipo') and names the return fields (id, firmantes), so the agent knows this is a read/list operation over team templates. It is distinguishable from crear_documento_desde_plantilla by scope, though it never names a 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?

The clause 'las plantillas se arman en la interfaz web; desde acá se usan para generar documentos' implies the workflow (discover template ids here, then generate documents), which suggests when to call it. However, it never explicitly names an alternative tool or states when NOT to use this one, so usage is inferred rather than directed.

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

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

With no annotations, the description carries the full burden, and it does disclose the returned payload shape (estado, meta, firmantes, envelopeId). However, it says nothing about permissions, behavior when the id does not exist, or side effects, so behavioral disclosure is partial.

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

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

One front-loaded sentence that states the operation first, then enumerates return fields compactly. Dense but with no filler sentences; the only mild cost is the long parenthetical field list.

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?

Because there is no output schema and no annotations, the description's enumeration of return fields (estado, meta flags, signers with signingUrl/identity, campos, envelopeId) is valuable and largely fills the gap. It is still silent on failure modes and access requirements, so not 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?

The single parameter has 100% schema description coverage ("El `id` numérico del documento"), so the baseline is 3. The description restates "`id` numérico" without adding format, range, or example details beyond the schema.

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

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

States a specific verb ("Devuelve") and resource ("un documento por su `id` numérico"), making it clearly the single-document fetch among siblings like `listar_documentos` or `descargar_documento_firmado`. It does not explicitly name or contrast those siblings, so it stops short of a 5.

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

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

The phrase "por su `id` numérico" implies the lookup key, but there is no guidance on when to use this tool versus `listar_documentos`, `descargar_documento_firmado`, or `traza_auditoria`, and no exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full burden and does disclose the key non-obvious behavior: an all-or-nothing rejection that sends no emails, plus error-handling guidance (explain the reason, do not auto-retry). It stops short of 5 because auth requirements, idempotency, and rate limits are unstated.

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 purpose and then the failure mode and follow-up guidance. Every sentence earns its place, though the imperative 'Explicá el motivo y no reintentes' is slightly advisory boilerplate.

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 two-parameter action tool with no output schema and no annotations, the description covers purpose, the atomic-failure behavior, and error handling. Missing only tangential details like auth scope and success confirmation, which is reasonable given there is no output schema to explain returns.

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 50%: 'firmantes' is documented in the schema (recipientId from obtener_documento) and the description reinforces its semantics via 'firmantes pendientes' and signing order, but 'documento_id' is undocumented in both places and the description does not compensate. Baseline-to-marginal for partial coverage.

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 (reenvía el email a firmantes pendientes) with an added scope qualifier (respetando el orden de firma), which separates it conceptually from enviar_documento and obtener_documento. It does not name a sibling explicitly, so it falls just short of the top band.

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 and an exclusion condition: the tool is for pending signers and the whole request is rejected if any chosen signer is still awaiting their turn. It does not name alternative tools for related needs, so it stops short of 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?

Sin anotaciones, la descripción asume toda la carga. Aporta que devuelve la traza en JSON, los campos incluidos y que resuelve el envelopeId automáticamente, pero no menciona permisos, manejo de errores, paginación ni otras características operativas relevantes.

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

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

Dos oraciones breves y bien estructuradas, con la información principal al inicio. No hay relleno ni redundancia; cada frase aporta datos útiles sobre el propósito y el comportamiento.

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

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

Para una herramienta de consulta con dos parámetros y sin esquema de salida ni anotaciones, la descripción cubre el propósito y el contenido de la respuesta, pero no detalla el parámetro pagina ni aspectos como permisos o estructura exacta del JSON devuelto.

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

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

La cobertura de descripciones en el esquema es 0%, por lo que la descripción debe compensar. Explica que documento_id es un id numérico y que se resuelve automáticamente a envelopeId, pero omite por completo el parámetro pagina y su función de paginación.

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?

Especifíca claramente el verbo (Devuelve) y el recurso (traza de auditoría completa del documento), y detalla los eventos que incluye (creación, envío, apertura, firmas, con fecha/IP/dispositivo). No menciona ni diferencia explícitamente de herramientas hermanas como obtener_documento, por lo que no alcanza el nivel 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?

No indica cuándo usar esta herramienta frente a alternativas, ni condiciones de uso, requisitos previos o exclusiones. La única orientación es implícita en la propia descripción del propósito.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the operation is cryptographic verification and lists the specific checks performed plus that authentication is required ('equivalente autenticado'), but says nothing about the result format, cost, or permissions beyond the auth hint.

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

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

Two tightly packed sentences: the action and its target come first, the enumerated checks follow, and the public-validator comparison closes it. Every clause earns its place with zero padding.

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

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

There is no output schema, so the description bears some responsibility for indicating results, and it does so by enumerating the verification aspects (integrity, chain, timestamp, test status). It stops short of describing the shape of the verdict or error cases, which leaves a small gap for a validation tool whose output is the whole point.

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%: the single parameter pdf_base64 is fully documented with encoding and a 15 MB limit in the schema. The description adds only that the PDF may originate from Identik or an Argentine digital signature, which is context rather than parameter syntax, 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 ('Verifica criptográficamente') and resource ('las firmas de un PDF') and enumerates exactly what is checked: integridad, cadena, sello de tiempo RFC-3161, and test-document status. No sibling tool performs validation, so the agent can clearly distinguish it from the document-management siblings 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?

The description names an alternative ('el validador público /validar') and frames this as its authenticated equivalent, which hints at when to prefer it. However, there is no explicit when-to-use guidance within the workflow (e.g., after descargar_documento_firmado) and no when-not conditions against the sibling tools.

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