MapMap

cheapest_fuel_along_route

Find the cheapest fuel along a route, with the REAL extra travel time of stopping at each station — never a straight-line guess. Provide origin + destination (a route is computed) or an existing route's geometry_polyline6, plus a fuel code ("diesel" default, "petrol_95", "petrol_98", "premium_diesel", "e85", "lpg") and max_detour_minutes (default 10). Stations come from the live open-data price feeds (UK CMA retailer scheme and/or the statutory Fuel Finder, FR prix-carburants, DE Tankerkoenig; the response's fuel_attribution names the ones actually matched), are priced through the routing engine with your costing (a truck profile makes detours respect dimensional/ADR restrictions) and ranked cheapest first. Each result carries price {value, currency, updated_at, stale} (stale = not verifiably fresher than 24 h), detour_minutes/detour_km, and saving_per_litre vs the cheapest on-route baseline (pass fill_litres to also get saving_total). Requires the MapMap gateway; answers a clear error when the deployment has no fuel-price dataset. Display the returned fuel_attribution with the prices.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fuel`	No	Which fuel to price: "diesel" (default), "petrol_95", "petrol_98", "premium_diesel", "e85" or "lpg" (aliases "petrol", "unleaded", "e10", "super_unleaded", "e5", "b7" and "sdv" are accepted).
`truck`	No	Truck profile (dimensions + ADR declaration). Requires costing "truck"; the detours then respect dimensional/ADR restrictions.
`origin`	No	Route origin (with `destination`, when no geometry is given).
`costing`	No	Costing model for the route and detour matrix: "auto" (default), "truck", "bicycle", "pedestrian" or "motor_scooter".	auto
`destination`	No	Route destination.
`fill_litres`	No	Optional fill size in litres; each result then also carries `saving_total` = `saving_per_litre` × `fill_litres`.
`max_results`	No	Maximum results (default 5, at most 25).
`geometry_polyline6`	No	An existing route geometry as an encoded polyline6 (the `route` tool's `geometry_polyline6`). Provide either this or `origin` + `destination`, not both.
`max_detour_minutes`	No	Largest acceptable detour in minutes (default 10, at most 120).

Output Schema

TableJSON Schema

Name	Required	Description
`fuel`	Yes	The normalised fuel code that was priced (e.g. "diesel").
`costing`	Yes	The costing the detours were priced with.
`results`	Yes	Stations within the detour budget, cheapest first (price, then detour).
`baseline`	Yes	The cheapest effectively-on-route option per currency (empty when no station sits on the route itself).
`candidate_cap`	Yes	The matrix fan-out cap in force.
`route_length_m`	Yes	Length of the route geometry in metres.
`fuel_attribution`	No	Attribution string for the fuel-price data sources actually returned — display it with the prices (a licence obligation).
`route_distance_m`	No	Direct origin→destination distance in metres.
`route_duration_s`	No	Direct origin→destination travel time in seconds (same estimator as the detour legs), when routable.
`candidates_costed`	Yes	Candidates actually priced through the engine (fan-out capped at `candidate_cap`, cheapest kept).
`max_detour_minutes`	Yes	The detour budget applied, minutes.
`candidates_considered`	Yes	Stations selling the fuel that passed the corridor pre-filter.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations at all, the description carries the full burden of behavioral disclosure, and it delivers: it names live open-data feeds, defines the stale flag as 'not verifiably fresher than 24 h', explains ranking by cheapest first, documents the error when no dataset exists, and states how truck costing affects detour restrictions. It also surfaces the 'never a straight-line guess' guarantee.

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?

The description is dense but well-organized: value proposition first, then route input, then data sources, then output fields and error behavior. Every sentence adds useful context, though it is somewhat long and partially echoes schema descriptions.

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 tool with 9 optional parameters and an output schema, the description covers the essential invocation modes, defaults, data provenance, result fields, error handling, and even an agent-facing display instruction. Minor omissions like max_results are already fully documented in the schema, so nothing critical 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 the baseline is 3, and the description adds extra meaning beyond the schema: it explains the mutual exclusivity of geometry_polyline6 vs origin+destination, that fill_litres produces saving_total, the effect of truck profiles on detours, and the default/alias behavior of fuel codes. Some repetition of schema text prevents a 5.

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 opens with a specific verb and resource: 'Find the cheapest fuel along a route', and immediately distinguishes itself from any generic routing or place-search tool by emphasizing real detour times rather than straight-line guesses. This clear scoping separates it from siblings like search_along_route and nearby_places without needing to open the 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?

It gives concrete invocation guidance: provide origin+destination, or geometry_polyline6, plus fuel code and max_detour_minutes, and states the MapMap gateway prerequisite. It does not explicitly name alternatives or provide when-not conditions, so it stops short of a 5, but the usage context is otherwise clear.

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

All MapMap tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools target a distinct action and resource pair, and descriptions are explicit about which tool fits which scenario. The closest overlaps—plan_ev_route vs cheapest_charging_along_route, and route vs plan_day vs order_stops vs optimise_routes—are mitigated by clear guidance, so an agent can usually pick correctly.

Naming Consistency4/5

Tool names overwhelmingly follow a verb_noun snake_case pattern (plan_ev_route, set_palette, list_style_layers) with a consistent geo_ prefix for geometry helpers. Minor deviations like elevation, route, and matrix are short and readable but break the strict verb_noun convention.

Tool Count2/5

At 39 tools, this surface is well past the 25+ threshold and feels heavy even for a broad mapping platform. The set spans routing, geocoding, places, styles, EV/fuel, telematics, usage, and feedback, which would be easier for an agent to navigate if split into smaller domain-focused servers.

Completeness4/5

For the stated breadth, coverage is strong: routing, multi-stop planning, VRP, EV/fuel detours, geocoding, places, geometry, style lifecycle, and telematics all have workable primary paths. Minor gaps like no style deletion, no route alternatives, and no batch geocoding are present but do not create dead ends for core workflows.

Resources

Need Help?