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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and reach are covered. The description adds one genuinely useful behavioral fact – 'Sin costo' – telling the agent the call is free, but it says nothing about auth requirements or the response format. With annotations carrying the safety profile, this is adequate-but-thin.

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 very short fragments, front-loaded with the returned resource and closing with the cost note – no waste at all. It reads as a sentence fragment rather than a complete statement, which slightly limits it, but nothing is padded.

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

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

For a zero-parameter, no-output-schema read tool, the description covers what is returned and confirms it is free, and annotations cover the read-only/open-world nature. Only the lack of any linkage to the surrounding verification workflow keeps it from being 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 tool takes zero parameters, so there is nothing for the description to disambiguate; per the baseline for parameterless tools this scores 4. No parameter-level information is missing.

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

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

The description identifies the resource being returned (tokens available in the Verificar CURP account), which, combined with the name consultar_saldo, makes the operation clear. However, it never contrasts itself with siblings like consultar_verificacion or verificar_curp_renapo, so an agent gets no help distinguishing this balance check from the other verification tools.

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 when-to-use guidance, no stated precondition (e.g. before consuming tokens, or before running verificar_curp_renapo), and no mention of alternatives. The agent must infer usage entirely from the tool name.

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?

The description adds real behavioral signal beyond the annotations: the result in `valores` is delivered exactly UNA sola vez and then deleted, which explains the non-idempotent, non-read-only annotation profile and warns the agent not to expect repeat delivery. It also states the operation is free, though it omits auth or rate-limit details.

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

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

Purpose and status enum are front-loaded and the second clause packs the important one-time-delivery caveat without filler. It is dense and slightly run-on but 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?

With no output schema, the description correctly documents what is returned (the status enum plus `valores` when still stored). It is nearly complete for this simple single-parameter query, missing only details on polling cadence and the exact content/format of `valores`.

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 0%, so the description carries the burden, and it only supplies minimal meaning for job_id ('por su job_id', i.e. the identification of the verification job). It does not state where the job_id comes from or its format beyond the schema's string/length constraint, so it only partially compensates.

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: consultar el estado de una verificación en RENAPO por job_id, and enumerates the exact status values the tool reports. It is clearly distinguishable from verificar_curp_renapo (which initiates a verification) and consultar_saldo.

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 mention of 'sin costo' implicitly signals a cheap polling/status check versus paid siblings, and the job_id framing implies it is used after a verification is launched. However, no explicit when-to-use, when-not, or named alternative is given, 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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false): it discloses that the result does NOT return to this conversation but is delivered asynchronously to `destination_id`, only when the CURP is valid and matches, that link creation is free but each response costs 1 token up to 3 attempts, and that at most 20 live links may exist.

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

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

Purpose is front-loaded, followed by mode behavior, delivery mechanics, cost/limits, and return values in a single dense block. Every sentence carries information, though it is longer than strictly minimal; nothing is filler, but it is not a tight two-liner either.

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 fairly complex async tool with no output schema, the description covers the full picture: async delivery target, cost and attempt/token limits, link cap, and the returned `url` and `expiresAt` along with the caution to share the URL only with the client. 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 coverage is 100% so the baseline is 3, but the description adds genuine semantics: `persona` is matched against the typed CURP without ever being shown to the client, `ask_guest_persona` additionally collects name and DOB, and `destination_id` is characterized as the configured webhook/email/chat target.

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: creates a single-use link for the client to type their CURP from their phone. It is unmistakably a link-creation tool, clearly distinct from validation siblings like validar_curp or verificar_curp_renapo, so an agent can select it 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 context for use (e.g., at check-in) and explains the two modes via `persona` and `ask_guest_persona`. However, it never names an alternative tool or states when NOT to use it (e.g., when you already have the CURP and just want to validate it), leaving the routing decision 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?

Adds substantial behavior beyond the annotations: a malformed CURP is not an error but returns valida=false with a razon field, there is no RENAPO lookup, and the call consumes 1 token of balance. The token cost explains why readOnlyHint is false despite this being a pure validation, so there is no annotation contradiction.

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 sentences, each carrying distinct payload: scope of validation, cross-check condition, error-semantics, sibling routing, and cost. The most decision-critical information is front-loaded 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?

No output schema exists, so the description carries the return-shape burden and does so by naming the valida and razon fields and their semantics. Combined with the routing note and cost disclosure, 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?

Schema coverage is 100% with detailed nested-object documentation, so the schema does the heavy lifting (baseline 3). The description still adds meaning by framing the persona object as an optional cross-check against the CURP ('la coteja con esos datos'), which is the key behavioral nuance of that parameter.

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 precise verb+resource (validar la estructura de una CURP mexicana) and enumerates what is checked: longitud, formato, entidad, fecha de nacimiento, dígito verificador. It also explicitly distinguishes itself from the sibling verificar_curp_renapo, so an agent can route correctly without opening either schema.

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

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

Gives an explicit alternative and the condition that selects it: 'No consulta RENAPO (para eso usa verificar_curp_renapo)'. It also clarifies the trigger for the optional comparison path ('si mandas persona'), leaving nothing 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?

Adds substantial context beyond the annotations: the immediate response carries `verificacion.job_id`, the registry result (ACTIVA/BAJA/RNE/NO_ENCONTRADA) is delivered separately to `destination_id`, failure exposes `codigo` and `retry_after`, and the call costs 1 token. This is a genuinely async, cost-incurring operation that the sparse annotations do not convey.

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 purpose before the async/cost details. Slightly information-heavy but every clause (delivery model, failure fields, token cost) 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?

No output schema exists, so the description correctly carries the return contract (job_id plus later status via destination). With 4 params and a nested object, an agent has enough to invoke it correctly, though the validar_curp boundary remains unstated.

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

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

Schema coverage is 75% and the description enriches it: it explains that `destination_id` is a webhook/email/chat endpoint configured in the panel and that `verificacion.*` fields are outputs. The nested `persona` comparison semantics are documented in the schema rather than the description, so it stays at 4.

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 ('Valida la CURP y la verifica además en el registro de RENAPO'), and the phrase 'además' implicitly separates it from plain validation. It does not name sibling tools like validar_curp or consultar_verificacion, so the agent must infer the boundary.

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: this is the tool that both validates and hits RENAPO, with results arriving asynchronously at a destination. But it never states when to prefer it over validar_curp (validation only) or consultar_verificacion (fetch the result), leaving routing to inference.

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