eSIM-Global.VIP eSIM Catalog

Start secure checkout

start_checkout

Read-onlyIdempotent

Hand the customer to the eSIM-Global.VIP 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, with an optional discount code) 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
`days`	No	Unlimited Flex only: the duration the customer wants; the returned total_for_days is the checkout total for it.
`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
`days`	No
`price`	No	Read WITH price_basis.
`buy_url`	No	The exact product page to send the customer to. Use verbatim.
`message`	No
`product`	No
`currency`	No
`price_max`	No
`days_range`	No
`product_id`	No
`price_basis`	No
`presentation`	No
`price_is_final`	No
`pricing_bucket`	No
`total_for_days`	No	Unlimited Flex: checkout total for the requested days, discount applied.

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 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"
+}

addedInput schema / properties / days

Added value: +{
+  "description": "Unlimited Flex only: the duration the customer wants; the returned total_for_days is the checkout total for it.",
+  "minimum": 1,
+  "type": "integer"
+}

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 / days
```
Added value: +{
+  "type": "integer"
+}
```

removedOutput schema / properties / days_range / description

Removed value: -"Only on price_basis \"per_day\": choosable durations in days, e.g. \"1-30\"."

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

changedOutput schema / properties / price / description

Previous value: -"Price in currency, to be read WITH price_basis: the full fixed price when \"total\", the price of one day when \"per_day\"."New value: +"Read WITH price_basis."

removedOutput schema / properties / price_basis / description

Removed value: -"What `price` means for this product. See the plan schema."

addedOutput schema / properties / price_is_final
```
Added value: +{
+  "type": "boolean"
+}
```

removedOutput schema / properties / price_max / description

Removed value: -"Only on price_basis \"per_day\": price for the longest duration, discount applied."

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

addedOutput schema / properties / total_for_days

Added value: +{
+  "description": "Unlimited Flex: checkout total for the requested days, discount applied.",
+  "type": "number"
+}

Changed4 schema fields changedSep 22, 2026

addedOutput schema / properties / days_range

Added value: +{
+  "description": "Only on price_basis \"per_day\": choosable durations in days, e.g. \"1-30\".",
+  "type": "string"
+}

changedOutput schema / properties / price / description

Previous value: -"Full fixed price in currency; not per-day."New value: +"Price in currency, to be read WITH price_basis: the full fixed price when \"total\", the price of one day when \"per_day\"."

addedOutput schema / properties / price_basis

Added value: +{
+  "description": "What `price` means for this product. See the plan schema.",
+  "enum": [
+    "total",
+    "per_day"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / price_max

Added value: +{
+  "description": "Only on price_basis \"per_day\": price for the longest duration, discount applied.",
+  "type": "number"
+}

First observedSep 13, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent, and the description adds substantial context beyond them: it returns a buy_url, the accepted payment methods, that no account is needed, that the eSIM is emailed after payment, and that no in-chat tracking exists. This tells the agent exactly what the side-effect boundary is (a link handoff, not an in-chat 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?

Front-loaded with the action and outcome, then supporting details; the payment-methods aside and delivery note are relevant rather than filler. Slightly dense with parentheticals, but every sentence carries information.

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?

Given the output schema covers the return shape and annotations cover the safety profile, the description fills the remaining gaps an agent needs: external handoff behavior, payment options, account requirement, post-payment delivery, and the absence of in-chat tracking.

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 an output schema exists, so the baseline is 3. The description only loosely reinforces bucket/currency ('in the customer's bucket or currency') and adds no format or precedence detail beyond what the schema already states; the 'Unlimited Flex only' semantics for days live in the schema, not here.

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?

Specific verb+resource ('Hand the customer to the ... shop to buy one plan'), with an explicit scope limit ('one plan') and a named destination. It is clearly distinguishable from siblings like search_esim_plans, get_plan_details and recommend_plan, which do not hand off to checkout.

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

Usage Guidelines3/5

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

Usage is implied ('buy one plan') and a negative constraint is given ('There is no in-chat order tracking'), but there is no explicit when-to-use versus the sibling tools or a stated prerequisite (e.g. 'call after recommend_plan / with a product_id from search_esim_plans'). The agent must infer where this fits in the flow.

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

All eSIM-Global.VIP 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?