varioroam eSIM configurator

Start secure checkout

start_checkout

Read-onlyIdempotent

Use only once the customer has decided to buy ("I'll take it", "how do I buy?"): the checkout handoff. Returns the buy_url to give the customer, the final price and a ready-to-send checkout block (next_step, payment_methods, delivery) — on the page they press "Get it" and pay securely. No account needed; the eSIM is delivered on screen and by e-mail right after payment. No in-chat order tracking, no discount codes. For prices while the customer is still comparing, use quote_esim.

Input Schema

Name	Required	Description
`gb`	Yes	Data pool in whole GB (1–100).
`days`	Yes	Validity days (1–90).
`bucket`	No	Optional language-region bucket the customer shops in, e.g. en-gb, de-de (sets currency and link locale). Defaults from language.
`currency`	No
`language`	No	ISO language of the conversation, e.g. en, de, ja. Localizes country names and sets the language/currency of links and prices.
`networks`	No	Optional: operator names (or codes) from get_networks to include. Omit = the cheapest network of the country. The dearest included network sets the data price and every network beyond the first adds a small fee.
`destination`	Yes	Country in ANY language or its ISO code, e.g. "Japan", "Japon", "jp". Map a city to its country first. One country per eSIM.

Output Schema

Name	Required	Description
`iso`	No	ISO 3166-1 alpha-2, lower case.
`days`	No	Validity in days, counted from the first connection at the destination.
`note`	No	Present when something about the request had to be adjusted — read it to the customer.
`price`	Yes	FULL price of this configuration in currency — the amount paid. Not per day, not per GB.
`topup`	No	How the customer adds data or days to this eSIM later (not through the tools).
`buy_url`	Yes	Configurator pre-set to exactly this configuration. Use verbatim.
`data_gb`	No	Total data pool for the whole validity (whole GB). Not per day.
`hotspot`	No
`message`	No	A ready-to-send line for the customer.
`currency`	Yes
`delivery`	No	How and when the eSIM arrives.
`networks`	No	Operator names included in this eSIM.
`next_step`	Yes	What the customer does now: open buy_url, press "Get it", pay.
`destination`	No	Resolved country name (localized).
`price_basis`	No
`price_is_final`	No
`payment_methods`	No
`activation_trigger`	No
`networks_unmatched`	No	Present when a requested network does not exist in this country: those names. The quote then uses the networks listed in networks.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 20, 2026

changedInput schema / properties / gb / description

Previous value: -"Data pool in GB (1–100)."New value: +"Data pool in whole GB (1–100)."

addedInput schema / properties / gb / maximum
```
Added value: +100
```
addedInput schema / properties / gb / minimum
```
Added value: +1
```

changedInput schema / properties / gb / type

Previous value: -"number"New value: +"integer"

changedOutput schema / properties / data_gb / description

Previous value: -"Total data pool for the whole validity (GB). Not per day."New value: +"Total data pool for the whole validity (whole GB). Not per day."

changedOutput schema / properties / data_gb / type

Previous value: -"number"New value: +"integer"

addedOutput schema / properties / networks_unmatched

Added value: +{
+  "description": "Present when a requested network does not exist in this country: those names. The quote then uses the networks listed in networks.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "Present when something about the request had to be adjusted — read it to the customer.",
+  "type": "string"
+}

addedOutput schema / properties / topup

Added value: +{
+  "additionalProperties": true,
+  "description": "How the customer adds data or days to this eSIM later (not through the tools).",
+  "properties": {
+    "how": {
+      "type": "string"
+    },
+    "kind": {
+      "enum": [
+        "data_days"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 17, 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 behavior, but the description adds important context: no account needed, the eSIM is delivered on screen and by e-mail after payment, and unsupported capabilities are ruled out. This is rich behavioral disclosure beyond 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.

Conciseness4/5

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

The trigger condition is front-loaded in the first sentence, and each subsequent clause adds usable context. It is dense with parenthetical details, but appropriate for a tool whose use must be tightly constrained.

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?

The tool has an output schema, seven parameters, and high schema coverage; the description still covers when to use it, what it returns, what happens after payment, and the relevant alternative. Nothing critical for correct invocation 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 description coverage is 86%, so the schema already carries most parameter meaning. The description does not add parameter syntax, format, or pricing logic beyond what the schema provides, so it stays at the baseline for high-coverage schemas.

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 action and resource: the checkout handoff that returns buy_url, final price, and a checkout block. It explicitly distinguishes itself from quote_esim for price comparisons, so an agent can route to it without opening the sibling 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?

Gives explicit trigger phrases and the condition for use: only once the customer has decided to buy. It also names the alternative for the comparison stage and lists exclusions such as no in-chat order tracking and no discount codes.

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

All varioroam eSIM configurator 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?