Skip to main content
Glama
magiclane

Magic Lane MCP Server

Official
by magiclane

Route Planner

route_planner
Read-only

Calculate optimized routes for car, bicycle, pedestrian, or public transport between multiple locations. Supports multi-stop routing with automatic waypoint resolution and turn-by-turn instructions.

Instructions

Calculate optimized routes between two or more locations for car, bicycle, or pedestrian transport modes. Supports multi-stop routing with automatic waypoint resolution from place names or coordinates. Returns turn-by-turn instructions, distance, duration, and route geometry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
transportNoTransport mode used to compute the route. Exactly one of: "car" (passenger car, default; supports type="fastest"|"shortest"|"scenic"), "lorry" or "truck" (heavy goods vehicle — set the `vehicle` field with dimensions/weight; supports type="fastest"|"shortest"|"scenic"), "pedestrian" (walking; supports type="fastest"|"shortest"|"scenic"), "bike" (bicycle — use `fitness_factor` and `vehicle.profile`; supports type="fastest"|"shortest"; type="economic" REQUIRES an eBike `vehicle.profile` (pedelec/spedelec variant); type="scenic" is NOT supported), "public" (public transport: bus/train/tram; supports type="fastest"|"shortest").car
typeNoRoute optimization objective. Exactly one of: "fastest" (minimize travel time, default; valid for all transport modes). "shortest" (minimize distance; valid for all transport modes). "economic" (minimize energy use; VALID ONLY for e-bikes — requires transport="bike" AND `vehicle.profile` set to one of the eBike sub-profiles: "road_pedelec", "cross_pedelec", "city_pedelec", "mountain_pedelec" (or the "_spedelec" 45 km/h variants). Do NOT use for cars, trucks, regular bikes, or pedestrians). "scenic" (prefer scenic roads at the cost of travel time; valid for car, truck/lorry, and pedestrian. NOT valid for transport="bike" — bicycle routing has no scenic cost model. Use "fastest" for bikes and tune `fitness_factor`/`vehicle.profile` instead).fastest
originYesRoute start point. Provide `coordinates` (longitude, latitude) when known - preferred for accuracy. Otherwise provide `location` to resolve the start from a place name or address.
destinationYesRoute end point. Provide `coordinates` (longitude, latitude) when known - preferred for accuracy. Otherwise provide `location` to resolve the end from a place name or address.
avoidNoRoad features to exclude from the route. Array of zero or more of: "highway" (motorways), "toll" (toll roads), "ferry", "unpaved" (dirt/gravel), "turnaround" (U-turns), "traffic" (heavy-traffic segments), "roadblocks" (closures). Empty array (default) means avoid nothing. Adding entries may significantly increase travel time or fail to find a route.
detailsNoResponse verbosity. Exactly one of: "full": geometry + turn-by-turn instructions (default; use when guiding the user). "path": geometry only, no instructions (use for map rendering). "timedistance": only total time and distance (smallest response; use for ETAs).full
number_of_routesNoNumber of route alternatives to return, including the recommended primary route. Range: 1-3 for car/truck/bike/pedestrian; 1-11 for transport="public". Default 1. Use >1 only when the user explicitly wants alternatives.
fitness_factorNoEffort tolerance for bike and pedestrian routing, in [0.0, 1.0]. 0.0 = avoid steep climbs and long routes (low fitness); 1.0 = accept steep/hard terrain (high fitness). Default 0.5. Ignored for car/truck/public.
intermediate_waypointsNoOrdered list of stops between origin and destination, excluding origin and destination themselves. Order in the array defines visit order for fixed stops. Each entry has a `type` discriminator - see RoutingStopParametersSchema for the per-type rules ("coordinates", "address", "reference_poi", or "along_route_poi"). Default empty array (no intermediate stops).
emergencyNoEnable emergency-vehicle routing. When true, the engine relaxes certain traffic restrictions (e.g. one-way streets, restricted zones) that apply to emergency services. Default false. Set to true ONLY for ambulance/fire/police use cases.
localeNoISO 639-2 / ISO 639-3 language code for turn-by-turn instruction text (e.g. "en", "de", "fr", "es"). Default "en". Does not affect routing, only instruction language.en
vehicleNoVehicle profile used for restrictions and energy modelling. REQUIRED for transport="truck"/"lorry" (dimensions/weight to avoid restricted roads). REQUIRED for electric vehicles (set `vehicle.fuel="electric"` and `vehicle.ev` for charging-aware routing). OPTIONAL for car/bike/pedestrian - defaults apply if omitted.
Behavior4/5

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

The description adds behavioral details beyond annotations, such as returning turn-by-turn instructions and supporting multi-stop routing. It is consistent with readOnlyHint and openWorldHint, providing useful context without contradictions.

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?

Two sentences with no wasted words: first introduces core function, second adds key features. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description omits public and lorry/truck transport modes listed in the schema, and does not explain return format in absence of output schema. While it covers basic use cases, gaps reduce completeness for a complex tool.

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 description adds little parameter meaning beyond summarizing key capabilities (e.g., automatic waypoint resolution). Baseline score of 3 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 clearly states the tool calculates optimized routes between two or more locations for specific transport modes, and lists key outputs (turn-by-turn instructions, distance, duration, route geometry). It distinguishes from sibling tools like location_search and static_map_render by focusing on routing.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs. alternatives like round_trip or isochrone_calculator. Does not mention when not to use it or prerequisites.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/magiclane/magiclane-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server