MapMap

search_along_route

Find places (POIs) along a route with the REAL extra travel time of stopping at each — never a straight-line guess. Provide origin + destination (a route is computed) or an existing route's geometry_polyline6, plus a free-text query ("coffee", "EV charger", "truck stop") and max_detour_minutes (default 10). For a category intent ("fuel", "EV charger", "coffee") pass category instead of relying on words alone: it takes the same vocabulary as nearby_places (lowercased OSM tag values such as "fuel", "cafe", "charging_station", "parking", "pharmacy"), and common colloquial phrases are normalised server-side ("petrol station" and "gas station" to fuel, "coffee" to cafe, "EV charger" to charging_station). query alone also promotes a pure category phrase to the same browse, so "fuel" finds fuel stations rather than places whose NAME starts "Ful"; anything else stays free-text name matching. When a browse ran, the response echoes the tokens used in matched_categories. Candidates near the route corridor are priced through the routing engine with your costing: detour = (origin→place) + (place→destination) − (origin→destination). Costing "auto", "truck" (with a truck profile the detours respect dimensional/ADR restrictions), "bicycle", "pedestrian" or "motor_scooter". Returns results sorted by detour with detour_minutes, detour_km, along_route_position (0-1) and off_route_m; at most 25 candidates are priced per call (candidate_cap).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	Free-text POI query, e.g. "coffee", "EV charger", "truck stop".
`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
`category`	No	Explicit place category ("fuel", "cafe", "charging_station" — same vocabulary as nearby_places). Colloquial phrases are normalised server-side; prefer this over query for category intents.
`destination`	No	Route destination.
`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
`query`	Yes	The query as interpreted.
`costing`	Yes	The costing the detours were priced with.
`results`	Yes	Places within the detour budget, cheapest detour first.
`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 fuel-price data sources, present only when at least one returned result carries `fuel_prices` (gateway-preferred mode with `SN_FUEL_PRICES` configured; see [`AlongRouteHit`]).
`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 is capped at `candidate_cap` nearest-to-route).
`matched_categories`	No	The normalised category tokens the candidates were browsed by, present only when a category browse actually ran (an explicit `category`, or a query the server promoted to one). Absent means free-text name matching answered the call, so a caller can tell how its words were understood rather than inferring it from the results.
`max_detour_minutes`	Yes	The detour budget applied, minutes.
`candidates_considered`	Yes	Candidates found near the corridor before pricing.

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure and does so thoroughly: it gives the exact detour formula, the candidate cap of 25, result fields, costing modes, truck ADR/dimensional restrictions, and server-side category normalization. It also explains how query alone can promote a category phrase to category browsing, making the tool's behavior predictable.

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?

The description is long but every clause earns its place, and the key differentiator is front-loaded: real detour time, never a straight-line guess. The content is organized around input modes, query/category behavior, detour computation, costing, and output, which makes even a dense description navigable.

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 9-parameter tool with no annotations and rich semantics, the description covers input alternatives, defaults, limits, category vocabulary, detour mathematics, costing behavior, and returned fields. Since an output schema is present, return-structure details are already covered structurally, and nothing necessary for invoking the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial semantic value beyond the schema: it clarifies the query/category distinction, the mutual exclusivity of geometry_polyline6 versus origin+destination, the default and maximum detour minutes, and how costing profiles influence detour computation. This materially improves an agent's ability to choose and format parameters correctly.

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 places (POIs) along a route' and immediately distinguishes the tool by emphasizing real detour time rather than a straight-line guess. It also signals how it relates to nearby_places through shared category vocabulary, making the tool's scope clear.

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?

The description explicitly covers two input modes (origin+destination vs geometry_polyline6) and gives detailed guidance on when to pass category versus query, including server-side normalization behavior. It does not explicitly state when to prefer this tool over sibling alternatives such as cheapest_fuel_along_route or nearby_places, so exclusions to alternatives remain implicit.

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?