varioroam eSIM configurator

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

Annotations already establish that this is a safe, read-only, idempotent, non-destructive operation. The description adds useful context by specifying the pricing basis (1 GB · 7 days) and that the tool returns network-level details, but it does not discuss rate limits, freshness, or result shape.

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

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

The description is a single dense sentence with no filler. It front-loads the resource and scopes the returned data efficiently, though the parenthetical pricing detail makes it slightly hard to parse at first read.

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 read-only tool with no output schema, the description sufficiently covers the returned fields and the pricing reference. It does not describe the return container or pagination, but annotations and the schema handle most remaining safety and parameter concerns.

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 75%, leaving mainly currency undocumented. The description reinforces that only one country is queried but adds no syntax or format guidance for bucket, currency, language, or destination 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 clearly identifies the resource (mobile networks available per country) and the exact data returned: operator name, 4G/5G, and a reference eSIM price per network. It does not explicitly name or contrast with sibling tools, so it falls 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?

It implies the tool is used to determine which network is cheapest and what others add, but it does not state when to use it instead of alternatives such as price_grid or recommend_config. Usage is inferable but not explicit.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the useful nuance that content is presented 'in the shop's own words' (i.e. shop-authored copy rather than neutral data), but says nothing about return format, freshness, or that results are localized by the bucket param.

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 front-loaded sentences with no filler; the topic list is dense but each item maps to a real question an agent might get. The enumeration is long but earns its place by signalling coverage boundaries.

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 read-only FAQ-style retrieval tool with no output schema and two optional, fully documented parameters, the description gives enough to know what content will come back and when to call it. Return shape and localization effects are the only remaining gaps.

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 baseline is 3. The description mentions no behaviour for bucket or language even though these control currency, locale and link language, so it adds no 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?

The description names a specific resource (shop facts) and enumerates the topical coverage: configurable eSIM, ranges, delivery, payment, hotspot, activation, top-ups, e-mails, support. It is distinguishable from the price-oriented siblings via the closing clause, though it does not name them directly.

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?

'Use for any question that is not a price' gives a clear use condition plus an explicit exclusion that routes pricing questions away from this tool. It stops short of naming the alternative tools (price_grid, quote_esim), which keeps it from a 5.

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 closed-world, so safety is covered. The description adds genuinely useful behavioral context by defining the price basis (1 GB, 1 day, cheapest network), which prevents misreading the 'starting price'. It omits pagination/size limits, which keeps it below 5.

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

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

One sentence describing contents plus one sentence on usage; zero filler and the price-basis qualifier is included exactly where it prevents ambiguity.

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

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

With no output schema, the description usefully sketches the return shape (country, network count, starting price basis), and the schema handles the inputs. Only the absence of result-size or freshness details keeps it from being fully complete for a list tool.

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

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

Schema description coverage is 100%, so bucket, currency and language are fully documented in the schema, including the default-from-language behavior. The description adds no parameter meaning beyond that, making the baseline 3 correct.

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

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

States a specific verb+resource ('List destinations') and what each row contains (countries, selectable network count, starting price with its 1 GB / 1 day / cheapest-network basis). It distinguishes itself functionally from single-country pricing siblings, but never names a sibling to route against.

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 usage context: 'check coverage or compare many countries at once,' which implies a survey/browse intent versus the per-country quoting tools. No explicit when-not-to-use or named alternative (e.g. price_grid, quote_esim) is given.

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/closed-world, so the safety profile is covered. The description adds real behavior beyond them: the 5-country cap, the default sizing rule (gb omitted = 1.5 GB/day from days), and the per-country output format with total. It doesn't discuss failures (e.g. an unsupported destination) or fallback when a country has no eSIM, which is why it isn't a 5.

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

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

One dense paragraph, front-loaded with purpose, then the per-country day rule, then return shape, then routing to alternatives — a sensible order. Slightly redundant with the schema's own days description, and the parenthetical explanations stack up, but no sentence is filler.

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

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

For a 7-param, 1-required tool with no output schema, the description covers the destinations, days, gb, per_country and return values adequately. The minor gaps are the locale params (bucket, currency, language) and no guidance on what happens when a destination in the list isn't sold — small omissions for a read-only quoting 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 86%, so the baseline is 3, but the description earns more by hammering the most error-prone semantic: days is PER COUNTRY, never trip length, with a concrete worked example (12-day Japan+Thailand trip = 7 + 5). That's the exact misreading an agent would make from the schema alone. bucket and currency get no description treatment, capping it at 4.

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

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

States a specific verb and resource ('a trip through several countries (max 5)'), the per-country quoting model, and the exact return shape (one line per country with price and buy_url, plus total). It explicitly separates itself from quote_esim (single country) and recommend_config (usage descriptions), so an agent can pick it without opening the schema.

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

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

Gives an explicit trigger ('when the customer names two or more countries and a size, 2–5 destinations') plus named alternatives with their selecting conditions: quote_esim for one country, recommend_config when they describe usage. Both when-to-use and when-not-to-use are covered.

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 closed-world, so the safety profile is fully covered. The description adds the 8 × 8 cap (also encoded in the schema) and the useful consistency note that prices match quote_esim, but discloses no pricing edge cases, currency behavior, or latency/cost traits beyond that.

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

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

Two tight sentences, front-loaded with the capability and its cardinality bound before the use case. The closing note on quote_esim pricing parity is short and earns its place by clarifying result consistency.

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 read-only pricing lookup with rich schema descriptions and no output schema, the description covers scope, limits and intended use adequately. It could be fuller on how the grid result is shaped or what currency/bucket defaults resolve to, but nothing critical to calling it correctly is missing.

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

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

Schema description coverage is 86%, so the schema already documents gb, days, bucket, language, networks and destination in detail. The description adds only the aggregate 8 × 8 bound and 'one country per eSIM', which the schema largely repeats; baseline 3 is appropriate when the schema does the heavy lifting.

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 (prices) with explicit scope: a grid of GB × days combinations for one country in a single call, capped at 8 × 8. It also names the sibling quote_esim and ties its pricing to it, so the agent can distinguish batch-grid pricing from a single quote without opening either schema.

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

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

Gives concrete intent ('compare with other providers' or 'find the best fit for a trip') and implies the batch use case, which is clear guidance. It stops short of an explicit when-not rule (e.g. 'use quote_esim instead for a single combination'), so it lands at a strong 4 rather than a full 5.

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 establish readOnly/idempotent/non-destructive, but the description adds real behavioral context: the price must be quoted verbatim ('never compute or scale it yourself') and the response carries a buy_url for reference only. It doesn't cover failure modes (unsupported destination, no matching config), so it falls just short of a 5.

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 usage trigger, then the behavioral constraint and the hand-off to start_checkout. Dense but every clause carries routing or behavior information; only mild crowding of three distinct instructions into one sentence.

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-value detail is unnecessary, and the description already covers when to use it, how to treat the result, and the next tool in the workflow. It omits any note about invalid or unavailable configurations, which is the one gap for a pricing tool.

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

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

Schema description coverage is 86%, so the schema already explains gb, days, destination, networks, bucket and language in detail. The description adds only a restatement of the GB/day ranges, not new syntax or defaults beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('the exact price of one eSIM configuration') with the key dimensions (country, GB 1–100, days 1–90, networks), which clearly separates it from price_grid (bulk grid) and recommend_config (sizing advice). An agent can route between quote_esim and its siblings without opening a 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?

Explicitly scopes timing ('Use while the customer is still deciding') and names the alternative plus the trigger that selects it ('when the customer says they want to buy, call start_checkout instead'). The schema also points to recommend_config for uncertain data amounts, so the when/when-not guidance is complete.

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?

Beyond the readOnly/idempotent annotations, the description discloses the return shape (three tiers with ×1.5 and ×2 multipliers, each with price, networks, reason, buy_url), trip totals, an optional budget check, and the error behavior for a missing country. It also establishes pricing parity with quote_esim, which an agent needs for consistency of answers.

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 trigger condition is front-loaded in the first clause, and the paragraph is dense with useful detail rather than filler. It is a single long run-on sentence-heavy block, however, so the return-shape and error details are harder to scan than a short structured breakdown would be.

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 an 11-parameter tool with no output schema, the description covers the trigger, required inputs, the three-tier output, totals, budget check, pricing parity, and a failure mode — everything an agent needs to select and call it correctly. Nothing material is 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 coverage is already 91%, so the baseline is 3, but the description adds meaning the schema lacks: the either/or requirement between destination and destinations (the schema marks only days as required), the gb_per_day-over-usage precedence, and the budget marking behavior. The remaining parameter detail is left to 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?

The description states a specific verb and resource — it sizes a data pool from the data guide and returns three server-quoted configurations per country — and frames the trigger precisely ('when the customer describes a trip instead of a size'). It is distinguishable from siblings like quote_esim (pricing parity noted) and get_networks (referenced for operator names).

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?

It gives clear context ('country (or up to 5), days and how they use data') and explicitly states the required-input constraint ('one of the two is required; a call without a country fails with invalid_argument'). The contrast 'instead of a size' implicitly routes to the sibling that handles explicit sizes, but no alternative is named outright, so this falls short of a full when/when-not with named alternatives.

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 behavior, but the description adds important context: no account needed, the eSIM is delivered on screen and by e-mail after payment, and unsupported capabilities are ruled out. This is rich behavioral disclosure 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?

The trigger condition is front-loaded in the first sentence, and each subsequent clause adds usable context. It is dense with parenthetical details, but appropriate for a tool whose use must be tightly constrained.

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

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

The tool has an output schema, seven parameters, and high schema coverage; the description still covers when to use it, what it returns, what happens after payment, and the relevant alternative. Nothing critical 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 86%, so the schema already carries most parameter meaning. The description does not add parameter syntax, format, or pricing logic beyond what the schema provides, so it stays at the baseline for high-coverage schemas.

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 action and resource: the checkout handoff that returns buy_url, final price, and a checkout block. It explicitly distinguishes itself from quote_esim for price comparisons, so an agent can route to it without opening the sibling 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 explicit trigger phrases and the condition for use: only once the customer has decided to buy. It also names the alternative for the comparison stage and lists exclusions such as no in-chat order tracking and no discount codes.

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