Commerce for Agents

Compare Travel eSIMs

compare-esims

Read-onlyIdempotent

Use this when the user needs phone data abroad: a travel eSIM, an international data plan for a trip, avoiding roaming charges, "will my phone work in Japan", the cheapest data for N days in a country, or unlimited travel data. Ranks a curated catalog of country eSIM packages (Airalo, Saily, Ubigi, Holafly, Nomad) by USD list price among packages valid for the whole trip with at least the data needed, listing each provider's cheapest package first and then the remaining packages by price, and shows price per GB and per day with a provider link. It does not check phone compatibility; the phone must be eSIM-capable and unlocked. Destinations: AU, BR, CA, CO, DE, ES, FR, GB, GR, IT, JP, KR, MX, NL, PT, TH, TR, US. Inputs: destination (country code), days, optional data_gb, unlimited and providers. No personal data is used. Keywords: travel eSIM, eSIM for Japan, cheapest eSIM, international data plan, roaming.

Input Schema

Name	Required	Description
`days`	Yes	Trip length in days; packages must be valid at least this long.
`data_gb`	No	Minimum data needed in GB (default 1). Ignored when unlimited is true.
`providers`	No	Only these providers, e.g. ["Airalo", "Saily"].
`unlimited`	No	true: only unlimited-data packages; false: exclude them; omitted: unlimited packages also qualify.
`destination`	Yes	Destination country, ISO 3166-1 alpha-2 (e.g. JP, US, GB). Supported: AU, BR, CA, CO, DE, ES, FR, GB, GR, IT, JP, KR, MX, NL, PT, TH, TR, US.

Output Schema

Name	Required	Description
`days`	Yes
`basis`	Yes
`closest`	No	When nothing qualifies: the largest package that lasts the trip.
`message`	No
`results`	Yes
`excluded`	Yes
`disclosure`	Yes
`destination`	Yes
`catalogVerifiedOldest`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / destination / description

Previous value: -"Destination country, ISO 3166-1 alpha-2 (e.g. JP, US, GB, FR, IT, ES, TH, MX)."New value: +"Destination country, ISO 3166-1 alpha-2 (e.g. JP, US, GB). Supported: AU, BR, CA, CO, DE, ES, FR, GB, GR, IT, JP, KR, MX, NL, PT, TH, TR, US."

Changed2 schema fields changedOct 15, 2026
- addedOutput schema / properties / closest / properties / offerTargetUrl
```
Added value: +{
+  "description": "Where offerUrl redirects to.",
+  "type": "string"
+}
```
- addedOutput schema / properties / results / items / properties / offerTargetUrl
```
Added value: +{
+  "description": "Where offerUrl redirects to.",
+  "type": "string"
+}
```
AddedOct 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and closed-world; the description goes further by disclosing the ranking algorithm, that each result carries a provider link and price per GB/day, that no personal data is used, and the hard limitation that phone compatibility is not checked. The one remaining gap is any statement about result count, pagination, or what happens when no package matches.

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

Conciseness3/5

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

The trigger sentence is well front-loaded and the behavioral sentence earns its place, but the trailing 'Keywords: travel eSIM, eSIM for Japan, cheapest eSIM, international data plan, roaming' block duplicates the opening triggers verbatim and the supported-destination list repeats the schema's 'Supported:' list. Roughly a third of the text is redundant.

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?

With an output schema present the description need not explain return values, and it still covers the safety profile indirectly, the supported destination set, the inputs, the ranking behavior, and its key limitation. An agent has everything needed to call it correctly.

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

Parameters3/5

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

Schema coverage is 100% and each parameter description already carries real semantics (defaults, exclusion rules, ISO codes, unlimited interaction). The description's 'Inputs: destination, days, optional data_gb, unlimited and providers' mostly restates the schema and adds no format or edge-case detail beyond it, so baseline 3 is correct.

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 ('Ranks a curated catalog of country eSIM packages ... by USD list price') plus the exact ranking rule (cheapest package per provider first, then remaining by price) and the provider set. This clearly separates it from siblings like compare-broadband and compare-mobile-plans 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.

Usage Guidelines5/5

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

Opens with a rich enumeration of user intents that select this tool ('phone data abroad', 'avoiding roaming charges', 'will my phone work in Japan', 'cheapest data for N days'), and adds explicit when-not conditions: it does not check phone compatibility and the device must be eSIM-capable and unlocked. It does not name a competing sibling tool, but the trigger set and exclusions are detailed enough to route the agent confidently.

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

All Commerce for Agents 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?