MyBestSim eSIM comparator

Plan eSIMs for a multi-country trip

plan_trip_esim

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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).

Output Schema

TableJSON Schema

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).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All MyBestSim eSIM comparator tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?