ConnectMeGuru eSim

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds two pieces of context annotations do not carry: the auth requirement ('Requires a valid session token') and the state precondition (order must be pre-activation). It stops short of explaining irreversibility or refund/wallet consequences.

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

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

Two short sentences, zero filler, with the core action and its eligibility constraint front-loaded ahead of the prerequisite. Nothing could be trimmed without losing information.

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

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

An output schema exists, so return values need not be described, and annotations cover the mutation's risk profile. The description supplies the auth requirement and the eligibility window, but 'eligible' is never defined and no failure/error behavior is hinted at.

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 both parameters (token, orderId) are documented there, including that the token comes from verify_agent_otp. The description only restates the token requirement and adds no format, source, or edge-case detail beyond the schema, 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?

States a specific verb and resource ('Cancels an eligible eSIM order') plus a scoping condition ('before activation/provisioning'), so the agent knows exactly what action it performs. No other sibling performs cancellation, so differentiation is implicit rather than stated, which keeps it short of a full 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?

'Eligible ... before activation/provisioning' implies the window in which the tool may be used and the token prerequisite is named. However, there is no explicit when-not guidance (e.g., what to do for an already-activated order, or whether a refund path exists), leaving usage partly 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=false, so the safety profile is covered. The description adds real behavioral context beyond them: only official codes tied to a specific account are served, third-party affiliate codes and invented codes are explicitly out of scope, and codes beginning with SAVE20 must be skipped. It does not describe pagination or result ordering, but the output schema exists to cover return shape.

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

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

Front-loaded with the verb and scope in the first clause, and the remaining constraints are compact. The 'Never invent fake codes' warning is arguably preamble that could be trimmed, but it does not bloat the definition significantly.

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, a full output schema, and annotations covering the read-only/open-world profile, the description need only supply scope and edge-case rules, which it does. The main residual gap is that it never states whether SAVE20 codes should be omitted from output entirely or merely not acted upon.

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; baseline 4 applies. The description's mention of descriptions and applicability describes the response payload rather than any input.

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 (Retrieves) and resource (currently active official ConnectMeGuru promotional coupon codes) with scope narrowed to codes affiliated with admin@connectmeguru.com, plus what is returned (descriptions and applicability). This clearly separates it from validate_coupon, which tests a single caller-supplied code.

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 scope (fetch active codes with their applicability) and the SAVE20 exclusion hints at filtering intent, but there is no explicit statement of when to call this instead of validate_coupon or where coupon results should be applied. The instructions present are behavioral constraints rather than selection 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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the output is a secure checkout and purchase link for an eSIM package, but does not disclose link expiration, authentication needs, or other behavioral details beyond what annotations provide.

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

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

The description is a single, front-loaded sentence with no redundant or filler content. Every word contributes to conveying the tool's 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?

The tool has full parameter coverage, an output schema, and clear annotations, so the description only needs to state the core purpose. It does so adequately, though it could briefly clarify that this generates a link rather than executing a purchase.

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 both parameters (packageCode and discountCode) are fully documented in the schema. The description adds no parameter-specific semantics such as format constraints or coupon behavior, 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?

The description states a specific verb (Generates), resource (secure checkout and purchase link), and scope (for a specific eSIM package). It distinguishes from purchase-executing siblings implicitly by focusing on link generation rather than completing a purchase, but does not explicitly name or contrast with 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?

The description gives no explicit guidance on when to use this tool versus alternatives such as purchase_esim_with_wallet or purchase_topup. It also omits prerequisites or conditions that would select this tool over related siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds that only ACTIVE plans are returned, which is real behavioral context, but says nothing about result limits, ranking, or pagination for a search endpoint.

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, zero filler, purpose front-loaded before the refinement detail. Every clause carries information the agent needs.

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?

An output schema exists, so return values need no explanation, and a single optional parameter with full schema coverage leaves little to document. The only omission is what 'active' scoping and result ordering mean in practice.

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

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

Schema description coverage is 100% and the single parameter already documents the same example formats ('Japan, JP, Japan 100MB, Europe 10GB'). The description's examples restate rather than extend that, so the baseline 3 applies despite a heavy hint that the value doubles as fuzzy keyword search.

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: 'Queries active travel eSIM data plans.' An agent can see this is a discovery/search tool rather than a purchase or top-up tool. It does not explicitly name the nearest sibling (get_topup_packages) or draw the line between them, keeping it 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?

Usage is implied: this is the catalog lookup an agent would call when hunting for a plan. However there is no explicit 'use this before purchase_esim_with_wallet' guidance, no statement of when not to use it, and no differentiation from get_topup_packages, which also returns purchasable packages.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds almost nothing beyond naming the content: it does not say whether the whole base is returned, whether results are static or live, or how it is meant to be consumed. For a zero-parameter tool this leaves the agent with little operational 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?

One tight sentence that front-loads the verb and resource and then lists the included material. Nothing is wasted, though it is a single sentence and stops short of giving the agent any routing or usage instruction.

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?

An output schema exists, so return structure need not be explained, and annotations carry the safety profile. However, for a grounding tool whose value depends on when and how the agent should consult it versus answering directly, the description omits that operational context entirely.

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, which is the baseline 4. The description correctly implies a parameterless full retrieval and does not invent filter semantics that do not exist.

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 (Retrieves) and resource (ConnectMeGuru grounding knowledge base), then names what it contains. It is clearly distinct from every sibling, which are all transactional or account-scoped 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?

Usage is implied: the tool exists so the agent can ground answers about installation, compatibility, refunds, and escalation. But there is no explicit when-to-use/when-not-to-use guidance and no named alternative for policy or workflow questions. Adequate but with a clear gap.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the authentication requirement (valid session token), which is modest added value beyond the structured data.

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, with the core purpose front-loaded and the auth prerequisite second. 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 an output schema present and annotations covering the safety profile, the description is largely sufficient. It is slightly thin on what 'compatible' means and where this tool sits in the OTP-verify → browse → purchase flow, but nothing essential for a correct call 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 both parameters are documented in-schema, including the token's provenance from verify_agent_otp. The description adds no parameter detail beyond what the schema already provides, 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?

States a specific verb and resource ('Retrieves compatible top-up data packages') with a scoping condition ('for an active eSIM'), which clearly separates it from the sibling purchase_topup. It does not explicitly name any sibling as the alternative, 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 'for an active eSIM' and 'Requires a valid session token' imply preconditions, but there is no explicit when-to-use/when-not guidance or reference to the sibling tools (e.g., purchase_topup, verify_agent_otp) that complete the flow.

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 a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds value beyond them by disclosing the auth requirement (valid session token) and the paginated nature of the result. It stops short of rate limits or ordering behavior, but the added auth/pagination context is solid.

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, front-loaded with the core action and then the prerequisite. No filler, no redundancy.

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?

An output schema exists, so return values needn't be explained, and annotations carry the safety profile. The description covers the resource scope, auth prerequisite, and pagination, which is nearly complete for a simple read tool; only ordering or filtering behavior is left unspecified, which is minor.

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 page, limit, and token are all already documented in the schema. The description's mention of 'paginated' and the session token merely restates what the schema provides, adding no syntax, defaults, or format detail. 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 states a specific verb (Retrieves) and resource (paginated list of the authenticated user's eSIM orders and history). The scoping to the authenticated user's own orders clearly separates it from siblings like get_wallet_transactions, get_esim_catalog, and cancel_order without opening another 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 gives a prerequisite ('Requires a valid session token'), which is useful context, but offers no explicit when-to-use guidance versus alternatives such as get_wallet_transactions or cancel_order. Usage is only implied by the 'authenticated user' scoping.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description adds the auth requirement, which is genuinely useful behavioral context, but says nothing about caching, freshness, or failure modes (e.g., expired token).

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

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

Two short sentences with zero redundancy; the core purpose is front-loaded ahead of the auth prerequisite.

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?

An output schema exists, so return values need not be described, and the one-parameter schema is fully documented. Adding a note on token expiry behavior or the read-only, closed-world nature would close the 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?

Schema description coverage is 100% and the single token parameter is fully documented in the schema (including its source: verify_agent_otp or PAT). The description's mention of a valid session token merely echoes this, 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 ('Retrieves the user's current pre-funded wallet balance'), which is unambiguous. However, it does not differentiate itself from the sibling get_wallet_transactions, which an agent could easily confuse it with.

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 states a prerequisite ('Requires a valid session token') but gives no explicit when-to-use guidance or routing rules against alternatives like get_wallet_transactions. Usage is implied rather than articulated.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the results are paginated and an auth token obtained from verify_agent_otp is required. It does not describe rate limits or default page sizing behavior.

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

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

Two sentences, zero filler, with the core purpose front-loaded ahead of the prerequisite. Every clause carries information an agent needs.

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 annotations covering the safety profile, a full parameter schema, and an output schema defining the return values, the description is nearly self-sufficient: it names the resource, the pagination, and the auth requirement. It omits only guidance on when this is preferred over get_wallet_balance or get_user_orders.

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 page, limit and token are already fully documented, and an output schema exists. The description only restates that the list is paginated and requires a token, adding no syntax or meaning 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?

Specific verb (Retrieves) plus resource (wallet transaction history) with the paginated-list nature stated up front. It clearly separates from get_wallet_balance by naming transactions rather than balance, but it never explicitly contrasts with that sibling, 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 description discloses the precondition (a valid session token from verify_agent_otp) but gives no explicit when-to-use guidance or named alternative among the wallet/order siblings. Usage is implied rather than 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?

Annotations already declare the safety profile (readOnlyHint=false mutation, non-idempotent, openWorld). The description adds genuine behavior beyond that: the charge is drawn from wallet balance and, critically, the insufficient-balance path returns a magic top-up link rather than simply failing. That failure-mode disclosure is meaningful and not present in the structured fields.

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

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

Two tight sentences, front-loaded with the action and followed by the edge-case outcome. No filler or redundancy.

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?

An output schema exists, so return values need no explanation, and the description still usefully calls out the magic-link fallback. What remains unstated is the permission/token prerequisite and any idempotency implications, though annotations plus the token param cover most of that.

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 token, packageCode and discountCode are all documented in the schema with examples; the description adds no additional parameter meaning. Baseline 3 is appropriate when the schema carries the semantics.

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 ('Purchases an eSIM package') and the mechanism ('using the user's wallet balance'), which implicitly distinguishes it from siblings like purchase_topup and get_checkout_url. 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 'directly in chat using the user's wallet balance' implies the usage context and differentiates the wallet-payment path, but there is no explicit when-to-use/when-not guidance and no named alternatives such as get_checkout_url or purchase_topup. Adequate but inferential.

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=false, openWorldHint=true and idempotentHint=false, so the mutation profile is covered. The description adds two useful facts beyond them — that funds come from the wallet balance and that a valid session token is required. It does not warn about the non-idempotency consequence (a retry can charge twice) or what happens on insufficient balance, which matters for a purchase tool.

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 core action and scope; no filler or restated title. It could be slightly tighter by folding the token requirement, but 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. Still, for a wallet-charging, non-idempotent purchase the description omits failure modes (insufficient balance, invalid/expired token) and the double-purchase risk, leaving an agent without guidance for the most consequential edge cases.

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% — token, orderId and packageCode are each documented in the schema, including the pointer to verify_agent_otp. The description adds no parameter-level detail (e.g., how to obtain packageCode or that orderId must reference an active order), 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?

States a specific verb and resource ('Purchases a ... top-up package') and clarifies the funding source ('using the wallet balance'), which separates it from get_topup_packages (read) and purchase_esim_with_wallet (a different purchase). It does not explicitly name those siblings, so an agent must infer the boundary rather than being told it.

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: 'compatible top-up package' hints the agent should first resolve available packages (get_topup_packages) and that the package must match the active order, but no explicit when-to-use, prerequisites, or alternative is named. No guidance on the relationship to purchase_esim_with_wallet either.

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=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile and external dependency are largely covered. The description adds the authentication prerequisite ('Requires a valid session token') and the fact that the request hits the carrier, which is useful, but this overlaps substantially with the token parameter's own schema note and the openWorld 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 sentences, zero filler, and the action plus its precondition are front-loaded. Every clause carries information an agent needs.

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?

An output schema exists, so return values need not be described, and annotations cover idempotency and safety. The description covers purpose, auth, and target resource; only the trigger scenario (e.g., when a user asks for current usage vs. cached data) is left implicit.

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 both the token and orderId parameters are already documented in the schema, including where the token comes from (verify_agent_otp). The description adds no format, constraint, or validation detail beyond that, 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 gives a specific verb ('Requests a real-time data usage update'), the resource ('an active eSIM'), and the data source ('from the carrier'), which clearly separates it from transaction-focused siblings like purchase_esim_with_wallet or get_user_orders. It stops short of naming any sibling it could be confused with, but no sibling covers the same operation.

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 'for an active eSIM' implies the precondition for use, and the action itself (fetching fresh usage) hints at the scenario, but there is no explicit when-to-use statement, no when-not-to-use, and no alternative named. Adequate but requiring 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 disclose that this is a non-read-only, open-world, idempotent, non-destructive operation. The description adds the 6-digit code length and delivery channel, but omits rate limits, OTP expiry, session binding, or whether previous codes are invalidated.

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 action and resource, with no wasted words. It is appropriately sized for a one-parameter tool.

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?

An output schema exists, so return values need not be explained. The description covers purpose, delivery mechanism, and authentication context; the only minor gap is that it does not explicitly relate to verify_agent_otp, but that is not essential for invoking this simple tool.

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

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

Schema description coverage is 100% and the single email parameter is fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, 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?

States the specific verb 'Sends', the resource '6-digit OTP code', the delivery target 'customer's email address', and the context 'in-chat authentication'. The verb distinguishes it from the sibling verify_agent_otp, but the description does not name that alternative 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 phrase 'for in-chat authentication' implies the intended context, but there is no explicit when-to-use, when-not-to-use, or alternative tool guidance. It does not tell the agent to use verify_agent_otp for validation afterward.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely new behavior: the auth requirement and the specific 401 failure mode with the suggested user-facing response, which is exactly the kind of context annotations cannot express.

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, front-loaded with the purpose before the auth caveat. The 401 sentence is long but each clause (error condition, required user message, remedy tool) carries actionable information rather than filler.

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

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

An output schema exists, so return values need not be described, and the description covers the main non-obvious requirement (login/auth) plus the failure handling. What remains unspecified is the actual validation outcome semantics on success (valid vs. inapplicable for a package), though the output schema likely covers that.

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%, with both parameters documented (coupon code example WELCOME10, and packageCode as the eSIM package to check applicability for). The description adds no syntax or format detail 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 (validates) and resource (discount coupon code) plus the context of use (for checkout), which cleanly separates it from the sibling get_available_coupons. An agent can tell what it does without opening the schema.

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

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

Gives an explicit prerequisite (user login is mandatory to validate a coupon) and a concrete recovery path for the 401 case pointing at send_agent_otp. It does not, however, explain when to prefer this over get_available_coupons or other checkout siblings, so it falls short of a full when/when-not contrast.

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

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

Annotations declare it is not read-only, not idempotent, and not destructive, but do not explain the consequence of repeated calls or the session token's scope. The description adds that a session token is returned for wallet purchases, which is useful context beyond the structured data.

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 states the action, inputs, and outcome without any wasted words.

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?

Given the tool has an output schema (which would describe the session token and any errors), a 2-parameter schema, and clear annotations, the description covers the essential purpose and outcome. It misses only explicit usage guidance relative to send_agent_otp.

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 both parameters are fully documented in the schema (code as 6-digit OTP, email as customer address). The description adds no additional parameter semantics beyond what the schema already provides.

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 (Verifies), resource (email OTP code), and an outcome (returns a session token for wallet purchases). This clearly distinguishes it from the sibling send_agent_otp, which sends rather than verifies.

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 implies this is used after receiving an OTP (presumably via send_agent_otp), but it does not explicitly state when to use it versus alternatives or prerequisites. The connection to send_agent_otp is implicit rather than spelled out.

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