roamflat Flat configurator

Quote one Flat

quote_flat

Read-onlyIdempotent

Use while the customer is still deciding — "how much is …?": the exact price of one configuration (country, speed, days and optionally which Flat / networks), the server price the customer would pay. Quote it as returned, never compute or scale it yourself. The result carries a buy_url for reference; when the customer says they want to buy, call start_checkout instead.

Input Schema

Name	Required	Description
`days`	Yes	Days of mobile data (1–30).
`flat`	No	Optional: which Flat of the country, as get_flats numbers them. Omit = the cheapest Flat that allows the speed.
`mbps`	No	Maximum speed in Mbps (5, 10, 25, 50; default 5). Data is unlimited at that speed. 25 Mbps and up need a 5G network.
`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.
`networks`	No	Optional: operator names from get_flats that must be included (the cheapest Flat holding all of them is used). Ignored when flat is given.
`destination`	Yes	Country in ANY language or its ISO code, e.g. "Japan", "Japon", "jp". Map a city to its country first. One country per Flat.

Output Schema

Name	Required	Description
`iso`	No	ISO 3166-1 alpha-2, lower case.
`data`	No
`days`	No	Days booked, counted from the first connection in the destination country.
`flat`	No	Which Flat of the country (1 = cheapest network only; higher numbers include more networks). Pass it back to quote the same Flat.
`name`	No	The Flat's name as the shop shows it: "Flat · Vodafone + O2" or "Flat · all 4 networks".
`note`	No	Present when something about the request had to be adjusted (a step up for the speed, an unknown network) — read it to the customer.
`price`	No	FULL price of this configuration in currency — the amount paid. Not per day.
`topup`	No	How the customer adds days to this Flat later (not through the tools).
`has_5g`	No	A 5G network is included.
`starts`	No
`buy_url`	No	The roamflat card preset to exactly this configuration. Use verbatim.
`hotspot`	No
`currency`	No
`networks`	No	Operator names included, as the shop states them.
`speed_mbps`	No	The chosen maximum speed. Data is unlimited at this speed.
`destination`	No	Resolved country name (localized).
`price_basis`	No
`all_networks`	No
`price_per_day`	No	For comparison only. Never multiply it yourself.
`price_is_final`	No
`networks_unmatched`	No	Present when a requested network does not exist in this country: those names. The quote then uses the Flat listed in networks.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 20, 2026

addedOutput schema / properties / networks_unmatched

Added value: +{
+  "description": "Present when a requested network does not exist in this country: those names. The quote then uses the Flat listed in networks.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "Present when something about the request had to be adjusted (a step up for the speed, an unknown network) — read it to the customer.",
+  "type": "string"
+}

addedOutput schema / properties / topup

Added value: +{
+  "additionalProperties": true,
+  "description": "How the customer adds days to this Flat later (not through the tools).",
+  "properties": {
+    "how": {
+      "type": "string"
+    },
+    "kind": {
+      "enum": [
+        "days"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

AddedOct 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare a safe, idempotent read. The description adds non-obvious behavior: the price must be quoted as returned and never computed or scaled, and the result carries a buy_url for reference. It stops short of saying anything about price validity/expiry or rate limits.

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 usage scenario before the mechanics, and the routing to start_checkout is placed last where it matters. Reasonably tight, though the quoted customer phrase and the parenthetical field list are slightly redundant with the schema.

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, return values need not be enumerated, yet the description still flags the buy_url. Combined with usage routing, price semantics and the no-computation rule, an agent has everything needed to call this correctly alongside its seven siblings.

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 description coverage is 100%, so every parameter including days, flat, mbps, networks and destination is already fully documented. The description only restates the field list ('country, speed, days and optionally which Flat / networks') without adding format or edge-case meaning. 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?

States a specific action on a specific resource: the exact price of one configuration. It distinguishes itself from price_grid (grid of many), recommend_config (recommendation) and start_checkout (purchase) by scoping to a single quote the customer pays.

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 the trigger ('Use while the customer is still deciding - how much is …?') and an explicit exclusion with the alternative to use instead ('when the customer says they want to buy, call start_checkout instead'). Nothing is left to inference.

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

All roamflat Flat 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?