MapMap

cheapest_charging_along_route

Find the best EV charge points along a route, with the REAL extra travel time of stopping at each one — never a straight-line guess. Provide origin + destination (a route is computed) or an existing route's geometry_polyline6, plus optional connectors ("ccs", "type2", "chademo", "type1", "tesla", "domestic", "other"), min_kw (e.g. 50 for rapid only), available_only and max_detour_minutes (default 10). Charge points come from operator-published feeds, are costed through the routing engine with your costing (a truck profile makes detours respect dimensional/ADR restrictions) and ranked most powerful first, since minutes off the clock are bought with kilowatts. Each result carries max_power_kw, connector_standards, best_connector, evse_count, detour_minutes/detour_km and, where a live feed backs it, available_now. IMPORTANT: there is no national charge-point registry — every deployment covers only the operators it has onboarded, so ALWAYS show the returned coverage_note alongside the results. An empty results means "none from these operators within the detour budget", NEVER "there are no chargers here". Statuses are live only when availability_live is true; otherwise they are the values captured at the last ingest and must not be described as current. say is ALWAYS present and is the whole answer as one short spoken line, composed by the gateway with the coverage already inside the claim rather than appended to it: it scopes its superlative to the operators this deployment holds, and an empty result's line says the emptiness is about those operators. Prefer reading it verbatim to writing your own summary. Requires the MapMap gateway; answers a clear error when the deployment has no charge-point dataset. Display the returned charging_attribution with the results.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`truck`	No	Truck profile (dimensions + ADR declaration). Requires costing "truck"; the detours then respect dimensional/ADR restrictions.
`min_kw`	No	Keep only charge points whose best connector is rated at least this many kW (e.g. 50 for rapid charging only).
`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
`connectors`	No	Keep only charge points offering at least one of these connector standards: "type2", "type1", "ccs", "chademo", "tesla", "domestic" or "other". Omitted ⇒ every standard.
`destination`	No	Route destination.
`max_results`	No	Maximum results (default 5, at most 25).
`available_only`	No	Keep only charge points with a bay reported free right now. Needs the deployment to have a live availability feed; without one the call is refused rather than silently returning nothing.
`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
`say`	Yes	Always present. The whole answer as one short spoken line, composed by the gateway. Coverage is inside the claim rather than appended to it: the line scopes its superlative to the operators this deployment holds, and an empty result's line says the emptiness is about those operators, never about the road. Safe to read to a driver verbatim.
`note`	No	Why `results` is empty, when it is — the cause, not a bare list.
`costing`	Yes	The costing the detours were computed with.
`results`	Yes	Charge points within the detour budget, most powerful first (power, then detour).
`sources`	Yes	Every operator in the dataset, with its own coverage note and licence. Present even when `results` is empty.
`candidate_cap`	Yes	The matrix fan-out cap in force.
`coverage_note`	Yes	Always present. What this deployment's charge-point dataset does and does not cover. An empty `results` means "none from these operators within the budget" — never "there are no chargers here". Show this to the user alongside the results.
`route_length_m`	Yes	Length of the route geometry in metres.
`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.
`availability_live`	Yes	Whether statuses are live (a bring-your-own availability feed) or the values captured at the last ingest.
`availability_note`	Yes	Plain-language explanation of what the statuses mean here.
`candidates_costed`	Yes	Candidates actually costed through the engine (fan-out capped at `candidate_cap`, most powerful kept).
`max_detour_minutes`	Yes	The detour budget applied, minutes.
`charging_attribution`	No	Attribution string for the charge-point operators actually returned — display it with the results (a licence obligation).
`candidates_considered`	Yes	Charge points matching the filters that passed the corridor pre-filter.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 23, 2026

addedInput schema / $defs / LatLon / anyOf

Added value: +[
+  {
+    "properties": {
+      "lat": {
+        "description": "Latitude in decimal degrees (−90 to 90).",
+        "format": "double",
+        "type": "number"
+      },
+      "lon": {
+        "description": "Longitude in decimal degrees (−180 to 180).",
+        "format": "double",
+        "type": "number"
+      }
+    },
+    "required": [
+      "lat",
+      "lon"
+    ],
+    "type": "object"
+  },
+  {
+    "description": "GeoJSON position [lon, lat]: longitude FIRST.",
+    "items": {
+      "format": "double",
+      "type": "number"
+    },
+    "maxItems": 2,
+    "minItems": 2,
+    "type": "array"
+  }
+]

changedInput schema / $defs / LatLon / description

Previous value: -"A WGS84 coordinate pair in decimal degrees."New value: +"A WGS84 coordinate in decimal degrees: a {lat, lon} object (preferred), or a GeoJSON [lon, lat] array with LONGITUDE FIRST, the same order as every polygon field on this server."

removedInput schema / $defs / LatLon / properties

Removed value: -{
-  "lat": {
-    "description": "Latitude in decimal degrees (−90 to 90).",
-    "format": "double",
-    "type": "number"
-  },
-  "lon": {
-    "description": "Longitude in decimal degrees (−180 to 180).",
-    "format": "double",
-    "type": "number"
-  }
-}

removedInput schema / $defs / LatLon / required
```
Removed value: -[
-  "lat",
-  "lon"
-]
```
removedInput schema / $defs / LatLon / type
```
Removed value: -"object"
```

Changed2 schema fields changedSep 21, 2026

addedOutput schema / properties / say

Added value: +{
+  "description": "**Always present.** The whole answer as one short spoken line,\ncomposed by the gateway. Coverage is inside the claim rather than\nappended to it: the line scopes its superlative to the operators\nthis deployment holds, and an empty result's line says the\nemptiness is about those operators, never about the road. Safe to\nread to a driver verbatim.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "costing",
-  "route_length_m",
-  "candidates_considered",
-  "candidates_costed",
-  "candidate_cap",
-  "max_detour_minutes",
-  "results",
-  "coverage_note",
-  "sources",
-  "availability_live",
-  "availability_note"
-]New value: +[
+  "costing",
+  "route_length_m",
+  "candidates_considered",
+  "candidates_costed",
+  "candidate_cap",
+  "max_detour_minutes",
+  "results",
+  "coverage_note",
+  "sources",
+  "availability_live",
+  "availability_note",
+  "say"
+]

AddedSep 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: data comes from operator-published feeds, costing respects the selected profile (truck dimensions/ADR), results are ranked by power, empty results mean 'none from these operators' not 'no chargers', statuses are live only when availability_live is true, and the `say` field is the authoritative answer. It also covers error behavior for missing datasets and mandates displaying attribution. This is exemplary transparency beyond 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?

The description is long but every sentence carries operational significance. It front-loads the key differentiator (real detour time) and the coverage caveat early. It is dense but well-organized, avoiding fluff; the length is justified by the tool's complexity and edge cases.

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?

Despite having an output schema, the description explains the interpretation of results (coverage_note, empty results meaning, live vs ingested statuses, say field composition) and error handling. It covers all parameters and their interdependencies, making it complete for an agent to call correctly without additional context.

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 baseline is 3. The description adds meaning: it explains connectors list, gives a min_kw example, clarifies that available_only requires a live feed, and explains how truck costing affects detours. It also ties parameters to output semantics (e.g., detour_minutes/detour_km). This adds value beyond the schema without redundancy.

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 clearly states a specific verb ('Find') and resource ('EV charge points along a route') and highlights the distinctive real detour-time calculation versus straight-line guesses. It is clearly distinguished from siblings like cheapest_fuel_along_route (fuel vs EV) and search_along_route (generic search vs costed charging).

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?

Provides explicit input modes (origin+destination or geometry_polyline6, not both), conditions for available_only (requires live feed, otherwise refused), and the important caveat about operator coverage and the coverage_note. It does not explicitly name alternatives or when-not-to-use, but the context is clear and actionable.

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

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?