Skip to main content
Glama

roamflat Flat configurator

Recommend a Flat

recommend_config
Read-onlyIdempotent

Use when the customer describes the trip instead of a speed: country (or up to 5), days and what will be connected (devices: phone, phone_laptop, small_group, family, creator_posting, creator_live, creator_hd_live, creator_pro). Picks the speed from the roamflat speed guide and returns it server-quoted together with the step below and the step above (where offered), each with price, networks, a one-line reason and its buy_url, plus trip totals and an optional budget check. A speed that needs 5G in a country without 5G falls back to the highest speed there and says so. Prices are the same as quote_flat. Give destination (one country) or destinations (several) — one of the two is required; a call without a country fails with invalid_argument.

Input Schema

NameRequiredDescriptionDefault
daysYesDays of mobile data (1–30).
flatNoOptional: which Flat of the country, as get_flats numbers them. Omit = the cheapest Flat that allows the speed.
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 trip in the quoted currency; options above it are marked.
devicesNophone = one phone (5 Mbps); phone_laptop = phone + laptop; small_group = a travel router for two or three devices; family = one travel router for the whole family; creator_posting = stories, reels, TikToks; creator_live = going live from the phone; creator_hd_live = Full HD live streams; creator_pro = multi-camera live and 4K uploads. Default phone.
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.
networksNoOptional: operator names from get_flats that must be included (the cheapest Flat holding all of them is used). Ignored when flat is given.
destinationNoCountry in ANY language or its ISO code, e.g. "Japan", "Japon", "jp". Map a city to its country first. One country per Flat. Required unless destinations is given.
per_countryNoOptional days per country for a multi-country trip.
destinationsNoSeveral countries (max 5), any language or ISO codes. Use instead of destination for a multi-country trip. Required unless destination is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / destination / description
      Previous value: -"Country in ANY language or its ISO code, e.g. \"Japan\", \"Japon\", \"jp\". Map a city to its country first. One country per Flat."New value: +"Country in ANY language or its ISO code, e.g. \"Japan\", \"Japon\", \"jp\". Map a city to its country first. One country per Flat. Required unless destinations is given."
    • changedInput schema / properties / destinations / description
      Previous value: -"Several countries (max 5), any language or ISO codes. Use instead of destination for a multi-country trip."New value: +"Several countries (max 5), any language or ISO codes. Use instead of destination for a multi-country trip. Required unless destination is given."
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive behavior beyond them: the 5G fallback rule and that it says so, the return shape (chosen speed plus the step below and above with reason and buy_url, trip totals, optional budget check), and budget marking. Slightly short of 5 only because handling of edge cases like per_country vs destinations interaction is left implicit.

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?

Front-loaded with the trigger and inputs, then the return shape and pricing note. Dense but each sentence carries information; the long second sentence bundles several facts but no filler.

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 an 11-parameter read-only recommendation tool with no output schema, the description covers inputs, selection logic, return payload, fallback behavior, and error conditions — enough for correct invocation and interpretation.

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 cross-parameter meaning: destination XOR destinations with max 5, budget marking options above it, and the driver for speed selection (days, devices, networks). It reinforces rather than merely repeats the schema.

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+resource (recommend a Flat/speed for a described trip) and immediately scopes it against the sibling case ('when the customer describes the trip instead of a speed'). It also clarifies its relationship to quote_flat ('Prices are the same as quote_flat'), so the agent can distinguish it without opening 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?

Explicitly names the trigger condition (trip described rather than a speed), the required input form (destination OR destinations, max 5), the failure mode of omitting both ('fails with invalid_argument'), and points to quote_flat for its pricing. When/when-not and the alternative are both present.

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