eSIMpass

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond them: the answer is a lookup against a curated vendor list, the result is conditional on carrier-unlock status, and absence from the list is not proof of incompatibility.

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 question, then the two caveats that matter. No filler, though the phrasing 'from the models eSIMpass documents' is slightly compressed and could be clearer about the lookup source.

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

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

No output schema exists, so the description carries the return-value burden; 'whether a phone model supports eSIM' implies a yes/no verdict but the exact response shape is not spelled out. The critical ambiguities that would mislead an agent (carrier-unlock precondition, false negatives) are covered.

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 schema already gives worked examples ('iPhone 15 Pro', 'Galaxy S24', 'Pixel 8'), so the description has little to add. It only reinforces that the value is a phone model; baseline 3 is appropriate when the schema carries the parameter documentation.

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 resource and scope: whether a given phone model supports eSIM, plus the bounded data source (models eSIMpass documents for Apple, Samsung and Google). It is clearly distinct from siblings like get_plans or create_checkout_link, but it never explicitly says so, since differentiation is left to inference from the domain.

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 usable context for when the answer applies (device must be carrier-unlocked) and an important exclusion on how to read a negative result ('a model not in the list is not necessarily incompatible'). It does not name a sibling alternative, but no sibling performs this lookup, so the omission is minor.

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 readOnly/idempotent/non-destructive, and the description reinforces this correctly by stating it does not pay or place an order. It goes further with the post-purchase lifecycle (confirmation page, Install button, QR code, private eSIM link), though it does not address link expiry or whether repeated calls return an identical URL, which matters given idempotentHint=true.

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

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

Front-loads the deliverable in the first sentence and follows with the outcome flow. The enumeration of payment methods is slightly extraneous to invoking the tool but is defensible as user-facing context; overall there is little waste.

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 100% schema coverage, an output schema, and full annotations, the description supplies the remaining behavioral context an agent needs: what the link is for and what it does not do. Only link lifetime and idempotency semantics are 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 the schema already carries the parameter documentation; baseline is 3. The description adds only one useful pointer, that plan takes the name exactly as get_plans returns it, which mildly reinforces the plan parameter without adding new syntax or constraint detail.

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 artifact: produces a checkout URL on esimpass.com with one plan pre-selected, and explicitly clarifies it is not a payment or order. This distinguishes it cleanly from siblings like get_plans (discovery) and fetch (retrieval).

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 clear workflow context (the traveller opens the link and pays, then gets an install page) and routes the agent to get_plans for the plan-name input format. It lacks an explicit when-not or a named alternative for other purchase paths, but the intended use is unambiguous.

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 annotations already covering readOnly/idempotent/non-destructive/closed-world, the bar is lower, and the description adds genuinely non-annotated context: the exact nature of the returned payload (plans, live prices, checkout link). It stops short of 5 by omitting error behavior for an unknown id and any indication of response size or format.

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 with zero filler; the payload contents are front-loaded and the id-provenance constraint follows immediately. 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?

For a one-parameter read tool with fully documented schema and complete annotations, and with no output schema in play, the description covers purpose, sourcing of the id, and the shape of the result. Only failure modes for a bad/missing id are left unstated.

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

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

Schema description coverage is 100% and the single parameter is fully documented there, including its example value "esim-japan". The description's "The id comes from search" restates the schema's provenance note rather than adding format or validation detail, 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 conveys retrieving a single destination and enumerates the payload (plans, live prices, a checkout link per plan), which is far more specific than a name/title restatement. It falls short of 5 because the verb is only implied by the tool name and it never explicitly contrasts itself with siblings like get_plans or search_destinations.

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 id comes from search" establishes the sequencing prerequisite and implies this is a follow-up call to a search. However, it gives no when-not-to-use guidance and does not distinguish this from siblings such as get_plans or search_destinations, leaving the agent to infer selection.

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

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

Adds context beyond readOnly/idempotent annotations: the result contains the traveller's private eSIM details, the input link is validated and refused if invalid, and install links work only on the device that opens them.

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 precondition and outcome; dense but each sentence carries information, though the parenthetical URL example adds minor bulk.

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?

Complete for a single-param tool with an output schema: precondition, accepted input, platform requirements, refusal behavior and return content are all covered.

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; the description adds the accepted syntax (the private eSIM link or the token at its end) and constrains other values as invalid, adding meaning beyond the schema.

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

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

States a specific resource (one-tap install links for a purchased eSIM) with explicit platform support (iOS 17.4+, Android 10+) and the manual codes, distinguishing it from fetch/get_plans/check_device siblings.

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 'After the traveller has paid' as the precondition and instructs that only the private eSIM link from the order confirmation page is accepted: 'any other value is refused.'

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 this a read-only, idempotent read, so the bar is lower. The description still adds real semantics: regional plans enumerate covered countries and absence from that list means no coverage, plus an explicit note that prices/plans are current at call time. That is genuinely 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.

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

Three tight sentences, front-loaded with the core payload and immediately followed by the regional-coverage caveat. The closing freshness sentence is slightly redundant but does useful work signaling non-cached results.

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 spelled out; the description nonetheless flags the two facts an agent would otherwise miss (country list semantics, live pricing). Complete enough to call correctly, with only the missing sibling routing as a 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%, so the schema already documents currency, unlimited and destination. The description only loosely reinforces 'one destination' and 'live prices' and adds no parameter syntax or format detail, 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 concrete resource (plans on sale for one destination) plus the payload contents (live prices, data, validity, product URL). It is specific enough to distinguish from search_destinations/fetch, but never names or contrasts a 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?

Usage is only implied: you need a destination, and the schema points at search_destinations for the slug. The description itself gives no when-to-use or when-not guidance and no routing away from 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?

The annotations already declare read-only, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds the return linkage ('ids that fetch takes'), which is genuinely useful, but says nothing about match semantics (exact vs fuzzy), result contents, or empty-result behavior – and there is no output schema to fill that gap.

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 no padding. 'in the shape ChatGPT connectors use' is a slightly opaque bit of protocol jargon, but overall the text is efficient.

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 simple one-parameter read tool with full schema coverage and annotations, the essentials are present, and the fetch-chaining hint partially compensates for the missing output schema. It remains thin on what a result actually contains and how matches are determined.

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% for the single 'query' parameter, so the schema already documents it. The description's 'by place name' merely restates the schema's 'Place name.' without adding format or matching details, 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 and resource ('Search eSIMpass destinations by place name') plus the scoping field, so an agent knows exactly what is being searched. However, it never distinguishes itself from the near-identically named sibling 'search_destinations', which leaves real ambiguity about which search tool to pick.

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?

'Returns ids that fetch takes' hints at a search-then-fetch pipeline, but there is no explicit when-to-use guidance and no exclusion or alternative named. With a sibling literally called 'search_destinations', the absence of any routing rule is a notable 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 the safe-read profile (readOnly, idempotent, non-destructive), so the description's job is to add beyond that. It does: cities are not distinct destinations but covered by their country's plans, and the returned slug is the key other tools expect — both are non-obvious behavioral facts. It omits any note on result volume, fallback when nothing matches, or ranking 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?

A single dense sentence that front-loads the purpose, then the accepted value forms, then the return value. No filler and nothing that could be dropped 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?

No output schema exists, so the description must cover the return value — and it does, stating that matching destinations are returned along with the slug consumed by get_plans and create_checkout_link. For a one-parameter lookup tool, an agent has everything needed to call it and use its result.

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 a single parameter at 100% schema coverage, the baseline is 3. The description goes beyond the schema by enumerating the accepted query shapes (country, region, city) and showing that regions like 'Europe', 'Asia' and 'Global' are valid, which the schema does not state.

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 ('Find the eSIMpass travel eSIM for a place') and enumerates the accepted place categories (country, region, city) with concrete examples. It also names the downstream consumers (get_plans, create_checkout_link), which separates it from those siblings without the agent opening any 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 clear context for when to reach for this tool: any place lookup, including cities that resolve to their country's plans, and it explains the workflow role of the result (feeding get_plans and create_checkout_link). It stops short of explicit exclusions (e.g., when to use the generic 'search' sibling instead), so it is not a full when/when-not statement.

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