Skip to main content
Glama

Build an eSIM plan

build-plan
Read-onlyIdempotent

Build an eSIM plan to the traveller's liking for one destination: how much data, for how many days, optionally which network it runs on and whether calls and texts are bundled. Returns the one real plan that matches, with its id and live price, never a made-up combination: a shape nobody sells is snapped to the nearest one that is, one axis at a time, and every change is spelled out in adjustments so you can read it back. Use it when the traveller knows what they want ("10 GB on Docomo for two weeks"); use plan-trip when they want a recommendation or the trip has several countries. To buy, pass plan.id to get-checkout-link when a person is paying, or to create-checkout-session when you are. Read-only: it reserves nothing and charges nothing.

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": {
      "country_code": "<country_code>",
      "data_mb": "<data_mb>",
      "validity_days": "<validity_days>"
    },
    "name": "build-plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
voiceNoOptional. True to require a plan that bundles calls and texts. Defaults to false, data only. If no such plan exists the answer is data only and says so.
data_mbYesData allowance wanted, in megabytes: 1 GB is 1024 MB, so 5 GB is 5120. Pass 0 for an unlimited plan. Snapped to the nearest size sold when no plan has exactly this size.
networkNoOptional. The mobile network the plan should run on, by carrier name as `options.networks` lists them, e.g. "NTT Docomo" or "au". Matching is case-insensitive and a single carrier of a multi-network plan is enough. Omit for the cheapest network.
currencyNoOptional. ISO 4217 three-letter code the price is quoted in, e.g. "USD", "EUR", "GBP". Defaults to EUR. An unknown code falls back to EUR rather than failing.
country_codeYesISO 3166-1 alpha-2 code of the destination, e.g. "JP". Look it up with list-destinations rather than guessing.
validity_daysYesHow many days the plan should stay valid, 1 to 365. Snapped to the nearest length sold for the chosen size.

Output Schema

NameRequiredDescriptionDefault
planYesThe plan built: the same shape get-plan returns. Its `id` is what you buy with. Null when nothing was found.
builtYesThe specification of the plan actually built, after any adjustment. Null when nothing was found.
foundYesTrue when a plan was built. False when the destination sells nothing at all, in which case `plan` is null.
optionsYesWhat else could be asked for, so a follow-up question can be answered without another call.
requestedYesThe specification exactly as it was asked for.
adjustmentsYesEvery way the built plan differs from what was asked, one sentence each, written to be read to the traveller. Empty when the plan matches the request exactly.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description explains that unsold combinations are snapped to real sellable plans one axis at a time and every change appears in `adjustments`. It also clarifies that the tool reserves nothing and charges nothing, and that it returns one real plan with live price rather than a made-up combination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded: it states the purpose, then alternatives, then snapping behavior, then purchase routing and safety. Every sentence contributes to selecting or correctly invoking the tool.

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, the description does not need to detail return shape, but it still explains the key return behavior: a real matching plan with id and live price plus adjustments. Combined with the rich parameter schema and annotations, it is complete 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?

Schema description coverage is 100%, so the schema already documents every parameter thoroughly, including units, defaults, and fallback behavior. The description maps the parameters conceptually but adds little semantic detail beyond what the schema provides.

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 states a precise verb and resource: build an eSIM plan for one destination with data, validity, optional network, and voice bundle. It explicitly distinguishes the tool from plan-trip by saying plan-trip is for recommendations or multi-country trips.

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?

It gives clear when-to-use guidance: use this when the traveller knows what they want, otherwise use plan-trip. It also routes purchase behavior to get-checkout-link or create-checkout-session depending on who is paying.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources