Skip to main content
Glama

variotrip route eSIM configurator

Quote a route

quote_route
Read-onlyIdempotent

Use while the customer is still deciding — "how much is …?": the exact price of ONE eSIM for the whole route — the countries in any order (1–8) with their networks, ONE data pool in GB for all of them and the trip length — the server price the customer would pay. A single country is a route of one. Quote it as returned, never compute, add up or scale it yourself. The result carries a buy_url for reference; when the customer says they want to buy, call start_checkout.

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": {
      "route": "<route>",
      "days": "<days>"
    },
    "name": "quote_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
gbNoThe data pool for the WHOLE route in whole GB (1–100), shared by every country. Omit = sized for normal use (1.5 GB × days). Not sure? Call recommend_config.
daysYesTrip length in days (1–90) for the whole route, counted from the first connection anywhere on the route.
routeYesThe countries of the trip in any order (1–8, each once).
bucketNoOptional language-region bucket the customer shops in, e.g. en-gb, de-de (sets currency and link locale). Defaults from language.
currencyNoOptional ISO 4217 override for prices.
languageNoISO language of the conversation, e.g. en, de, ja. Localizes country names and sets the language/currency of links and prices.

Output Schema

NameRequiredDescriptionDefault
daysNoTrip length, counted from the first connection anywhere on the route.
noteNoPresent when something about the request had to be adjusted — read it to the customer.
priceNoFULL price of this route in currency — the amount paid. Not per day, per GB or per country.
routeNoThe countries on the eSIM in any order with the networks of each.
topupNoHow the customer adds data, days or a country later (not through the tools).
buy_urlNoThe route builder pre-set to exactly this route. Use verbatim.
data_gbNoONE data pool for every country on the route (whole GB), used wherever the customer is.
hotspotNo
currencyNo
countriesNo
price_basisNo
not_availableNoRequested countries variotrip cannot add (left out of the quote).
price_is_finalNo
activation_triggerNofirst_connection (anywhere on the route)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / route / description
      Previous value: -"The countries of the trip in travel order (1–8, each once)."New value: +"The countries of the trip in any order (1–8, each once)."
    • changedOutput schema / properties / route / description
      Previous value: -"The countries on the eSIM in travel order with the networks of each."New value: +"The countries on the eSIM in any order with the networks of each."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the readOnly/idempotent annotations, it discloses genuinely useful behavior: the price is a single pooled-GB price for the entire route rather than a per-country sum, and the returned value must be quoted verbatim rather than recomputed or scaled. It also mentions the returned buy_url. It stops short of describing error/failure behavior or what happens with invalid or unsupported routes.

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 usage cue is front-loaded and the remaining sentences each carry a distinct rule (pool semantics, quote-as-returned, checkout handoff). The opening sentence is long and slightly run-on with parenthetical dashes, which costs a little readability.

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 100% schema coverage, the description covers everything else an agent needs: when to call it, that the pricing is a single pooled product for the whole route, the prohibition on recomputing, and the next-step tool. Nothing material is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by stressing that route countries are in any order, capped at 1–8, each listed with its networks, and that gb is ONE pool shared by all countries and days is one length for the whole trip. That clarifies the pricing model the parameters express, not just their formats.

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: it returns the exact server price of ONE eSIM covering a whole multi-country route, with one shared data pool. That scope is clearly distinct from siblings price_grid (grid of prices), recommend_config (sizing advice) and start_checkout (purchase).

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?

Gives an explicit usage window ("while the customer is still deciding — how much is …?") and an explicit handoff rule: when the customer says they want to buy, call start_checkout. It also notes a single country is a valid route of one, removing a common ambiguity, and the schema routes unsure sizing to recommend_config.

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