eSIM Finder

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: it returns a clickable URL, instructs the agent to render it as markdown, and warns about the trust-breaking price mismatch if currency is inconsistent. 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.

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

The description is front-loaded with purpose and includes only a short usage rule plus the currency critical note. It is slightly repetitive with the schema's currency property description, but the repetition is justified by how important the requirement is.

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 annotations, full parameter documentation, output schema, and clear relationship to search_esims, the description covers the essential context: when to use it, how to render the result, and the critical currency alignment. Nothing necessary for correct invocation 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%, so the input schema already documents sku, currency, and quantity. The description reinforces the currency-matching rule and adds the trust rationale, but it does not add substantial parameter meaning 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?

The description opens with a specific verb and resource: 'Generate a checkout URL for a specific eSIM plan.' It clearly distinguishes this tool from the sibling search/plan/info tools by tying itself to search_esims results and the checkout flow.

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 guidance is explicit: 'Use only AFTER the user has chosen a specific plan from search_esims results.' It also gives a precise currency-matching rule with a concrete failure scenario, so an agent knows exactly when and how to invoke the tool correctly.

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

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

With readOnlyHint=true and destructiveHint=false already in annotations, the description adds value by disclosing the return type ('response is markdown text from the eSIM Finder knowledge base') and a data-freshness trait ('the regions topic is generated live from the current catalog'). This goes beyond what annotations alone communicate, though it does not address concerns like rate limits or auth — minor for a read-only KB retrieval 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?

The description is long, but the length is earned: purpose is front-loaded in the first sentence, followed by usage criteria, then per-topic expansions each carrying selection-relevant detail. Minor redundancy exists — the enum values are restated from the schema and the closing 'prefer this tool over guessing' repeats earlier guidance — so it is not perfectly lean, but no sentence 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?

Given an output schema exists (so return structure need not be explained), annotations cover the safety profile, and the single required parameter is fully documented by both schema and description, nothing an agent needs to select or invoke this tool is missing. The description even covers edge routing like troubleshooting and post-purchase questions, which is complete for a knowledge-base retrieval tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description dramatically expands every enum value beyond the schema's one-line listing. Each topic is annotated with the actual content it returns — e.g., compatibility covers per-device install steps and specific error messages like 'This Code Is No Longer Valid,' travel-pass includes the full 130-destination list, regions enumerates all 14 current bundles. This is far beyond baseline and materially improves correct topic selection.

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 opens with a specific verb-resource pair — 'Retrieve detailed narrative information about the eSIM Finder product and connector' — and explicitly scopes itself as 'beyond what the search/checkout tools surface,' cleanly differentiating it from its siblings (search_esims, create_checkout_url, get_plan_details). The purpose is unmistakable even before reading the parameter details.

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?

Provides explicit usage routing: 'Use this for any question that is NOT a price/plan search' states the exclusion, while concrete question patterns ('how do I...', 'what is...', 'my eSIM is not working', 'what do I do after buying') tell the agent exactly when to reach for it. It also closes with a directive to prefer the knowledge base over guessing, which is actionable routing 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?

The description adds context beyond readOnlyHint=true by explaining that it does NOT generate a checkout URL, which is a behavioral boundary. It also warns about currency consistency and language handling, which are critical for correct invocation. The annotations already indicate read-only, so the description complements them without contradiction.

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

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

The description is somewhat long but packs necessary operational details (currency consistency, language handling, destination_url inclusion) in a structured way with clear sections like CURRENCY HANDLING and LANGUAGE. It front-loads the core purpose and then adds nuances, so it earns its length for a tool with these complexities.

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 presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers all critical usage aspects: when to use, parameters, currency consistency, language derivation, and how to use the destination_url. The tool's moderate complexity is fully addressed, and nothing essential is missing for correct invocation.

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

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

The input schema already provides detailed descriptions for all parameters (sku, currency, language), including examples and usage notes. The description reinforces the currency and language semantics by repeating the importance, but it does not add significant new meaning beyond the schema's 100% coverage. Thus baseline 3 is appropriate.

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

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

The description clearly states it retrieves full details of a single eSIM plan by SKU, distinguishing it from search_esims which returns multiple plans. It also names the sibling tool create_checkout_url which it is not (no checkout URL generation), so an agent can differentiate it without ambiguity.

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

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

Explicitly says use for inspecting/confirming a specific plan before checkout, or re-displaying details of a previously found plan. It also specifies not to use for checkout URL generation (use create_checkout_url instead) and when to use search_esims, providing clear when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds rich context beyond that: ~190 entries with Travel Pass first, alphabetical ordering of countries/regions, an exact-string guarantee for the search_esims country parameter, and disclosure that responses also surface PUL destinations. 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.

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

Despite being long, every sentence earns its place. Core purpose and trigger conditions are front-loaded, the (a)/(b)/(c) enumeration makes conditions skimmable, and the alternative-tool routing appears exactly where needed rather than in a separate section.

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

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

For a zero-parameter read-only tool with an output schema and safety annotations, nothing an agent needs is missing: return size, ordering, parameter-matching semantics, reverse-question answering, edge cases (uncommon destination names, empty search results), and routing to the sibling that covers region contents.

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?

With zero parameters, the baseline is 4, and the description earns above baseline by confirming 'No input parameters required' and by adding cross-tool semantics: the returned names are the exact strings to pass as the country parameter to search_esims. This meaningfully instructs the agent how to chain outputs into a sibling tool.

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 opens with a specific verb and resource: 'List every destination (country or region) the eSIMfinder catalog covers.' It also distinguishes itself from siblings by name, noting that search_esims consumes these names as the `country` parameter and that get_esim_finder_info handles region-bundle breakdowns.

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 guidance is explicit and structured: three concrete trigger conditions (a/b/c) tell the agent when to call this before search_esims, and a clear when-not instructs it to use get_esim_finder_info with topic='regions' instead for bundle contents. It even covers the no-results fallback case.

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 readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds rich behavioral context: it warns against manual currency conversion to avoid checkout mismatches, explains how the language parameter affects the destination_url, and specifies the promotion line and destination guide link. 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.

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

The description is long but every section (currency, promotion, destination guide, language) is purposeful and clearly labeled with IMPORTANT. It's well-structured and front-loaded with purpose and usage. Slightly verbose but not redundant; a 4 is appropriate for its length while remaining effective.

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's complexity (currency, language, promotion, destination links), the description covers all necessary operational details. An output schema exists, so return format is not needed in the description. The description is complete for an agent to call this tool correctly in all scenarios.

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

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

Schema coverage is 100% and the description adds significant value beyond the schema: it explains the 'why' behind currency handling (do not manually convert), the requirement to pass the same currency to create_checkout_url, and how to derive the language parameter from the reply language. This goes well beyond the schema's basic field descriptions.

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 clearly states the verb ('Search') and resource ('eSIMfinder catalog for travel eSIM data plans'), and explicitly scopes it to destination countries. It distinguishes itself from siblings by noting when to use it ('Use this when the user asks about getting mobile data abroad') and when to use list_supported_countries instead.

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?

Provides explicit when-to-use guidance, including fallback to list_supported_countries when no results, and detailed currency and language handling instructions. It also states when to pass specific parameters and when to mention the Annual Travel Pass, covering both the primary use and edge cases.

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