SimFuse eSIM Storefront

Create checkout session

create-checkout-session

Open a checkout session for one or more eSIM plans at frozen prices, using the plan ids that plan-trip, list-plans or get-plan returned. Use it once the traveller has chosen what to buy. It CHARGES NOTHING and reserves no stock: it prices the basket, freezes those prices until the session's price_locked_until, and hands back the session plus a bearer agent key. Payment, completion and cancellation happen afterwards over the SimFuse agentic HTTP API with that key, as the session's note explains, and the eSIM is delivered by email once payment settles. Each call opens a NEW session and mints a NEW key, so call it once per basket rather than retrying it to re-read one.

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": {
      "items": "<items>"
    },
    "name": "create-checkout-session"
  }
}

Input Schema

Name	Required	Description
`items`	Yes	What to buy: one entry per plan, 1 to 50 entries. Pass the whole basket in one call, e.g. [{"id":"01JVQ...","quantity":1}].
`currency`	No	Optional. ISO 4217 three-letter code to price the session in, e.g. "USD", "EUR", "GBP". Defaults to EUR. Every amount in the answer is minor units (cents) of this currency.
`agent_name`	No	Optional. Name of the assistant or app opening the session, e.g. "Claude". Recorded on the agent key so we can tell integrations apart. Defaults to "mcp-client".
`buyer_email`	No	Optional but strongly recommended. The traveller's email address, where the eSIM and its installation details are sent once payment settles. Ask for it rather than inventing one.

Output Schema

Name	Required	Description
`api`	Yes	The HTTP endpoints for this session, all taking the agent_key as a bearer token.
`note`	Yes	How to use the key and how long the prices hold. Worth following literally.
`session`	Yes	The priced checkout session, in the same shape the agentic HTTP API returns it.
`agent_key`	Yes	The bearer key for every follow-up call on this session, shown ONCE and never again. Send it as "Authorization: Bearer <key>". It is a credential: use it, do not read it out to the traveller.

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 flag non-read-only and non-idempotent, and the description adds substantial context beyond them: nothing is charged, no stock reserved, prices frozen until price_locked_until, a bearer agent key is minted, delivery is by email after payment settles, and critically that each call creates a NEW session and NEW key so it must not be retried to re-read one.

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?

A single dense paragraph, but front-loaded with the action and the critical 'charges nothing / reserves no stock' assurances before the downstream workflow. Nearly every sentence carries information, though a slightly tighter form would read better.

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?

Even though an output schema exists, the description correctly previews the return (session plus bearer key) and the post-call workflow, and covers the non-idempotent, no-charge semantics an agent needs to avoid duplicate sessions. Nothing material is missing for a 4-param, 1-required mutation.

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 description coverage is 100%, so the schema already documents items, currency, agent_name and buyer_email with ranges and defaults. The description's contribution is limited to the provenance of plan ids, which the schema also states; the baseline 3 applies when the schema does the heavy lifting.

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 (open a checkout session for eSIM plans) plus the key scope (frozen prices). It is clearly distinguishable from the sibling discovery tools (plan-trip, list-plans, get-plan), which it names as the source of its ids rather than as competitors.

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 an explicit trigger ('use it once the traveller has chosen what to buy') and explicit exclusions ('CHARGES NOTHING and reserves no stock'), plus a routing note that completion happens afterwards over the agentic HTTP API with the returned key. It also states up front that ids must come from plan-trip, list-plans or get-plan.

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?