Skip to main content
Glama
Sign In

variotrip route eSIM configurator

by com.variotrip
OverviewDiscussionsAdmin

Recommend a route

recommend_config
Read-onlyIdempotent

Use when the customer describes a trip instead of a size: the countries (with the days in each, when known) and how they use data (usage light / normal / heavy, or gb_per_day). Sizes the shared pool from the trip length and returns three server-quoted routes — exact, comfortable (×1.5) and generous (×2) — each with the pool in GB, the full price, a one-line reason and its buy_url, plus an optional budget check. Same prices as quote_route.

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>"
    },
    "name": "recommend_config"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoTrip length in days (1–90). Give days, or days_in_country on the countries (then the trip length is their sum). With neither, the call fails with invalid_argument asking for days.
routeYesThe countries of the trip in any order (1–8, each once).
usageNolight ≈ 0.5 GB/day, normal ≈ 1.5 GB/day (default), heavy ≈ 4 GB/day.
bucketNoOptional language-region bucket the customer shops in, e.g. en-gb, de-de (sets currency and link locale). Defaults from language.
budgetNoOptional budget for the whole route in the quoted currency; options above it are marked.
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.
gb_per_dayNoOptional: the customer's own estimate in GB per day (wins over usage).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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)."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for what it adds: the three-tier quoting model with multipliers, the per-route payload (pool GB, full price, one-line reason, buy_url), budget marking, and price parity with quote_route. It does not cover failure modes such as missing trip length, but that is documented in the schema.

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?

Two sentences, front-loaded with the selection trigger, and the output contract is packed into the second sentence without filler. The dash-separated multiplier list is dense but readable; no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with no output schema, the description does the important extra work of describing the return shape (three routes with pool, price, reason, buy_url, optional budget flag). Minor gaps: no mention of how the result relates to start_checkout, and the budget-marking behavior is only loosely described.

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 coverage is 100%, so the schema already explains days, route, usage mapping, gb_per_day precedence, budget and currency. The description restates the trip-shape inputs (countries with days, usage light/normal/heavy or gb_per_day) without adding format, precedence, or edge-case detail beyond the schema — baseline 3 applies.

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 names a specific action (sizing a shared data pool from a trip description) and a concrete output (three server-quoted routes: exact, comfortable ×1.5, generous ×2). It explicitly distinguishes itself from quote_route by stating price parity, so an agent can tell the two apart without opening either schema.

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?

"Use when the customer describes a trip instead of a size" is an explicit trigger condition that contrasts with the size-based alternative. It never names the tool to use in the opposite case (presumably quote_route or price_grid), so the routing rule is only half-stated.

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 toolsInspect
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