SimFuse eSIM Storefront

Build an eSIM plan

build-plan

Read-onlyIdempotent

Build an eSIM plan to the traveller's liking for one destination: how much data, for how many days, optionally which network it runs on and whether calls and texts are bundled. Returns the one real plan that matches, with its id and live price, never a made-up combination: a shape nobody sells is snapped to the nearest one that is, one axis at a time, and every change is spelled out in adjustments so you can read it back. Use it when the traveller knows what they want ("10 GB on Docomo for two weeks"); use plan-trip when they want a recommendation or the trip has several countries. To buy, pass plan.id to get-checkout-link when a person is paying, or to create-checkout-session when you are. Read-only: it reserves nothing and charges nothing.

Input Schema

TableJSON Schema

Name	Required	Description
`voice`	No	Optional. True to require a plan that bundles calls and texts. Defaults to false, data only. If no such plan exists the answer is data only and says so.
`data_mb`	Yes	Data allowance wanted, in megabytes: 1 GB is 1024 MB, so 5 GB is 5120. Pass 0 for an unlimited plan. Snapped to the nearest size sold when no plan has exactly this size.
`network`	No	Optional. The mobile network the plan should run on, by carrier name as `options.networks` lists them, e.g. "NTT Docomo" or "au". Matching is case-insensitive and a single carrier of a multi-network plan is enough. Omit for the cheapest network.
`currency`	No	Optional. ISO 4217 three-letter code the price is quoted in, e.g. "USD", "EUR", "GBP". Defaults to EUR. An unknown code falls back to EUR rather than failing.
`country_code`	Yes	ISO 3166-1 alpha-2 code of the destination, e.g. "JP". Look it up with list-destinations rather than guessing.
`validity_days`	Yes	How many days the plan should stay valid, 1 to 365. Snapped to the nearest length sold for the chosen size.

Output Schema

TableJSON Schema

Name	Required	Description
`plan`	Yes	The plan built: the same shape get-plan returns. Its `id` is what you buy with. Null when nothing was found.
`built`	Yes	The specification of the plan actually built, after any adjustment. Null when nothing was found.
`found`	Yes	True when a plan was built. False when the destination sells nothing at all, in which case `plan` is null.
`options`	Yes	What else could be asked for, so a follow-up question can be answered without another call.
`requested`	Yes	The specification exactly as it was asked for.
`adjustments`	Yes	Every way the built plan differs from what was asked, one sentence each, written to be read to the traveller. Empty when the plan matches the request exactly.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 20, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Discloses that it never returns made-up combinations, snaps unmatched shapes to nearest real plan one axis at a time, and records every change in adjustments. It also states read-only semantics (reserves nothing, charges nothing), complementing the annotations.

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

Conciseness5/5

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

Four dense sentences with no filler: main behavior first, then matching/transparency, then usage and purchase routing, then read-only caveat. Each sentence earns its place and the structure supports agent decision-making.

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?

Covers return value shape (id, live price, adjustments), when to use vs alternatives, purchase handoff, and side-effect-free behavior; output schema and 100% parameter schema coverage handle the rest. Nothing an agent needs to invoke correctly 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% and every parameter is already described with units, defaults, snapping, and matching rules. The description mostly restates these (data, days, optional network, calls/texts), adding no parameter meaning beyond what the schema provides, so the high-coverage baseline of 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?

States exactly what it does ('Build an eSIM plan... for one destination'), what it returns (the one real matching plan with id and live price), and explicitly distinguishes itself from plan-trip and purchase tools. An agent can tell this is a quote/selection tool, not a booking tool.

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?

Gives explicit when-to-use condition ('when the traveller knows what they want'), names the alternative for recommendations/multi-country (plan-trip), and specifies how to buy by passing plan.id to get-checkout-link or create-checkout-session. Also tells the agent to look up country with list-destinations rather than guessing.

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?