SimFuse eSIM Storefront

Plan eSIMs for a trip

plan-trip

Read-onlyIdempotent

Answer "which eSIM should I buy for this trip?". Give it the stops, a country code and the days spent in each, and it compares one plan covering the whole route against one plan per country against a mix of the two, on live prices, then flags the cheapest option that covers everything and explains the choice in a sentence you can quote. It also estimates the data each stop needs, names any country SimFuse cannot cover, and returns package ids that go straight into create-checkout-session. Use it whenever a trip has two or more countries, and for a single country when the traveller wants a recommendation rather than a list. Read-only: nothing is reserved and nothing is charged, and the totals are today's catalog prices, not a quote held for later.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "stops": "<stops>"
    },
    "name": "plan-trip"
  }
}

Input Schema

Name	Required	Description	Default
`start`	No	Optional. Departure date as YYYY-MM-DD, e.g. "2026-04-18". Only used to date the stops in the answer; it does not change prices. Defaults to today.
`stops`	Yes	The trip, one entry per country, in travel order. 1 to 12 stops, e.g. [{"country":"JP","days":7},{"country":"KR","days":5}].
`usage`	No	Optional. Trip-wide data usage for stops that do not set their own: "light" (about 300 MB a day), "regular" (about 800 MB a day) or "heavy" (about 2 GB a day). Defaults to "regular".	regular
`currency`	No	Optional. ISO 4217 three-letter code every price is quoted in, e.g. "USD", "EUR", "GBP". Defaults to EUR. An unknown code falls back to EUR rather than failing.

Output Schema

Name	Required	Description
`trip`	Yes	The trip as it was understood, which is worth reading back to the traveller.
`reason`	Yes	One sentence explaining the recommendation, written to be quoted to the traveller verbatim.
`options`	Yes	Every way of buying the trip that we could price, cheapest-first within each strategy. Empty when nothing we sell covers it.
`checkout`	Yes	How to act on the recommendation.
`contract`	Yes	Version of this answer's shape. "1" today; it only changes when an existing field changes meaning.
`currency`	Yes	ISO 4217 code every amount below is quoted in, e.g. "EUR".
`warnings`	Yes	Trip-level caveats: a country SimFuse does not sell, or a gap the recommended option leaves. Say these out loud rather than dropping them.
`planner_url`	Yes	The same trip on the SimFuse website, for a person who wants to finish it themselves.
`recommendation`	Yes	Which strategy won: one plan for the whole route, one plan per country, or a mix. Null when nothing we sell covers the trip.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral context: nothing is reserved or charged, prices are today's catalog rates rather than a held quote, and the returned package ids flow directly into create-checkout-session. It also discloses the side finding that uncovered countries are named.

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 question it answers, then capabilities, then usage guidance, then the read-only caveat. Efficient overall, though the middle sentence bundles several distinct outputs (cheapest option, data estimate, uncovered countries, package ids) into one long chain.

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 read-only planning tool with an output schema, the description covers the computation logic, the return payload shape, the read-only guarantee, and price freshness. Nothing an agent needs to decide whether or how to call it is missing.

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%, so the schema already documents every parameter including the usage enums, defaults, and country-code format. The description only restates 'the stops, a country code and the days spent in each' and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

Opens with the exact question the tool answers ('which eSIM should I buy for this trip?') and states the specific computation: comparing one whole-route plan vs per-country vs a mix on live prices. It clearly distinguishes itself from siblings like list-plans and get-plan, which return catalog data rather than a recommendation.

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 routing: 'Use it whenever a trip has two or more countries, and for a single country when the traveller wants a recommendation rather than a list.' That names both the trigger condition and the alternative (listing via list-plans), and it points to create-checkout-session as the downstream step.

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

All SimFuse eSIM Storefront 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?