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, Amazon Pay, Klarna or a local method such as iDEAL | Wero, Bancontact, BLIK or Pix; 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.

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": {
      "product_id": "<product_id>"
    },
    "name": "start_checkout"
  }
}

Input 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

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

Behavior5/5

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

Annotations only establish that this is a safe, idempotent, open-world read; the description adds substantial behavior the agent could not infer: payment methods supported, the explicit absence of a discount-code field, no account requirement, email delivery after payment, and the absence of in-chat order tracking. These negative-space disclosures directly prevent agent errors such as promising discount handling or offering to track an order.

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 core action is front-loaded in the first clause, and most sentences carry distinct information. The long enumerated payment-method list (Klarna, iDEAL | Wero, Bancontact, BLIK, Pix...) is heavier than an agent strictly needs and could be trimmed without losing routing value.

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?

With an output schema present and annotations covering the safety profile, the description fills the remaining gaps: it explains the returned buy_url, the currency/bucket quoting of name and price, and the post-payment fulfillment flow. Nothing an agent needs to call this correctly or set user expectations 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 100%, and the schema already documents the bucket/currency/language precedence (bucket wins, bare "en" maps to en-us/USD), so the description only restates that prices and names come back in the customer's bucket or currency. It adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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 — handing the customer off to the e-eSIM shop to buy exactly one plan — and names the primary output (buy_url). This is clearly distinguishable from the read-only siblings get_plan_details, search_esim_plans and recommend_plan, which the description never resembles.

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 scopes usage tightly ("to buy one plan") and sets expectations about what happens downstream — no account, emailed eSIM, no in-chat order tracking — so an agent knows when this is and isn't the right call. It stops short of naming which sibling to use instead (e.g. recommend_plan/search_esim_plans first), so it is clear context rather than explicit routing.

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?