Server Quality Checklist

Tool Scores

• find_bundles_by_regionA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive, but the description adds valuable context beyond that: 'This needs no login,' 'resolves it against the platform's own region list,' and 'The result covers this region only.' It also mentions keeping bundle_code for follow-up, which informs the agent about downstream behavior. This is more than just restating annotations, though it doesn't disclose return formatting (which is covered by the output schema).

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

  Conciseness4/5

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

  The description is about five sentences and each earns its place: it states purpose, gives a WHEN condition, explains region resolution, references the sibling tool for filter/presentation behavior, and notes no login requirement. It is front-loaded with the main action and not overly verbose, though it could be tightened by removing some redundancy like 'such as Europe' and 'The result covers this region only' (both are useful, so not wasted).

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

  Completeness4/5

  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 and rich annotations, the description covers the key contextual aspects: when to use it, how to pass the region, that it requires no login, and that it behaves like the country-based sibling. It does not mention edge cases like invalid region codes, but the schema instruction 'Never invent a region code' partially covers that. Overall, it is sufficiently complete for a read-only search tool with a clear usage model.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds a bit of semantic guidance for the region parameter ('Pass the region as the user said it (name or code)') and for filters ('only pass filters the user stated'), but most parameters are already well-documented in the schema. The description does not compensate heavily for parameter semantics, as the schema already does that work.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Find the multi-country eSIM plans available for one region, such as Europe.' This clearly states what the tool does and distinguishes it from the sibling find_bundles_by_country by emphasizing 'multi-country' and 'region.' It also explicitly says 'The result covers this region only,' reinforcing scope.

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

  Usage Guidelines4/5

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

  The description includes an explicit 'WHEN' clause: 'the user names a region, or is visiting several countries in the same area.' It also tells the agent to pass the region as the user said it and to filter/present exactly as in find_bundles_by_country, referencing a sibling for consistency. However, it does not explicitly state when not to use this tool (e.g., when a single country is named), so it falls short of a fully explicit exclusion list.

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

• cancel_prepared_purchaseA
  4.5/5.0
  Behavior5/5

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

  The description goes well beyond the annotations by disclosing the operation is purely local ('discards local information only'), never contacts the eSIM platform, and has no refund/charge implications. It also specifies the correct user-facing messaging, which is valuable behavioral context not present in the structured annotations.

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

  Conciseness5/5

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

  The description is well-structured with clear 'WHEN' and 'IMPORTANT' labels, each sentence earns its place, and it avoids redundancy. It is neither too terse nor overly verbose for the complexity of the operation.

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

  Completeness5/5

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

  Combined with the schema and annotations, the description covers the action, scope, side effects, user communication, and parameter source. The presence of an output schema accounts for return-value details, making this description fully adequate for a single-parameter cancellation tool.

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

  Parameters3/5

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

  The input schema already fully documents the only parameter (quote_id: 'returned by prepare_purchase... Never invent, guess or edit one'), achieving 100% schema description coverage. The description adds no further parameter detail, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description uses a clear verb+resource ('Throw away a quote you prepared earlier') and explicitly differentiates from siblings like prepare_purchase and confirm_purchase by clarifying it only discards a local quote, not an order. The title 'Cancel a prepared eSIM quote' reinforces the purpose.

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

  Usage Guidelines4/5

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

  The 'WHEN' clause gives explicit usage context: 'the user says they do not want the plan you prepared, or wants to start again.' It also provides communication guidance ('never tell them an order was cancelled'). However, it does not explicitly name alternative tools or provide when-not conditions, so it stops short of a full 5.

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

• list_regionsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds useful context beyond that: 'This needs no login' and clarifies the scope with 'such as Europe.' No contradiction with annotations.

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

  Conciseness5/5

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

  Three short, purposeful sentences: what it does, when to use it, and how to chain it with another tool. Front-loaded and free of redundancy.

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

  Completeness5/5

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

  For a simple list tool with no required parameters, full schema coverage, strong annotations, and an output schema, the description together with the schema fully covers usage, triggers, and constraints. No important gap remains.

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

  Parameters3/5

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

  Schema description coverage is 100%, and each parameter (limit, query, locale) is already well documented in the schema. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific action and resource: 'List the regions the eSIM platform sells multi-country plans for.' The example 'such as Europe' and the name clearly distinguish it from siblings like list_countries and find_bundles_by_region.

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

  Usage Guidelines5/5

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

  Explicit WHEN triggers are provided: 'the user mentions a region, asks what regional plans exist, or is travelling to several countries in one area.' It also names the next step (find_bundles_by_region) and notes that no login is required, giving clear guidance.

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

• find_bundles_by_countryA
  4.6/5.0
  Behavior5/5

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

  Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive. The description goes further by stating 'This needs no login,' warning that 'Prices are catalogue prices and may not include final tax,' and clarifying the result covers only the destination. These are meaningful behavioral disclosures beyond the annotations and do not contradict them.

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

  Conciseness4/5

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

  The description is structured with WHEN and AFTER SUCCESS sections, making it scannable. Every sentence provides actionable guidance: trigger condition, parameter handling, output formatting, scope limitation, and auth note. It is somewhat long but justified given the tool's complexity; no filler exists.

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

  Completeness5/5

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

  Despite 9 parameters, the description covers the trigger, parameter discipline, result presentation (numbered list with bundle_code linkage), destination-only scope, pricing caveat, and no-login requirement. The presence of an output schema means return-value details are not needed in the description, and the post-success workflow is fully explained.

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

  Parameters4/5

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

  Schema description coverage is 100% with per-parameter explanations, so the baseline is 3. The description adds critical semantics for the country parameter ('Pass the country exactly as the user said it... Never invent a country identifier') and for filters ('Only pass a filter the user actually stated'), which meaningfully enriches parameter usage beyond the schema.

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

  Purpose5/5

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

  The description opens with 'Find the eSIM plans available for one country,' a specific verb+resource+scope combination. It clearly distinguishes from the sibling tool find_bundles_by_region by emphasizing 'one country,' and the AFTER SUCCESS section reinforces this singular scope.

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

  Usage Guidelines4/5

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

  The WHEN clause explicitly says to use this tool when 'the user names a destination country' and gives an example. It also instructs to only pass filters the user actually stated and mentions get_bundle_details as a follow-up tool. It does not explicitly name find_bundles_by_region as an alternative, though the distinction is implied.

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

• browse_home_catalogA
  4.7/5.0
  Behavior5/5

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

  Annotations already mark readOnly, openWorld, idempotent, and non-destructive. The description adds crucial operational context beyond those: 'there is no endpoint that returns every plan for every country' and 'This needs no login.' This explains a real limitation and authentication requirement that 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.

  Conciseness5/5

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

  The description is compact, front-loaded with the core purpose, and every sentence earns its place: WHAT it shows, WHEN to use, IMPORTANT limitation, and NEXT STEP. No filler or repetition of schema fields.

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

  Completeness5/5

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

  For a 0-required-parameter tool with a rich output schema and strong annotations, the description covers all needed context: what result looks like, usage triggers, endpoint limitation, and follow-up action. It also names the no-login requirement. Sibling tools provide further avenues but are not necessary to enumerate.

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

  Parameters3/5

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

  Schema covers 100% of parameters with clear descriptions for locale ('Optional language tag for platform text, e.g. 'en') and currency ('Optional ISO-4217 currency code, e.g. 'USD'). The description does not repeat or add param syntax, which is acceptable because the schema already carries full weight, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states a specific action and resource: 'Show what the catalogue offers: how many destinations and regions exist, plus a few cruise and global plans.' It distinguishes itself from siblings by explicitly noting that there is no endpoint returning every plan, making its overview role distinct from country/region-specific tools like find_bundles_by_country and list_regions.

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

  Usage Guidelines5/5

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

  The WHEN clause gives explicit triggers: 'user asks something broad like "show me all bundles", "what do you have" or "what plans are there".' It also provides a when-not ('never claim to be showing all of them') and guides the next step: 'ask which country or region the user is travelling to, or whether they want a global or cruise plan.' It even notes login not required, which is a precondition statement.

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

• get_bundle_detailsA
  4.7/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint and idempotentHint true; the description reinforces this by stating 'Nothing here reserves, orders or charges anything'. It also adds context about no login required and a price tax caveat, going beyond the annotations without contradicting them.

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

  Conciseness5/5

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

  Organized with purpose, WHEN, and AFTER SUCCESS sections. Front-loaded with the main action and every sentence adds useful operational or behavioral information without fluff.

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

  Completeness5/5

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

  With an output schema present, return-value details are not needed. The description covers purpose, usage, parameter source, side-effect profile, and even a pricing nuance, making it fully complete for this simple read tool.

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

  Parameters3/5

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

  Schema description coverage is 100% and the description's guidance for bundle_code largely repeats the schema's own description ('from a result you have already received; never invent'). It does not add significant meaning beyond what the schema already provides, so the baseline 3 applies.

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

  Purpose5/5

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

  Description states 'Read the full details of one plan' and lists the specific fields (data, validity, price, coverage, plan type, activation policy, availability). This uses a specific verb (Read) and resource, and clearly distinguishes from sibling tools like browse/find by focusing on a single plan already listed.

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

  Usage Guidelines5/5

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

  Explicitly provides a usage condition: 'WHEN: the user asks about a specific plan you already listed'. It instructs to pass the bundle_code from existing results and never invent one, and also states that this tool does not buy or reserve anything, guiding away from purchase use cases.

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

• get_login_statusA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: the call is local, fast, makes no network request to the eSIM platform, and the output can indicate a pending login that requires a six-digit code. This goes beyond annotations without contradicting them.

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

  Conciseness5/5

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

  Three sentences, with the purpose in the first sentence, usage timing in the second, and actionable result handling in the third. Every sentence earns its place with no redundancy.

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

  Completeness5/5

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

  Given zero parameters and an output schema present, the description fully covers what the tool does, when to use it, and how to interpret and act on the result. It is complete for an agent to select and invoke correctly.

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

  Parameters4/5

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

  The tool has zero parameters and the input schema is an empty object, making parameter explanations unnecessary. The baseline for 0 params is 4 and the description correctly focuses on behavior rather than inputs.

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

  Purpose5/5

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

  The description uses a specific verb 'Check' with a clear resource 'eSIM login status' and further clarifies it checks whether the client has a signed-in eSIM user. It distinguishes itself from sibling login tools by noting it is local, fast, and does not call the eSIM platform.

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

  Usage Guidelines4/5

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

  Provides explicit WHEN guidance: use before anything needing a signed-in user and whenever the user asks about login state. It also gives conditional actions based on the result (carry on if authenticated, ask for six-digit code if pending). However, it does not explicitly name alternative tools or state when not to use it, so it misses the top tier.

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

• get_prepared_purchaseA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate read-only and idempotent, but the description adds critical context: it reads local state only, changes nothing, and handles expiring quotes with guidance to offer re-preparation and clarify no charge occurred. This goes beyond the annotations.

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

  Conciseness5/5

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

  The description is well-structured with a clear WHEN prefix and concise sentences. Each sentence adds value: purpose, usage triggers, parameter source, behavioral note, and expiration handling. No fluff.

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

  Completeness5/5

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

  Despite having an output schema (so return values are covered), the description fully covers purpose, usage, local-state behavior, and edge cases like expired quotes. It is complete for an agent to select and invoke the tool correctly.

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

  Parameters3/5

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

  Schema description for quote_id already covers the 'returned by prepare_purchase' and 'never invent' guidance, matching the description. With 100% schema coverage, the description adds no new parameter meaning, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool reads back a prepared quote, specifying the exact data returned (plan, amount, payment method, validity). This distinguishes it from siblings like prepare_purchase and confirm_purchase by focusing on reading local state.

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

  Usage Guidelines5/5

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

  Explicit WHEN section with example user phrasings ('show me my prepared purchase', 'what was that going to cost'). It instructs to pass the quote reference from prepare_purchase and contrasts with platform-contacting tools by noting it never contacts the eSIM platform.

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

• get_user_profileA
  4.7/5.0
  Behavior5/5

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

  Even with annotations marking the tool as readOnly and idempotent, the description adds valuable behavioral detail: contact details come back masked, tokens and internal session data are never included, and the response may include 'authentication_required'. This is well beyond the abstract annotation flags and gives the agent operationally relevant expectations about output content and edge cases.

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

  Conciseness5/5

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

  The description is well-structured with clear section markers (WHEN, PRIVACY) and front-loaded with the core action. Every sentence provides essential guidance: the trigger condition, the authentication fallback, the masking behavior, and the privacy rule. No filler or redundant information is present, making it appropriately concise while thorough.

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

  Completeness5/5

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

  The tool has a rich output schema (indicated by 'Has output schema: true'), so the description need not explain return values. It covers the user-facing purpose, the trigger condition, the authentication failure mode, and privacy constraints. Combined with the annotations and schema, the description fully equips the agent to select and call this tool correctly.

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

  Parameters3/5

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

  The input schema already covers both parameters (locale and currency) with descriptions stating they are optional language/currency tags. The description does not add any additional parameter semantics beyond this, but it also doesn't need to — schema coverage is 100%. Per the rubric, the baseline of 3 is appropriate when the schema fully describes the parameters.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Read the signed-in user's own profile and wallet balance from the eSIM platform.' This clearly distinguishes get_user_profile from sibling tools like purchase or login tools, which have different resources and actions. It also scopes the tool to the signed-in user, preventing confusion with other profile-related functionality.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool: when the user asks about their account, profile, name, or balance while signed in. It also provides an exclusion/alternative: if the tool returns 'authentication_required', the agent should start the login flow with request_login_otp. This is a clear, actionable usage guideline that sets expectations and directs behavior.

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

• list_cruise_bundlesA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint/idempotentHint annotations, the description discloses that each plan covers specific ships, that the summary only reports a count, and that get_bundle_details is needed to name ships. It also states 'This needs no login,' adding auth context not present in the annotations. No contradictions with annotations.

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

  Conciseness5/5

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

  Four short sentences with a clear WHEN marker make the content scannable and front-loaded. Every sentence earns its place: purpose, triggers, ship-coverage caveat, and auth note.

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

  Completeness5/5

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

  Given 8 optional parameters, rich schema descriptions, a present output schema, and strong annotations, the description covers the remaining context: when to use, ship-specific behavior, and login requirements. No major gaps remain for an agent to invoke the tool correctly.

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

  Parameters3/5

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

  The input schema already provides 100% description coverage, including usage guidance like 'Only pass a budget the user actually stated' and 'Set true only when the user explicitly asks.' The tool description itself adds no parameter-level semantics, so the schema-heavy baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific action and resource: 'List the eSIM plans sold for cruise ships.' This clearly distinguishes it from country/region bundle finders and identifies the maritime domain. The title reinforces the purpose, and the special-case mention of get_bundle_details further clarifies scope.

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

  Usage Guidelines5/5

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

  It states explicit trigger conditions ('user says they are going on a cruise, names a ship or a cruise line, or asks for maritime coverage'), and directs the agent to get_bundle_details when a specific ship is involved before promising coverage. It also notes no login is required, which helps with alternative handling.

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

• logoutA
  4.7/5.0
  Behavior5/5

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

  Beyond annotations (destructiveHint=true, etc.), the description adds crucial scope: 'for this client only' and 'Other clients and other users are unaffected.' This explains the isolation behavior without contradicting annotations.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the first sentence states purpose, followed by a tight WHEN/DO NOT guideline. No unnecessary words.

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

  Completeness5/5

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

  For a simple logout tool with output schema and one documented optional parameter, the description covers purpose, usage constraints, and scope. Nothing essential is missing.

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

  Parameters3/5

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

  Schema coverage is 100% with a clear description of the optional 'locale' parameter. The tool description adds nothing about parameters, but the schema already fully documents it, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Sign the current user out of the eSIM platform, for this client only.' This clearly distinguishes it from sibling login tools and matches the title.

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

  Usage Guidelines5/5

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

  Explicit WHEN guidance is provided: 'only when the user explicitly asks to log out or sign out' and a clear DO NOT directive ('DO NOT log anyone out on your own'), which fully clarifies appropriate usage vs. alternatives.

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

• verify_login_otpA
  4.7/5.0
  Behavior5/5

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

  The description discloses significant behavioral context beyond annotations: 'you never see, need or handle any token' clarifies token handling, and 'do not retry a rejected code by yourself -- ask the user to re-read it, or to ask for a new one' explains failure behavior. Annotations only indicate readOnlyHint=false, but the description adds actionable safety and session management details.

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

  Conciseness5/5

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

  The description is well-structured with labeled sections (WHEN, AFTER SUCCESS, DO NOT) and every sentence delivers necessary guidance. It is concise enough to parse quickly while covering purpose, usage, and exceptions.

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

  Completeness5/5

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

  The description is complete given the tool's complexity and the presence of an output schema. It covers the success flow ('tell the user they are signed in'), session handling, and failure handling (no automatic retries). Optional parameters (locale, currency) are adequately described in the schema, so no further detail in the description is needed.

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

  Parameters4/5

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

  With 100% schema description coverage, the baseline is 3. The description adds extra meaning by instructing to 'Pass that code together with the same email or phone the code was sent to,' which clarifies an important relationship between the verification_pin and email/phone parameters not stated in the schema. This elevates the score to 4.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'verify the six-digit code the user received and open their eSIM session.' This specific verb and resource make the purpose unmistakable. It also distinguishes itself from siblings by completing the login flow initiated by request_login_otp.

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

  Usage Guidelines4/5

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

  The description provides a clear 'WHEN' condition: 'the user has given you a six-digit code for a login you started with request_login_otp.' It does not explicitly name an alternative tool to use instead, but the condition implies this is the correct step in the OTP flow. The 'DO NOT retry' instruction gives additional usage guidance.

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

• create_card_checkoutA
  4.9/5.0
  Behavior5/5

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

  The description adds context beyond annotations: it clarifies that the tool charges nothing by itself, is idempotent (returns same link, no second page), requires user sign-in, and never handles card details. This goes well beyond the idempotentHint annotation and gives a complete picture of side effects.

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

  Conciseness4/5

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

  The description is long but well-structured with clear headings (WHEN, FIRST, NEVER, etc.). Every sentence adds necessary safety or usage information. Slightly verbose, but the complexity and risk of payment tools justify it.

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

  Completeness5/5

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

  Covers all necessary context: prerequisites, step-by-step process, limitations, post-success expectations, and relation to other tools. The output schema handles return structure, and the description explains the semantics of the returned link. Very complete.

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

  Parameters5/5

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

  The schema already covers the single parameter quote_reference well, with concrete instructions. The description reinforces the semantics by emphasizing to use only the reference from prepare_purchase, never inventing or accepting user-supplied references, and explaining the consequences of an expired quote.

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

  Purpose5/5

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

  The description clearly states it opens a secure hosted checkout page for a prepared eSIM plan and returns the payment link. It distinguishes itself from sibling tools by explicitly referencing prepare_purchase and check_card_payment_status, making its unique role clear.

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

  Usage Guidelines5/5

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

  Provides explicit WHEN/FIRST/NEVER guidance. It states to call only after explicit user consent, only with a prepared quote, and to use check_card_payment_status after payment. Also explicitly says never to call on its own initiative or for mere quotes.

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

• list_countriesA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: the result is 'deliberately a limited extract plus a total count', and 'This needs no login' clarifies access requirements. This goes well beyond what the 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.

  Conciseness5/5

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

  The description is short and front-loaded with the core purpose. The 'WHEN' label organizes usage guidance clearly. Every sentence earns its place with no fluff or repetition.

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

  Completeness5/5

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

  For a simple list tool with an output schema, the description adequately covers purpose, usage, and result behavior. It explains the limited extract nature and instructs the agent to ask the user where they are travelling, which is critical for effective interaction. No gaps remain.

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

  Parameters4/5

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

  Schema description coverage is 100%, with detailed parameter descriptions for limit, query, and locale. The description complements the schema by clarifying query usage ('Pass the user's own wording as 'query' to resolve it') and browsing behavior ('omit 'query' to browse'), adding value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'List the countries the eSIM platform sells plans for, or check the one the user named.' This uses a specific verb and resource and distinguishes it from siblings like list_regions and find_bundles_by_country.

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

  Usage Guidelines5/5

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

  Explicit WHEN guidance is given: 'WHEN: the user asks which destinations are available, or you want to confirm a country exists before searching for plans.' It also explains how to use the query parameter ('Pass the user's own wording as 'query' to resolve it; omit 'query' to browse') and what not to do ('do not read the whole list out').

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

• prepare_purchaseA
  4.9/5.0
  Behavior5/5

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

  Even with annotations present, the description adds substantial behavioral context: it creates no order, moves no money, reserves nothing, replaces the earlier quote if called again, re-reads price/availability/balance from the platform, and must never imply the plan is reserved or bought. No contradiction with the annotations exists; the openWorldHint aligns with the re-reading behavior.

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

  Conciseness5/5

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

  Though long, the description is tightly structured with clear sections: WHAT, WHEN, FIRST, AFTER SUCCESS, and boundary statements. Every paragraph covers a distinct operational concern, and the opening sentence front-loads the core purpose. No filler sentences are present.

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

  Completeness5/5

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

  Given the tool's complexity, 6 parameters, output schema, and a web of related sibling tools, the description fully covers prerequisites, side effects, follow-up actions, and post-success messaging. It leaves no meaningful gap for an agent deciding when and how to invoke this tool.

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

  Parameters4/5

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

  The schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds genuine value by insisting bundle_code must come verbatim from a catalogue result and never be invented or asked from the user, plus clarifying that region/country preserve context but never affect price. This goes beyond the schema's already-rich parameter docs.

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

  Purpose5/5

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

  The description opens with a precise verb+resource statement: prepare a signed-in user's chosen plan for buying and report its cost, while explicitly clarifying that it does NOT buy anything. It clearly distinguishes this from confirm_purchase and create_card_checkout by stating those are the actual paying steps.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use context ('a signed-in user has picked a real plan... and wants to go ahead'), prerequisites (must check get_login_status), and directly names the alternatives: confirm_purchase for Wallet and create_card_checkout for Card. It also tells the agent not to call this again for the same choice and not to start payment on its own.

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

• resend_login_otpA
  4.9/5.0
  Behavior5/5

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

  Beyond the annotations (which only indicate non-read-only, non-idempotent, non-destructive), the description discloses critical behavioral constraints: the code goes to the same destination as the ongoing login, resend should only occur on explicit user request, and the agent must not auto-retry after failures. It also specifies how to respond to platform-reported rate limits or still-active codes.

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

  Conciseness5/5

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

  The description is compact and well-structured: it opens with the core action, then provides clear WHEN and DO NOT conditions. Every sentence contributes meaningful guidance, and there is no redundant or filler content.

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

  Completeness5/5

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

  Given the presence of an output schema, rich parameter descriptions, and sibling context, the description fully covers the tool's purpose, usage triggers, exclusions, and failure-handling behavior. It is complete for safely selecting and invoking this resend operation.

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

  Parameters4/5

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

  The input schema already provides extremely detailed parameter descriptions (100% coverage), including exact-format requirements and warnings not to invent values. The description adds further value by emphasizing 'Pass the same email or phone that started the login,' which is a key semantic constraint not explicit in the schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Send the pending one-time code again, to the same destination as the login already in progress.' It distinguishes this from sibling tools like request_login_otp and verify_login_otp by emphasizing it resends a pending code rather than requesting or verifying one.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use and when-not-to-use guidance: 'WHEN: only when the user explicitly asks for another code' and 'DO NOT call this on your own after a wrong or expired code, and do not use it to retry a failed request_login_otp.' It also instructs the agent to wait if the platform reports an active code or a limit was reached.

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

• check_card_payment_statusA
  5/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, idempotent, openWorld), the description adds crucial behavioral context: the tool cannot make a payment succeed, it only reads results from the platform, and it has no argument for asserting success. It also explains the exact meaning of each possible result, which is not deducible from annotations alone.

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

  Conciseness5/5

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

  The description is long but well-structured with clear sections (WHEN, NEVER, status meaning, unclear result). Every sentence earns its place by preventing a costly mistake or clarifying a critical nuance. The front-loaded purpose makes the tool's role immediately clear.

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

  Completeness5/5

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

  The description covers the tool's purpose, trigger conditions, non-triggers, result interpretation, and ambiguous/unresolved cases. With an output schema present, no return format explanation is needed; the description fully prepares the agent to act correctly in all described scenarios.

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

  Parameters5/5

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

  Although the schema already describes the parameter at 100% coverage, the description adds significant semantics: the payment_reference must come from create_card_checkout in this conversation, must never be invented or taken from the user, and no argument can override the platform's state. This is high-value guidance beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: asking the eSIM platform what happened to a card payment started with create_card_checkout. It also distinguishes this tool from siblings by noting it is the ONLY way to know whether a card payment went through, making it impossible to confuse with other payment or checkout tools.

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

  Usage Guidelines5/5

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

  Explicit when-to-use guidance is given: use it when the user says they have paid or asks to check, and only once per request. It also tells the agent when NOT to use it (not on a loop, not on its own) and clarifies that no other evidence counts as proof, effectively steering away from alternative interpretations.

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

• confirm_purchaseA
  5/5.0
  Behavior5/5

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

  The description goes beyond annotations by stating that it 'SPENDS REAL MONEY', debits the wallet, and cannot be undone. It also discloses idempotent repeat behavior, unclear-result handling, and post-success actions. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is long but every sentence adds value, with clear headings for WHEN, FIRST, SAFE TO REPEAT, AFTER SUCCESS, and IF RESULT IS UNCLEAR. It is well-structured and free of fluff.

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

  Completeness5/5

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

  For a high-stakes purchase tool, the description covers all necessary context: prerequisites, execution, idempotency, post-success reporting, and failure uncertainty. The presence of an output schema means return values need not be described, so this is fully complete.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds crucial context: the quote_reference must come from the agent's own prepare_purchase result, must not be invented or user-supplied, and expired quotes require re-preparation. This significantly constrains the parameter beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: buying a previously prepared eSIM plan using the wallet. The verb 'buy' plus the resource (prepared plan) and payment method (wallet) make it distinct from siblings like prepare_purchase and create_card_checkout.

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

  Usage Guidelines5/5

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

  The 'WHEN' and 'FIRST' sections provide explicit conditions for use: only after user confirmation of a specific amount, and after prepare_purchase has been called. It also lists exclusions (never on own initiative, never for checking) and differentiates from card payment.

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

• request_login_otpA
  5/5.0
  Behavior5/5

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

  The description discloses rate limiting ('DO NOT call this tool again for the same login attempt; it is rate limited'), the fact that the user is NOT logged in after success, and the masked destination in the result. These behaviors go beyond the annotations, which only indicate non-read-only, non-idempotent, and non-destructive hints.

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

  Conciseness5/5

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

  The description is organized with clear, labeled sections (WHEN, FIRST, AFTER SUCCESS, DO NOT) and each sentence conveys a necessary instruction. It is longer than average but every line adds value, and the structure makes it easy for an agent to parse and execute.

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

  Completeness5/5

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

  Given the tool's complexity, the description covers the full lifecycle: what triggers the tool, what to ask the user, what to pass, what the result means, what to do next, and what to avoid. The presence of an output schema means return values need not be detailed, and the description provides all needed context.

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

  Parameters5/5

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

  Though schema coverage is 100%, the description adds critical semantic usage: 'Pass exactly one of them, exactly as the user gave it' and 'Never invent, guess or auto-complete an address or number.' It also clarifies the otp_channel default behavior and the optional nature of locale/currency without repeating schema details.

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

  Purpose5/5

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

  The description states the specific verb and resource: 'ask the eSIM platform to send a six-digit one-time code to the user's email address or phone number.' This clearly distinguishes it from siblings like resend_login_otp and verify_login_otp by framing the action as starting a login.

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

  Usage Guidelines5/5

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

  Explicit WHEN conditions are provided: when the user wants to log in, or when an action requires a signed-in user and get_login_status reports no one signed in. It also instructs to ask for the destination first, to call verify_login_otp after success, and explicitly says to use resend_login_otp if the code never arrives.

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