varioroam eSIM configurator

Quote one configuration

quote_esim

Read-onlyIdempotent

Use while the customer is still deciding — "how much is …?": the exact price of one eSIM configuration (country, data GB 1–100, days 1–90, networks), the server price the customer would pay. Quote it as returned, never compute or scale it yourself. The result carries a buy_url for reference; when the customer says they want to buy, call start_checkout instead.

Input Schema

Name	Required	Description
`gb`	Yes	Data pool in whole GB for the whole trip (1–100). One pool, not per day. Not sure how much? Call recommend_config.
`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`	No	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`	No	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
`currency`	No
`networks`	No	Operator names included in this eSIM.
`destination`	No	Resolved country name (localized).
`price_basis`	No
`price_is_final`	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.

Changed11 schema fields changedOct 20, 2026

addedInput schema / properties / days / maximum
```
Added value: +90
```
addedInput schema / properties / days / minimum
```
Added value: +1
```

changedInput schema / properties / gb / description

Previous value: -"Data pool in GB for the whole trip (1–100, whole numbers)."New value: +"Data pool in whole GB for the whole trip (1–100). One pool, not per day. Not sure how much? Call recommend_config."

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.3/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, but the description adds real behavioral context: the price must be quoted verbatim ('never compute or scale it yourself') and the response carries a buy_url for reference only. It doesn't cover failure modes (unsupported destination, no matching config), so it falls just short of a 5.

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?

Two sentences, front-loaded with the usage trigger, then the behavioral constraint and the hand-off to start_checkout. Dense but every clause carries routing or behavior information; only mild crowding of three distinct instructions into one sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return-value detail is unnecessary, and the description already covers when to use it, how to treat the result, and the next tool in the workflow. It omits any note about invalid or unavailable configurations, which is the one gap for a pricing tool.

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 explains gb, days, destination, networks, bucket and language in detail. The description adds only a restatement of the GB/day ranges, not new syntax or defaults 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?

States a specific verb and resource ('the exact price of one eSIM configuration') with the key dimensions (country, GB 1–100, days 1–90, networks), which clearly separates it from price_grid (bulk grid) and recommend_config (sizing advice). An agent can route between quote_esim and its siblings without opening a 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?

Explicitly scopes timing ('Use while the customer is still deciding') and names the alternative plus the trigger that selects it ('when the customer says they want to buy, call start_checkout instead'). The schema also points to recommend_config for uncertain data amounts, so the when/when-not guidance is complete.

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?