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 travel 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.

Input Schema

TableJSON Schema

Name	Required	Description
`gb`	No	The 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.
`days`	Yes	Trip length in days (1–90) for the whole route, counted from the first connection anywhere on the route.
`route`	Yes	The countries of the trip in travel order (1–8, each once).
`bucket`	No	Optional language-region bucket the customer shops in, e.g. en-gb, de-de (sets currency and link locale). Defaults from language.
`currency`	No	Optional ISO 4217 override for prices.
`language`	No	ISO language of the conversation, e.g. en, de, ja. Localizes country names and sets the language/currency of links and prices.

Output Schema

TableJSON Schema

Name	Required	Description
`days`	No	Trip length, counted from the first connection anywhere on the route.
`note`	No	Present when something about the request had to be adjusted — read it to the customer.
`price`	No	FULL price of this route in currency — the amount paid. Not per day, per GB or per country.
`route`	No	The countries on the eSIM in travel order with the networks of each.
`topup`	No	How the customer adds data, days or a country later (not through the tools).
`buy_url`	No	The route builder pre-set to exactly this route. Use verbatim.
`data_gb`	No	ONE data pool for every country on the route (whole GB), used wherever the customer is.
`hotspot`	No
`currency`	No
`countries`	No
`price_basis`	No
`not_available`	No	Requested countries variotrip cannot add (left out of the quote).
`price_is_final`	No
`activation_trigger`	No	first_connection (anywhere on the route)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, the description explains that this returns the server price the customer would pay, that the quote should be used as returned, and that the result carries a buy_url for reference rather than initiating purchase. This is meaningful behavioral context about pricing semantics and output usage. It does not contradict the annotations.

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 opens with the usage scenario, then defines the quote, then gives the critical 'never compute' instruction, then points to checkout. Every sentence earns its place, and the longer length is justified by the complexity of route quoting and the need to prevent wrong pricing behavior.

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 exists, the description need not explain return values, but it still usefully notes the buy_url. Combined with 100% schema description coverage and annotated safety hints, the definition gives an agent everything needed to call quote_route correctly and route the customer onward to checkout when appropriate.

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 useful conceptual meaning: the route is a sequence of 1–8 countries in travel order, a single country is a route of one, and the data pool is shared across the whole route. These details help an agent understand how the parameters combine beyond their individual schema descriptions.

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 specific verb and resource: quoting the exact price of ONE eSIM for a whole multi-country route. It defines the quote's scope precisely (countries in travel order, networks, one shared data pool, trip length) and distinguishes it from purchase flow by naming start_checkout. An agent can distinguish it from siblings such as price_grid or recommend_config without opening their schemas.

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 explicitly says when to use it: while the customer is still deciding and asks 'how much is …?'. It also states when to switch tools: when the customer wants to buy, call start_checkout, and the schema additionally points unsure agents to recommend_config. It gives a clear exclusion: do not compute, add up, or scale the quoted price yourself.

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

All variotrip route eSIM configurator 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?