Compare prepaid travel eSIM plans by destination, data and trip length; plan multi-country trips.
Scored across 4 tools
Each tool has a distinct role: aggregate destination stats (get_destination_overview), shortlist search (search_esim_plans), single-plan detail (get_esim_plan), and multi-country trip optimization (plan_trip_esim). The main risk is overlap between get_destination_overview and search_esim_plans, since both answer 'how much does an eSIM cost in country X', but the descriptions draw a usable line between pre-comparison summary and plan shortlist.
All names are snake_case and verb-first (get_, search_, plan_), which is a consistent convention. plan_trip_esim is slightly less predictable in structure and reads ambiguously (plan as verb vs. noun), but the set is still clearly patterned.
Four tools is on the lean side but each covers a genuinely different query shape (overview, search, detail, multi-stage trip), so nothing is redundant. It is slightly thin for a comparator that might also expose provider-level listing or filtering, but well scoped overall.
The surface covers the core journey: destination overview, plan search, plan detail, and multi-country trip planning with total-price optimization. Minor gaps exist (no provider-level listing or direct side-by-side plan comparison tool), but agents can work around these via search plus detail.
Use this when someone asks how much a travel eSIM costs in a country or region, or how much choice there is, before comparing individual plans. Returns the number of plans and providers compared by MyBestSim, the cheapest plan, the best price per GB, the cheapest unlimited plan if any, the available validities, and the link to the comparison page.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language of the conversation (ISO 639-1). Links open our comparison page in that language when it exists, otherwise in English. Default "en". | |
| destination | Yes | Where the traveller is going, as they named it: a country in English or another common language ("Japan", "Japon"), an ISO 3166-1 alpha-2 code ("JP"), a well-known city ("Tokyo"), or one of the regions Europe, Asia, Africa, North America, South America, World, Balkans. Never the traveller's home country. |
| Name | Required | Description |
|---|---|---|
| cheapest | Yes | |
| language | Yes | |
| planCount | Yes | |
| destination | Yes | |
| comparisonUrl | Yes | |
| durationsDays | Yes | |
| providerCount | Yes | |
| bestPricePerGb | Yes | |
| cheapestUnlimited | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by enumerating the output content (plan count, providers, cheapest plan, best price per GB, unlimited plan, validities, comparison link), which tells the agent what to expect beyond the structured hints.
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, no filler. The second sentence is a dense list of return values, which is informative but slightly heavy; still efficient overall.
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 two-parameter read tool with full schema coverage, annotations, and an output schema, the definition is complete: it explains when to reach for it and what it summarizes. Return-value details partly duplicate the output schema, which is why it isn't a 5.
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 both parameters are fully documented in the schema itself. The description only echoes 'country or region' without adding format or resolution guidance (e.g. how city vs region vs ISO code resolve), so it adds little over 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 title and description state a specific resource ('travel eSIM costs in a country or region') and scope ('how much choice there is'), and the phrase 'before comparing individual plans' cleanly separates this aggregate-overview tool from plan-level siblings like get_esim_plan and search_esim_plans.
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 opening 'Use this when someone asks how much a travel eSIM costs... or how much choice there is, before comparing individual plans' gives clear triggering conditions. It stops short of naming the alternative tool or stating explicit exclusions, but the timing cue is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants the detail of one plan returned by search_esim_plans or get_destination_overview: coverage (number of countries, region), features, validity and price. Needs the planId and the destination it was found under.
| Name | Required | Description | Default |
|---|---|---|---|
| planId | Yes | planId returned by search_esim_plans. | |
| language | No | Language of the conversation (ISO 639-1). Links open our comparison page in that language when it exists, otherwise in English. Default "en". | |
| destination | Yes | Where the traveller is going, as they named it: a country in English or another common language ("Japan", "Japon"), an ISO 3166-1 alpha-2 code ("JP"), a well-known city ("Tokyo"), or one of the regions Europe, Asia, Africa, North America, South America, World, Balkans. Never the traveller's home country. |
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| language | Yes | |
| destination | Yes | |
| comparisonUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds real context beyond that: which fields come back, and the non-obvious constraint that the destination must be the one the plan was found under, not merely where the traveller is going.
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, no padding, and the trigger condition is front-loaded before the returned-field list and prerequisite note. Every clause carries information the 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?
With an output schema present, the description needn't explain return values, and annotations cover the safety profile. Purpose, triggering context, required inputs and the destination-matching constraint are all covered, leaving no gap that would cause a misinvocation.
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% with rich per-parameter descriptions (including the language default and the accepted destination formats), so the baseline is 3. The description adds the pairing rule linking planId to the destination under which it was found, which the schema states only implicitly.
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 (return the detail of one plan) and enumerates exactly what detail: coverage (country count, region), features, validity, price. It also names the sibling tools that produce the planId, so an agent can distinguish it from search_esim_plans and get_destination_overview 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?
"Use this when someone wants the detail of one plan returned by search_esim_plans or get_destination_overview" gives clear triggering context and a prerequisite chain. It stops short of an explicit exclusion (e.g. use search_esim_plans first to discover plans), so it is strong context rather than full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when one trip visits SEVERAL countries or regions, e.g. "Japan then China", "two weeks in France, Italy and Spain", "Thailand, Vietnam and Cambodia in March". Pass EVERY stage in travel order, with the days spent in each when known (or totalDurationDays), and the data need. Compares, at the real total price, every way to cover the trip: (a) one eSIM for every stage (regional or worldwide plan; coverage is checked country by country against the MyBestSim catalogue, never guessed from a plan name), (b) one plan per stage, and combinations (a regional plan for some stages, other plans for the rest; several regional plans). A plan is only proposed for stages it covers, for their whole duration and data need. Recommends the cheapest total; prefers fewer eSIMs unless installing more saves at least $2 per extra eSIM, and says so. Gives the reason, the number of eSIMs, total price, data and validity, and links to the MyBestSim pages where the traveller buys. List the countries themselves as stages: a region stage (Europe, Asia…) only matches plans listed on that region page. Ask how long they stay and how much data they use when they have not said: without it a 7-day trip with standard use is assumed and reported in "assumptions". Prepaid travel eSIMs only.
| Name | Required | Description | Default |
|---|---|---|---|
| dataGb | No | Data for the WHOLE trip in GB, when the traveller gives a figure (spread over the stages by days). Unlimited plans always qualify. | |
| dataNeed | No | Data appetite when no figure is given: light ≈ 0.3 GB/day, standard ≈ 0.7 GB/day, heavy ≈ 1.5 GB/day. Default standard. Ignored when dataGb is set. | |
| features | No | Features every proposed plan must include. | |
| language | No | Language of the conversation (ISO 639-1). Links open our comparison page in that language when it exists, otherwise in English. Default "en". | |
| itinerary | Yes | The stages of the trip in travel order (1 to 8). A stage is a country, a well-known city or one of the regions (Europe, Asia…). | |
| unlimited | No | true = unlimited plans only; false = fixed-data plans only; omit for both. | |
| totalDurationDays | No | Whole trip length in days, when the stages are not dated one by one (a single plan must last this long). |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| dataGb | Yes | Data needed for the whole trip; null for unlimited-only. |
| stages | Yes | |
| currency | Yes | |
| language | Yes | |
| perStage | Yes | |
| totalDays | Yes | |
| singlePlan | Yes | |
| assumptions | Yes | What was assumed because the traveller did not say it (null = given). Ask for the real value to refine. |
| combination | Yes | |
| recommendation | Yes | |
| optionsByEsimCount | Yes | Cheapest real total for each possible number of eSIMs (every split of the stages compared), to show what one more or one fewer eSIM costs. |
| plansCoveringAllStages | Yes | Plans proven to cover every stage (listed on the page of each stage, or with a catalogue line in each country of the trip), before the length/data/feature criteria. |
| singlePlanAlternatives | Yes | Other single plans covering every stage (up to 2). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe, read-only, idempotent, closed-world operation, and the description layers substantial extra behavior on top: coverage is verified country by country against the catalogue rather than guessed from plan names, recommendations follow a stated $2-per-extra-eSIM rule, defaults are reported in 'assumptions', and only prepaid plans are considered. This is exactly the context annotations cannot carry.
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?
Long, but dense and front-loaded: the trigger condition and stage-input instructions come before the comparison logic. A few clauses (the enumeration of combination types) run longer than needed, but almost every sentence carries operational 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?
An output schema exists, so return values need not be explained, yet the description still tells the agent what the answer will contain (reason, eSIM count, total price, data, validity, links). For a complex 7-parameter planning tool, nothing essential 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 already 100%, so the baseline is 3, but the description adds real meaning: stages go in travel order, countries must be listed as their own stages because a region stage only matches region-page plans, and missing duration/data triggers a 7-day standard-use default. The 'totalDurationDays vs per-stage days' interplay is clarified in prose as well.
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 ('Plan eSIMs') plus a precise scope: multi-country/multi-region trips. Examples like 'Japan then China' make the resource concrete, and the multi-stage framing clearly differentiates it from sibling tools such as search_esim_plans and get_esim_plan.
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?
Opens with an explicit trigger condition ('Use this when one trip visits SEVERAL countries or regions') and gives guidance on when to ask the traveller for duration/data. It never names an alternative sibling for the single-country case, so the routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone is choosing a travel eSIM or needs mobile data abroad for a given country or region, e.g. "cheapest eSIM for Japan", "10 GB for two weeks in Europe", "unlimited data in the USA". Returns a shortlist (up to 10, at most 2 per provider) from the MyBestSim comparator: data allowance, validity, price in USD (and EUR), 5G/hotspot/calls/SMS, and the link to the full comparison page on mybestsim.com where the traveller buys from the provider. Pass durationDays and dataGb (or dataNeed) whenever the traveller mentions trip length or usage, and ask for them when unknown: without them a 7-day trip with standard use (0.7 GB/day) is assumed and reported in "assumptions"; with dataGb but no durationDays, plans valid for fewer than 7 days are excluded. For a trip through several countries or regions, call plan_trip_esim with every stage instead of searching each country. Prepaid travel eSIMs only: not home mobile contracts, physical SIM cards or a carrier's roaming pass.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | value (default) = the cheapest plan that covers the data need (given, or assumed standard use) for the trip length; with unlimited=true and no figure, the lowest price per GB of fair use; cheapest = lowest total price; data = most data; days = longest validity. The need and trip length filter every sort. | |
| limit | No | Number of plans to return (default 5). | |
| dataGb | No | Minimum data in GB, when the traveller gives a figure. Unlimited plans always qualify. | |
| dataNeed | No | Data appetite when no figure is given: light ≈ 0.3 GB/day (maps, messaging), standard ≈ 0.7 GB/day (social, some video), heavy ≈ 1.5 GB/day (streaming, hotspot). Multiplied by durationDays; without it a 7-day trip is assumed, and plans valid for fewer than 7 days are excluded. Ignored when dataGb is set. | |
| features | No | Features every returned plan must include. | |
| language | No | Language of the conversation (ISO 639-1). Links open our comparison page in that language when it exists, otherwise in English. Default "en". | |
| unlimited | No | true = unlimited plans only; false = fixed-data plans only; omit for both. | |
| destination | Yes | Where the traveller is going, as they named it: a country in English or another common language ("Japan", "Japon"), an ISO 3166-1 alpha-2 code ("JP"), a well-known city ("Tokyo"), or one of the regions Europe, Asia, Africa, North America, South America, World, Balkans. Never the traveller's home country. | |
| maxPriceUsd | No | Maximum total price in USD. | |
| durationDays | No | Trip length in days: plans valid for fewer days are excluded. Default 7 (reported in assumptions). |
| Name | Required | Description |
|---|---|---|
| sort | Yes | |
| plans | Yes | |
| matched | Yes | Plans matching the criteria, before the shortlist. |
| currency | Yes | |
| language | Yes | |
| minDataGb | Yes | |
| totalPlans | Yes | Plans compared for the destination (all of them, whatever their commercial terms). |
| assumptions | Yes | What was assumed because the traveller did not say it (null = given). Ask for the real value to refine. |
| destination | Yes | |
| comparisonUrl | Yes | |
| minDurationDays | Yes | Minimum validity applied (given, or assumed); null when none. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing the shortlist cap (up to 10, at most 2 per provider), the default-trip assumption (7 days at 0.7 GB/day, reported in 'assumptions'), and the filtering consequence of passing dataGb without durationDays. It also clarifies that results link out to mybestsim.com where the purchase happens, so the agent knows this is a comparator, not a booking 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?
Front-loaded with the use case and examples, then behaviour, then exclusions, so an agent gets the essentials in the first sentence. It is a single long paragraph that mildly overlaps the schema (sort, limit, destination wording) and re-states the returned fields despite an output schema, costing a point.
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 10-parameter filtering tool, the description covers trigger, alternatives, defaults, filtering side effects, and purchase-link semantics, while annotations cover safety and an output schema covers return shape. Nothing needed to 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 the baseline is 3, but the description adds real meaning: the interaction between dataGb and durationDays, the exclusion of sub-7-day plans, and the instruction to request these values when unknown. Most individual enum and default semantics remain schema territory, so it stops short of 5.
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/compare travel eSIM plans) and names the sibling it is not (plan_trip_esim for multi-country trips). An agent can distinguish it from get_esim_plan and get_destination_overview 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?
Explicit trigger conditions with example utterances ('cheapest eSIM for Japan'), an explicit alternative for the multi-country case (call plan_trip_esim with every stage instead of searching each country), and explicit exclusions (prepaid travel eSIMs only, not home contracts, physical SIMs or roaming passes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_destination_overviewget_esim_planplan_trip_esimsearch_esim_plansSearch, compare & buy prepaid travel eSIM data plans for 190+ countries in 40 currencies, including regional plans and a 12-month Travel Pass.
Compare travel eSIM plans by country, days and data — live prices and links to buy on esimoa.
Search travel eSIM data plans for 230+ destinations with live prices and purchase links.
Find prepaid travel eSIM plans for 200+ destinations with live prices, specs and a buy link.
Add one secure layer between your agents and this server.
