geospatial-mcp

Overview Schema Source Related Servers Discussions Admin

route_directions

Read-onlyIdempotent

Get turn-by-turn driving, cycling, or walking directions along real roads, with distance, travel time, and route geometry. Plan delivery, service, or commute trips using OpenStreetMap data—no API key needed.

Instructions

Get driving, cycling or walking directions along real roads.

Returns distance, travel time and turn-by-turn instructions using OpenStreetMap road data via Valhalla -- no API key needed.

Use this for anything involving actual travel: delivery and field-service scheduling, ambulance response-time modelling, freight planning with vehicle restrictions, commute estimation, hiking and cycling routes.

For straight-line distance instead, use geom_measure -- it is much cheaper and needs no network. To find everywhere reachable within a time budget rather than the path to one place, use route_isochrone. For travel times between many places at once, use route_matrix rather than calling this repeatedly.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`via`	No	Optional intermediate stops, semicolon-separated, visited in the order given. Example: '48.87,2.33; 48.88,2.35'
`detail`	No	'summary' returns distance, duration and turn list. 'full' adds the route geometry as GeoJSON, which is much larger.	summary
`origin`	Yes	Start, as coordinates or a place name.
`profile`	No	Vehicle type. 'truck' respects weight, height, width and hazmat restrictions; 'walk' uses footpaths; 'bicycle' prefers cycleways.	car
`destination`	Yes	End, as coordinates or a place name.
`coordinate_format`	No	'grid' adds a USNG/MGRS grid reference to each turn. Useful for crews working from gridded paper maps -- search and rescue, wildland fire, surveying.	decimal

Output Schema

TableJSON Schema

Name	Required	Description	Default
`end`	Yes
`meta`	Yes
`start`	Yes
`steps`	No
`profile`	Yes
`provider`	Yes
`duration_s`	Yes
`distance_km`	Yes
`distance_miles`	Yes
`duration_display`	Yes
`geometry_geojson`	No
`geometry_polyline`	No
`profile_description`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description adds high-value behavioral context: no API key needed, OpenStreetMap data via Valhalla, return contents (distance, travel time, turn-by-turn instructions), and size implications of 'full' detail. It also discloses routing-behavior differences such as truck restrictions and walking/bicycle preferences. There is no contradiction with the readOnly/openWorld/idempotent annotations.

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 well-structured: what it does, what it returns, when to use it, and when to use alternatives. The sentence list of concrete use cases is specific and earns its place, and the alternative-routing guidance is front-loaded after the core purpose. Nothing feels redundant.

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?

Given six parameters and an output schema, the description covers the important contextual ground: data source, no-auth requirement, use cases, and clear routing to siblings. Because an output schema exists, the description does not need to enumerate return fields, and it still communicates the main outputs. This is complete for safe, correct invocation.

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 the baseline is 3 even without additional parameter detail. The main description adds broad use context and routing profile awareness, but it does not materially extend parameter semantics beyond what the schema already provides for origin/destination format, via ordering, detail levels, profile restrictions, and coordinate_format. It neither repeats nor compensates heavily, so the baseline is appropriate.

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: 'Get driving, cycling or walking directions along real roads.' It immediately distinguishes this tool from geometry-only tools by emphasizing 'real roads' and from isochrone/matrix tools by stating it returns the path to one place. No ambiguity about what the tool does.

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?

The description explicitly states when to use it: 'Use this for anything involving actual travel' with concrete examples. It also names three alternatives and the conditions that select them: geom_measure for straight-line distance, route_isochrone for reachable areas, and route_matrix for multiple origin/destination pairs at once. This is exactly the when-vs-alternatives guidance an agent needs.

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