eSIM Finder

get_plan_details

Read-only

Get the full details of a single eSIM plan by its SKU. Use this when the user wants to inspect or confirm one specific plan before checkout (e.g. "tell me more about the 5GB Italy plan", "what does Premium Unlimited mean for this plan?"), or when you need to re-display the details of a plan you found earlier in the conversation. Returns destination, data allowance, validity, price, plan benefits and speed characteristics in the same rich format as search_esims, but focused on one plan. CURRENCY HANDLING (IMPORTANT): pass the SAME currency used in this conversation's earlier search_esims call so the price shown here matches what the user will see at checkout. Defaults to USD. Does NOT generate a checkout URL — for that, follow up with create_checkout_url using the same SKU and currency. DESTINATION GUIDE: the result includes a destination_url (e.g. https://esimfinder.io/esim/japan) — include this link in your reply so the user can open the full destination guide. LANGUAGE (IMPORTANT): pass the language parameter set to the language YOU are replying in ("de" when you answer in German). destination_url then already points at the page in that language; use it exactly as returned.

Input Schema

TableJSON Schema

Name	Required	Description
`sku`	Yes	Plan SKU returned by search_esims (e.g. "2025h2_5GB_30D_IT_V2", "esimp_5GB_30D_AT_ULE_V2").
`currency`	No	ISO 4217 currency code (e.g. USD, EUR, GBP). Defaults to USD. MUST match the currency used in this conversation's search_esims call so price consistency is preserved.
`language`	No	The language YOU are replying in, as a short code ("de" for German, "en" for English, "es", "fr"). REQUIRED whenever you are answering in anything other than English: the server uses it to return destination_url for the page in that language. Derive it from the language of your own reply, never from the destination country.

Output Schema

TableJSON Schema

Name	Required	Description
`sku`	Yes
`data`	Yes	Data allowance label, e.g. "5 GB" or "Unlimited Essential".
`price`	Yes
`currency`	Yes
`plan_type`	Yes	Fixed data \| Unlimited Essential (ULE) \| Premium Unlimited (PUL) \| Unlimited.
`destination`	Yes
`validity_days`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

addedInput schema / properties / language

Added value: +{
+  "description": "The language YOU are replying in, as a short code (\"de\" for German, \"en\" for English, \"es\", \"fr\"). REQUIRED whenever you are answering in anything other than English: the server uses it to return destination_url for the page in that language. Derive it from the language of your own reply, never from the destination country.",
+  "type": "string"
+}

First observedSep 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The description adds context beyond readOnlyHint=true by explaining that it does NOT generate a checkout URL, which is a behavioral boundary. It also warns about currency consistency and language handling, which are critical for correct invocation. The annotations already indicate read-only, so the description complements them without contradiction.

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 description is somewhat long but packs necessary operational details (currency consistency, language handling, destination_url inclusion) in a structured way with clear sections like CURRENCY HANDLING and LANGUAGE. It front-loads the core purpose and then adds nuances, so it earns its length for a tool with these complexities.

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 presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers all critical usage aspects: when to use, parameters, currency consistency, language derivation, and how to use the destination_url. The tool's moderate complexity is fully addressed, and nothing essential is missing for correct invocation.

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?

The input schema already provides detailed descriptions for all parameters (sku, currency, language), including examples and usage notes. The description reinforces the currency and language semantics by repeating the importance, but it does not add significant new meaning beyond the schema's 100% coverage. Thus baseline 3 is 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?

The description clearly states it retrieves full details of a single eSIM plan by SKU, distinguishing it from search_esims which returns multiple plans. It also names the sibling tool create_checkout_url which it is not (no checkout URL generation), so an agent can differentiate it without ambiguity.

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 says use for inspecting/confirming a specific plan before checkout, or re-displaying details of a previously found plan. It also specifies not to use for checkout URL generation (use create_checkout_url instead) and when to use search_esims, providing clear when/when-not guidance.

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

All eSIM Finder 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?