MyBestSim eSIM comparator

Compare travel eSIM plans

search_esim_plans

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?