SimoraGo travel eSIM plans

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

Annotations already declare read-only, idempotent, non-destructive, so safety is covered. Beyond that the description discloses the tri-state result (yes / no / not published), the per-plan fields returned (name, validity, price in USD), a summary line format, and the ordering rule 'own page first, then regional plans' — substantive behavior with no output schema to carry it.

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 core action, then the nuance, then the output shape and the alternate mode. Three sentences, all load-bearing. The rhetorical example question is slightly padded but is the fastest way to convey the regional-plan trap.

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, yet the description specifies exactly what comes back per plan and in aggregate, plus the fallback mode's ordering. For a 3-parameter read tool with full annotation coverage, nothing an agent needs to select or call 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 coverage is 100%, so baseline is 3. The description still adds real meaning for the optional destination parameter: it changes the query direction entirely (list every destination containing the country, ranked own page first), and it clarifies that the country input is validated against real plan coverage rather than destination membership.

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: check whether a country is covered, plan by plan. The Europe/France/Turkey example and the 'destination's country list is not every plan's coverage' line make it unmistakably distinct from search_plans or get_plan, which the agent would otherwise confuse with a coverage query.

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: use it to check whether a specific country is on a specific plan's coverage list, and explains the reverse mode (omit destination to find all destinations including the country). It also warns why this differs from reading a destination page. It does not explicitly name which sibling to use instead, so it falls short of a full when/when-not/alternative rubric.

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 covered. The description adds genuinely useful boundary context: payment happens on simorago.com in a browser and this tool performs no purchase, and it discloses that the response carries a purchasable flag indicating whether checkout is currently open.

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

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

Two sentences, front-loaded with the core action and followed by the purchase-boundary clarification and routing hint. Slightly awkward phrasing ('with purchasable') but no wasted sentences.

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 two-parameter read tool with no output schema, the definition covers the action, the non-transactional nature, the purchasable return signal, and the sibling routing. Only minor gaps remain, such as what happens if checkout is closed or a plan id is invalid.

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%, including the plan_id provenance note and the locale enum, so the schema does the heavy lifting. The description only restates 'for one plan' and adds no syntax, format, or fallback details beyond the schema, which is the baseline 3.

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 (get the simorago.com checkout page link for one plan) and clarifies what the result includes (purchasable flag). It also explicitly distinguishes itself from the purchase action and from search_plans, so an agent can identify 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?

Explicitly says when to use it (someone wants to buy a plan found with search_plans), naming the natural predecessor tool. It lacks an explicit when-not clause, but the 'this tool does not buy anything' line implicitly bounds the usage.

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 real value by detailing the payload contents (throttled speed, hotspot/tethering rule, top-up eligibility, whether checkout is open) which matter for downstream decisions. It omits failure behavior for an unknown or stale plan_id and whether pricing varies by locale, so it is not complete.

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: the capability and the enumerated facts first, then the usage rule. The long field list is dense but every item carries decision-relevant information given the absence of an output schema; nothing is redundant with the schema or annotations.

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 compensates by enumerating the returned fields, which is exactly what an agent needs to know before calling. The remaining gap is edge-case behavior (invalid/expired id, locale effect on currency), which is minor for a read-only single-record lookup.

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%: plan_id already says 'exactly as returned by search_plans' and locale documents its enum and default. The description only restates the id lookup ('by its id') and adds no new meaning about locale or id formatting, so the baseline of 3 applies.

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

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

States a specific verb (get) and resource (one travel eSIM plan) plus the lookup key (id), then enumerates the returned facts: price in USD, data, validity, daily limit/throttled speed, hotspot rule, networks, covered/not-covered countries, SMS, 5G, top-up and checkout status. This is clearly distinct from siblings like search_plans (discovery) and check_coverage (coverage-only lookup).

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 gives the sequencing condition: 'Use it after search_plans when someone asks about a specific plan,' which tells the agent both the trigger and the prerequisite tool. It does not state when NOT to use it (e.g., for browsing options or bulk comparison), so it stops short of full 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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the scope of content returned, which is modest value, but says nothing about whether this is static published text, whether the locale affects the policy body or just names/links, or how fresh the content is.

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 resource and its contents, followed by the use case. Efficient, though the parenthetical about the emailed install link and QR code is detail that sits awkwardly inside a purpose statement and slightly bloats it.

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-optional-parameter, read-only lookup with no output schema, the definition covers what an agent needs: what the tool returns, which topics it answers, and its safety profile via annotations. Nothing blocking remains before a correct call.

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 optional 'locale' enum parameter is fully documented in the schema, including its default. The description never mentions locale or how language selection interacts with the returned policies, so it adds no meaning beyond the structured field — the baseline of 3 applies.

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

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

States a specific verb and resource ('Get SimoraGo's published policies') and then enumerates the exact policy domains covered: refunds/cancellation, eSIM delivery/installation, payment checks, and device compatibility. That enumeration cleanly separates it from siblings like search_plans, get_plan, get_checkout_link and check_coverage, so an agent can route without 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?

'Use it for questions about refunds, installing or activating the eSIM, or whether a phone will work' gives concrete triggering conditions rather than implied usage. It lacks any explicit exclusion or pointer to a sibling (e.g. 'for plan pricing use search_plans'), so routing away from this tool is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value by disclosing the payload contents (plan counts, lowest USD price, ISO codes, page links), which matters because there is no output schema. It doesn't mention rate limits or result size limits, but for a small static catalog that's minor.

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, both earning their place: the first defines scope and return shape, the second handles sibling routing. No filler, and the alternatives come after the definition where they belong.

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 correctly explains what the response contains (destinations, plan counts, lowest price, ISO codes, links). Combined with annotations and the fully described locale enum, an agent has everything needed to invoke and interpret this 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?

The single locale parameter is fully documented in the schema, including allowed values, default, and what it localizes. The description adds no parameter-level detail, so the schema does all the work and 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 (list every country/region with eSIM plans) and enumerates the returned fields, so the agent knows exactly what this call yields. It is clearly distinct from check_coverage and search_plans, which are named.

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 to use it to find the destination slug for search_plans, and routes the different question (does a plan cover a country) to check_coverage. Both the when and the named alternative are present.

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 read-only, idempotent, non-destructive behavior, so the description's job is to add result semantics — and it does, disclosing cheapest-first ordering, throttling rules, hotspot policy, uncovered countries, and checkout availability. This is substantive context beyond the annotations, though it does not discuss pagination or empty-result 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?

The when-to-use guidance is correctly front-loaded, but the return-value sentence is a long comma-chained list in a single dense paragraph. Given there is no output schema the detail is earned, yet splitting it or trimming the enumeration would improve scannability.

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 takes on the burden of describing the response and does so thoroughly (price, data allowance, validity, networks, link, checkout status). All six optional parameters are meaningful and the zero-required-parameter design is implicitly clear from 'Leave out to search every destination' plus the schema.

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 adds interpretive framing: trip_days means only plans valid for the whole trip, and min_gb means the data actually needed, plus examples of country/region values. That clarifies intent of the filters rather than merely repeating 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 verb and resource ('search and compare travel eSIM data plans') and frames it around the user question it answers. It is clearly distinguishable from siblings such as get_plan (single plan detail) and list_destinations (destination discovery).

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 trigger scenarios: choosing a travel eSIM, finding the cheapest plan, comparing plans, or avoiding roaming charges. It also tells the agent which inputs to supply. It stops short of naming when to prefer a sibling (e.g. get_plan for a known plan), so it is clear context without explicit exclusions.

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