Skip to main content
Glama

roamflat Flat configurator

Plan a multi-country trip

plan_trip
Read-onlyIdempotent

A trip through several countries (max 5): one Flat per country, each quoted at the same speed and days unless given per country. days is PER COUNTRY, never the whole trip: for a 12-day trip through Japan and Thailand pass per_country days that add up to 12 (e.g. 7 + 5). Returns one line per country with price and buy_url, plus the total. Use when the customer names two or more countries and a speed (2–5 destinations); for one country call quote_flat; use recommend_config when they describe devices or usage instead.

Input Schema

NameRequiredDescriptionDefault
daysNoDays in EACH country (1–30, default 7) — NOT the length of the whole trip. A 12-day trip through 3 countries is about 4 days per country: split the trip with per_country days that add up to the trip length.
mbpsNoMaximum speed in Mbps (5, 10, 25, 50; default 5). Data is unlimited at that speed. 25 Mbps and up need a 5G network.
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.
per_countryNoOptional overrides per country (days and/or mbps). Use it to split the trip: the days of all countries together should add up to the trip length.
destinationsYesCountries of the trip (2–5), any language or ISO codes, in travel order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / days / description
      Previous value: -"Days of mobile data (1–30)."New value: +"Days in EACH country (1–30, default 7) — NOT the length of the whole trip. A 12-day trip through 3 countries is about 4 days per country: split the trip with per_country days that add up to the trip length."
    • changedInput schema / properties / per_country / description
      Previous value: -"Optional overrides per country (days and/or mbps)."New value: +"Optional overrides per country (days and/or mbps). Use it to split the trip: the days of all countries together should add up to the trip length."
  2. Changed2 schema fields changed
    • changedInput schema / properties / destinations / description
      Previous value: -"Countries of the trip, any language or ISO codes, in travel order."New value: +"Countries of the trip (2–5), any language or ISO codes, in travel order."
    • addedInput schema / properties / destinations / minItems
      Added value: +2
  3. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds non-obvious behavior beyond that: the return shape ('one line per country with price and buy_url, plus the total'), the max-5 cap, and the critical rule that 'days is PER COUNTRY, never the whole trip' with a worked 7+5 example. Only pricing/auth edge cases are absent.

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?

Front-loaded with the trip scope and the max-5 constraint, then the per-country days rule and example, then the return shape, then routing to siblings. Dense but every clause carries decision-relevant information.

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?

For a 7-parameter tool with no output schema, the description covers inputs, defaults, return structure (per-country lines plus total), cardinality limits, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

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 3 is the floor. The description still adds value beyond the schema by stating the cross-parameter default rule ('each quoted at the same speed and days unless given per country') and reinforcing the per-country days split with the 12-day Japan/Thailand example, which clarifies how `days` and `per_country` interact.

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 ('a trip through several countries', one Flat per country, max 5) and explicitly differentiates from siblings: 'for one country call quote_flat; use recommend_config when they describe devices or usage instead.' An agent can pick this tool without opening any schema.

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 explicit when-to-use criteria ('customer names two or more countries and a speed, 2–5 destinations') and names both alternative tools with the conditions that select them. No exclusions are left to inference.

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