eSIM-Global.VIP eSIM Catalog

Recommend a plan for a trip

recommend_plan

Read-onlyIdempotent

Turn a trip into up to three plan recommendations: countries (1-5, any language), number of days and how much data the traveller uses. Each fit carries the full plan facts, the total price for the whole trip and a one-sentence reason built only from catalogue facts. Use this first whenever the user describes a trip rather than asks for a list.

Input Schema

TableJSON Schema

Name	Required	Description
`days`	Yes	Trip length in days.
`usage`	No	light ≈ 0.5 GB/day (maps, messaging), normal ≈ 1.5 GB/day (social, some video), heavy ≈ 4 GB/day (video, hotspot). Default normal.
`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.
`budget`	No	Optional maximum total for the trip, in the result currency.
`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.
`countries`	Yes	Countries or regions of the trip, any language.
`gb_per_day`	No	Overrides usage with an explicit daily need in GB.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`trip`	No
`message`	No
`currency`	No
`all_plans_url`	No
`pricing_bucket`	No
`recommendations`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 29, 2026

addedOutput schema / properties / recommendations / items / properties / plan / properties / last_updated

Added value: +{
+  "description": "Date the plan was last updated in the catalogue (YYYY-MM-DD).",
+  "type": "string"
+}

removedOutput schema / properties / recommendations / items / properties / plan / properties / last_verified

Removed value: -{
-  "description": "Date the plan facts were last synchronised from the supplier (YYYY-MM-DD), when known.",
-  "type": "string"
-}

AddedSep 29, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful behavioral detail: up to three recommendations, each carrying full plan facts, total price, and a one-sentence reason built only from catalogue facts. No contradiction with 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?

Three sentences, front-loaded with purpose and inputs, then output details, then usage. The middle sentence describing return content is somewhat redundant given an output schema exists, but overall the description is efficient and well-structured.

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 annotations covering safety, a comprehensive schema, and an output schema, the description needs only to state purpose, usage context, and high-level output shape. It does all three adequately; no critical information 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 100%, so the schema already documents all eight parameters with detail. The description restates the key inputs (countries 1-5, days, usage) but adds no syntax or meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (recommend) and resource (plan for a trip), and specifies the output (up to three recommendations). The phrase 'rather than asks for a list' implicitly distinguishes it from sibling search_esim_plans, though no sibling is named explicitly.

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?

Provides clear when-to-use guidance: 'Use this first whenever the user describes a trip rather than asks for a list.' This sets context and implies an exclusion (list requests), but does not explicitly name alternatives like search_esim_plans or get_plan_details.

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?