Skip to main content
Glama
atlasfetch-dev

atlasfetch-mcp

Official

Route between coordinates, optionally avoiding your own zones

get_route
Read-only

Plan car, bike, foot, or truck routes between two or more points, with distance, duration, and turn-by-turn steps.

Instructions

A driving, cycling, walking or truck route from the first location to the last, via any in between, with distance, duration and turn-by-turn steps.

COST: a route is 10 LOOKUPS on the standard plans, not one (a custom plan may charge less; X-Lookups-Remaining is always the truth). Everything it returns is included in that, so do not call it in a loop to compare options without saying so.

Durations are FREE-FLOW: the road network at its own speed limits, with NO live or historical traffic. Never present one as an arrival time in traffic — for that, say a traffic-aware service (Google, Mapbox) is needed.

The route line is NOT returned unless routeGeometry is set, because an encoded polyline is thousands of characters that no one reads. Ask for it only when something will draw it.

Locations are SNAPPED to the nearest routable road, and locations[] in the response says how far each one moved. A large snapDistanceMeters means the answer starts somewhere else than asked — worth repeating to the user.

avoidSets and exposureSets name BOUNDARY SETS on the account (list_boundary_sets), not ad-hoc shapes. avoid routes around every zone in those sets; exposure leaves the route alone and reports how far it ran inside each zone. A zone containing one of the locations cannot be avoided for that route: it is skipped and reported in avoid.skipped.

TRUCKS (Pro only): a truck over 9 t, or with no weightTonnes, is capped at 80 km/h, as South African law caps goods vehicles; a lighter truck keeps car speeds. The vehicle’s height, width, length, weight, axle load and hazmat are checked against road limits where OpenStreetMap records them, which is not everywhere — a good start, not a legal clearance.

Limits by plan: 2 locations and 1 alternative on the free plans, up to 25 and 2 on Pro; alternatives need exactly 2 locations. Over a cap the answer is 403, and nothing is billed. A location with no road near it, or two places with no road between them, is 422 — and that one IS billed, because the route was attempted.

Not for: distance matrices, isochrones or live traffic (none exist yet), and not for which-area-is-this questions — that is lookup_location, at one lookup.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoTravel mode. Defaults to car. "truck" is Pro only; see TRUCKS above.
stepsNoTurn-by-turn steps per leg. Defaults to true here; set false for distance and time only.
vehicleNoTruck dimensions and load. Only with mode "truck"; rejected otherwise. Give weightTonnes: without it the truck is treated as heavy (over 9 t) and capped at 80 km/h.
geometryNoDEPRECATED: use routeGeometry, which takes the same values. Removed in 1.0.
languageNoLanguage for the step instructions, e.g. "en-GB", "de-DE", "fr-FR". Defaults to en-US.
avoidSetsNoNames of boundary sets on this account to route AROUND. Every zone in them is excluded.
locationsYesOrigin, any stops in order, then destination. 2 on the free plans, up to 25 on Pro.
alternativesNoAlso return up to this many other routes. Exactly 2 locations only. Plan-capped.
exposureSetsNoNames of boundary sets to MEASURE against: the route is unchanged, and the answer says how many metres of it ran inside each zone.
routeGeometryNoThe route line. Defaults to none. Ask for polyline6 or geojson only when something will draw it: it is long, and an assistant cannot read it usefully.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description carries far more: cost of 10 LOOKUPS per call, free-flow durations with no live/historical traffic, geometry withheld unless routeGeometry is set, snap behaviour and snapDistanceMeters reporting, avoid-vs-exposure semantics with avoid.skipped, truck speed capping, and plan limits. It also discloses billing rules per error code (403 unbilled, 422 billed), which no annotation covers.

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?

Long, but front-loaded with purpose then cost, and sectioned with labels (COST, TRUCKS, Limits by plan) so the reader can skim. Almost every sentence carries operative detail; the truck paragraph is extended but earns its place against the vehicle parameter.

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 10-parameter, nested-object, billing-sensitive tool with no output schema, the description still tells the agent what comes back (locations[] snap distances, avoid.skipped) and where the route line appears. Nothing needed to call it correctly or to set user expectations 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 baseline is 3, but the description adds meaning beyond the schema: avoidSets/exposureSets are account-level BOUNDARY SETS (pointing at list_boundary_sets) rather than ad-hoc shapes, and an unnamed weightTonnes makes a truck heavy and 80 km/h capped. These are operational distinctions the schema alone does not resolve.

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?

Opens with a specific verb+resource and scope: a route between the first and last location, via any in between, returning distance, duration and steps. It explicitly distinguishes itself from siblings by naming lookup_location as the tool for which-area-is-this questions, so an agent can route without reading other 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?

Gives explicit when-not rules ('Not for: distance matrices, isochrones or live traffic') and names the alternative (lookup_location). It also warns against the misuse pattern of looping to compare options, and states that alternatives require exactly 2 locations.

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