Maps by DeltaBreen

directions

Read-only

A route between points in order ([lng, lat] each, 2 to 25: start, stops, end) by car, truck, bike or on foot, in the shape of Mapbox Directions v5: total distance in metres and time in seconds, each leg's main roads, turn-by-turn steps with written instructions, and the line as a polyline6. Times assume normal road speeds; there is no live traffic. Optional: alternative routes, roads to avoid (toll, motorway, ferry), the instructions' language, and each route's climb and descent. Covers Europe, North America (Canada, the US and Mexico), South America, Australia and Oceania; a point elsewhere answers no_route and counts nothing. Counts one lookup against the workspace's monthly searches, on every plan; past the plan it returns searches_exhausted and nothing is charged. Show the returned attribution with the route.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "points": "<points>"
    },
    "name": "directions"
  }
}

Input Schema

Name	Required	Description
`steps`	No	Turn-by-turn steps with written instructions (default true).
`key_id`	No	The map key (uuid from list_keys) to count the lookup against. Default: the workspace's first active secret key, else its first publishable one.
`points`	Yes	The stops in order, each [lng, lat]: the start, any stops between, the end (2 to 25 points).
`exclude`	No	Roads to leave out: any of toll, motorway, ferry.
`profile`	No	driving (the default), driving-hgv (a truck), cycling or walking.
`language`	No	The instructions' language, e.g. de or fr-FR; English where it is not available.
`elevation`	No	Each route's climb, descent, lowest and highest point, in metres.
`alternatives`	No	Up to two alternative routes after the best one (default false).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description goes well beyond the read-only annotation by disclosing key behavioral traits: no live traffic, regional coverage, the no_route behavior outside coverage, billing as one lookup against monthly searches, searches_exhausted past plan limits with no charge, and the attribution requirement. These are exactly the operational facts an agent needs before calling it.

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 dense but front-loaded, covering purpose, return shape, limitations, coverage, billing and attribution in one coherent paragraph. Every sentence carries useful information and nothing is wasted.

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 an eight-parameter routing tool with no output schema, the description is complete: it explains the return format, limitations, coverage, failure modes, billing behavior, and attribution. An agent can call it correctly without missing critical context.

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 schema already documents all eight parameters. The description adds helpful business context for points ordering and optional features, but it mostly restates what the schema already conveys, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: routing between ordered points by car, truck, bike or foot, and returns the route shape, distance, time, legs, steps and polyline. It is clearly different from distance_matrix and isochrone by capability, although it does not name a sibling alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the detailed output and coverage description, but the description gives no explicit when-to-use guidance or named alternatives for choosing this tool over distance_matrix, isochrone or elevation. It does provide useful constraints such as point limits, regional coverage, and no live traffic.

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

All Maps by DeltaBreen tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?