e-eSIM Catalog

Start secure checkout

start_checkout

Read-onlyIdempotent

Hand the customer to the e-eSIM shop to buy one plan. Returns buy_url (the product page where they tap Buy now and pay securely — card, Apple Pay, Google Pay, PayPal; there is no discount-code field) plus the plan name and price in the customer's bucket or currency. No account needed; the eSIM is emailed right after payment. There is no in-chat order tracking.

Input Schema

TableJSON Schema

Name	Required	Description
`bucket`	No	Optional language-region bucket the customer shops in, e.g. "en-gb", "de-de". Wins over language; prices and links are quoted in it.
`currency`	No	Optional ISO 4217 code. Every price in the result is quoted in it.
`language`	No	ISO language of the conversation, e.g. en, de, ja. Plan names and country names come back in it when available. Bare "en" is quoted in en-us / USD.
`product_id`	Yes	Product id to buy.

Output Schema

TableJSON Schema

Name	Required	Description
`price`	No	FULL fixed price of the plan.
`buy_url`	No	The exact product page to send the customer to. Use verbatim.
`message`	No
`product`	No
`currency`	No
`app_links`	No	Optional store links of the free e-eSIM app (android, ios) - the eSIM works without it.
`product_id`	No
`price_basis`	No
`presentation`	No
`price_is_final`	No
`pricing_bucket`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedSep 29, 2026

addedInput schema / properties / bucket

Added value: +{
+  "description": "Optional language-region bucket the customer shops in, e.g. \"en-gb\", \"de-de\". Wins over language; prices and links are quoted in it.",
+  "type": "string"
+}

addedInput schema / properties / currency

Added value: +{
+  "description": "Optional ISO 4217 code. Every price in the result is quoted in it.",
+  "type": "string"
+}

changedInput schema / properties / language / description

Previous value: -"ISO language of the conversation. Sets the language/currency of the payment page."New value: +"ISO language of the conversation, e.g. en, de, ja. Plan names and country names come back in it when available. Bare \"en\" is quoted in en-us / USD."

changedInput schema / properties / product_id / description

Previous value: -"WooCommerce product id to buy."New value: +"Product id to buy."

addedOutput schema / properties / app_links / additionalProperties
```
Added value: +true
```

changedOutput schema / properties / app_links / description

Previous value: -"Optional links to the free e-eSIM app (android/ios) for tracking data usage after setup. Mention only when present."New value: +"Optional store links of the free e-eSIM app (android, ios) - the eSIM works without it."

addedOutput schema / properties / presentation
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / price / description

Previous value: -"Full fixed price in currency; not per-day."New value: +"FULL fixed price of the plan."

addedOutput schema / properties / price_basis

Added value: +{
+  "enum": [
+    "total"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / price_is_final
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / pricing_bucket
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / product_id
```
Added value: +{
+  "type": "integer"
+}
```

First observedSep 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description is consistent with them since it only produces a URL rather than mutating anything. It adds genuinely useful behavior: no account required, eSIM emailed post-payment, accepted payment methods, and the notable absence of any discount-code field.

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?

Three sentences, purpose front-loaded, with delivery and payment details following. Dense but nearly every clause carries actionable information; only the payment-method enumeration is arguably expendable.

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?

An output schema exists, yet the description still tells the agent what the call yields (buy_url, plan name, price) and covers the customer-facing prerequisites and delivery path. Nothing needed to invoke it 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%, so all four parameters are already documented, including the bucket-wins-over-language precedence and currency quoting. The description reinforces the bucket/currency effect on returned prices but adds no syntax or format information beyond the schema, matching the baseline 3.

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: hand the customer to the e-eSIM shop to buy one plan. It also names the return artifact (buy_url) and what it contains, which separates it cleanly from search_esim_plans, recommend_plan, and get_plan_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the triggering context clear ('buy one plan', hands off to shop) and sets expectation boundaries ('no in-chat order tracking'), but it never names a sibling alternative or an explicit when-not-to-use condition, so routing is inferred rather than stated.

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

All e-eSIM Catalog 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?