bikerouter-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| plan_routeA | Plans a cycling route through the given waypoints with BRouter and returns distance, climb, estimated riding time, surface and way-type breakdown, turn instructions and a shareable bikerouter.de link. Waypoints may be coordinates or place names. Optionally saves the track as GPX/GeoJSON/KML. |
| compare_profilesA | Routes the same waypoints with several profiles (e.g. trekking vs gravel vs fastbike) and compares distance, riding time, climb and surface mix, so the best style of route can be picked. |
| geocode_placeA | Looks up coordinates for a place name, address or POI so it can be used as a routing waypoint. |
| list_profilesA | Lists the BRouter routing profiles (riding styles) known to this server, optionally checking which ones the routing host actually serves. |
| get_profile_optionsA | Fetches a profile's source and lists the parameters it exposes (avoid unsafe roads, allow ferries, rider mass and power, elevation weighting, ...). Pass them to plan_route via profile_options. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
The five tools are fairly distinct: plan_route is the core routing function, compare_profiles explicitly compares routing results across profiles, geocode_place converts names to coordinates, and list_profiles/get_profile_options are clearly about profile metadata. Minor confusion could arise between list and get_profile, but their scope is differentiated by listing and options-fetching.
All tool names follow a consistent verb_noun pattern in lowercase with underscores: plan/compare/geocode/list/get + route/profiles/place. Every verb is specific and every noun clearly reflects the resource. There is no mixing of naming styles or tense conventions.
The server provides exactly five tools for a domain that is naturally narrow: compose a route, compare routing outcomes, geocode a waypoint, inspect available profiles, and retrieve profile tuning details. This is a well-scoped set for a routing assistant without feature bloat.
The tool set covers the core lifecycle of bike route planning smoothly: geocoding inputs, planning a route, selecting and comparing routing styles. The main gap is the lack of a save/load route history or a user-specific profile creation tool, but these are optional conveniences, not critical. There are no major dead-ends in the existing workflow.