Provides trail search and geocoding using OpenStreetMap data via Waymarked Trails and Nominatim, enabling finding routes by name, place, or bounding box, and retrieving route details, elevation, and geometry.
Resolves Wikipedia URLs for routes, providing direct access to their Wikipedia pages for additional information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@trails-mcp Find hiking trails near Zermatt"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A multi-service MCP server for outdoor / mapping data. Service 1 wraps the open Waymarked Trails API (recreational routes from OpenStreetMap) and adds OpenStreetMap Nominatim geocoding so trails can be found by place name. Service 2 adds Windy point forecasts for trail weather, marine, and air-quality planning.
Trail search is read-only and needs no API keys. Windy forecasts require a
Point Forecast API key (WINDY_API_KEY).
Search trails by name or reference code (GR20, E5, "Pennine Way")
Find trails near a place name in one step ("hiking trails near Zermatt")
Find trails inside a lon/lat bounding box
Get full route details: length, operator, description, website, Wikipedia, OSM tags, bbox, sub/super-routes, and (optionally) the full path geometry
Get a route's elevation profile
Get route geometry clipped to a map box (GeoJSON)
Resolve a route's Wikipedia link
Get a guidepost (signpost node)
Get a route's waymarking symbol (SVG shield)
Geocode any place name to coordinates
Get weather/marine/air-quality forecasts at any lat/lon (Windy Point Forecast API)
Browse all Windy models, parameters, and pressure levels with descriptions
All six Waymarked Trails flavours are supported via a flavour parameter on each tool:
hiking (default), cycling, mtb, riding, skating, slopes.
Coordinates: the upstream API speaks Web Mercator (EPSG:3857) internally. This server accepts and returns WGS84 lon/lat everywhere — the conversion is automatic. Route geometry is summarised by default (
geometry_detail: "summary") to keep responses small; pass"full"for every coordinate or"none"to omit geometry.
Related MCP server: Hiking MCP Server
Tool | Purpose |
| Health/last-update of a flavour |
| Fuzzy name/ref search |
| Geocode a place + return nearby routes (primary entrypoint) |
| Routes inside an explicit lon/lat box |
| Batch summary lookup by relation id |
| Full route detail (geometry trimmed by default) |
| Elevation profile |
| Route geometry clipped to a box (GeoJSON) |
| Wikipedia URL for a route |
| Guidepost node detail |
| Waymarking symbol SVG |
| Place name → coordinates (Nominatim) |
| Weather/marine/AQ forecast at lat/lon (Windy; requires API key) |
| Catalog of Windy models, parameters, levels (no API call) |
npm install
npm run build # compiles src/ -> dist/
npm test # unit tests for the geo/conversion helpersRequires Node >= 18.18 (developed on Node 22).
The same stdio command works everywhere; only the config file differs. Run npm run build
first — the config points at dist/index.js.
Either run:
claude mcp add trails -- node /Users/chiragahuja/Desktop/trails-mcp/dist/index.js…or add to ~/.claude.json (global) or a project .mcp.json:
{
"mcpServers": {
"trails": {
"command": "node",
"args": ["/Users/chiragahuja/Desktop/trails-mcp/dist/index.js"]
}
}
}Add to ~/.cursor/mcp.json (global) or <project>/.cursor/mcp.json (project-scoped):
{
"mcpServers": {
"trails": {
"command": "node",
"args": ["/Users/chiragahuja/Desktop/trails-mcp/dist/index.js"]
}
}
}Point the client at the TypeScript source via tsx instead of the built file:
{
"mcpServers": {
"trails": {
"command": "npx",
"args": ["tsx", "/Users/chiragahuja/Desktop/trails-mcp/src/index.ts"]
}
}
}Use the MCP Inspector:
npm run inspectOr, in a connected client, prompt:
Find hiking trails near Zermatt and show details of the longest one.
…which chains find_routes_near_place → get_route_details.
Copy .env.example to .env.dev and set your Windy Point Forecast key (create one at
api.windy.com). For local dev, npm run dev loads
.env.dev automatically. For MCP clients, pass env vars in the server config:
{
"mcpServers": {
"trails": {
"command": "node",
"args": ["/path/to/trails-mcp/dist/index.js"],
"env": { "WINDY_API_KEY": "your_point_forecast_key" }
}
}
}Variable | Default | Purpose |
| (unset) | Windy Point Forecast API key (Map/Webcam keys do not work) |
|
|
|
|
| User-Agent sent to upstream APIs (Nominatim requires a descriptive one) |
src/
core/ registry, tool type, http, errors, rate limiter, logger, result helpers
geo/ Mercator <-> lon/lat conversion, bbox helpers, geometry trimming
services/
index.ts registerAllServices() — the single place new services plug in
geocoding/ Nominatim client + geocode_place (shared, rate-limited)
waymarked/ Waymarked Trails client, response shapers, and one file per tool
windy/ Windy Point Forecast client, parameter catalog, forecast shapingAdding another service = create src/services/<name>/ with a register() function and add
one call in src/services/index.ts. No existing tool files change. Tool names are namespaced
to avoid collisions, and the registry rejects duplicates.
Trail data: © OpenStreetMap contributors, served by Waymarked Trails (Sarah Hoffmann), ODbL.
Geocoding: OpenStreetMap Nominatim — used within its usage policy (max 1 request/sec, descriptive User-Agent), enforced in-process.
Please be considerate with request volume; these are free community services.
MIT (this wrapper). Upstream data/services keep their own licenses.
Find recreational routes that pass through an explicit WGS84 lon/lat bounding box. Use this when you already have coordinates (e.g. from geocode_place or a map viewport). For a place name, use find_routes_near_place instead.
| Name | Required | Description | Default |
|---|---|---|---|
| min_lon | Yes | Western longitude. | |
| min_lat | Yes | Southern latitude. | |
| max_lon | Yes | Eastern longitude. | |
| max_lat | Yes | Northern latitude. | |
| limit | No | Max routes to return (1-100). | |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
| language | No | Preferred language for names (BCP-47 code, e.g. 'en', 'de', 'fr'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not mention behavioral traits like rate limits, authentication, or specific query behavior (e.g., routes partially crossing are included). Adequate but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and usage guidance. Slightly more description of parameters could be added, but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description covers essential usage context. Missing return format details, but it's sufficient for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with inline parameter descriptions. The description adds no additional meaning beyond what the schema already provides, earning baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds recreational routes within a WGS84 bounding box, using specific verb and resource. It distinguishes from sibling tool find_routes_near_place by emphasizing coordinate-based input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when coordinates are available) and when not (for place names, use find_routes_near_place), providing clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find recreational routes near a named place in one step: geocodes the place with OpenStreetMap, then returns routes whose path passes through a bounding box around it. This is the primary way to answer 'what trails are near '. Returns summary route entries; follow up with get_route_details for any id.
| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | Place name to search around, e.g. 'Zermatt', 'Snowdonia'. | |
| radius_km | No | Half-size of the search box around the place, in km (0.5-100). | |
| limit | No | Max routes to return (1-100). | |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
| language | No | Preferred language for names (BCP-47 code, e.g. 'en', 'de', 'fr'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fully discloses the two-step operation (geocode via OpenStreetMap, then bbox search), the return type (summary entries), and suggests a follow-up tool. This is excellent transparency for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences that front-load the purpose and key behavior. Every sentence adds value without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no output schema, the description covers the essential context: the geocoding step, bounding box approach, return type, and follow-up tool. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no parameter-specific details beyond the schema, but the overall process explanation provides context that enriches understanding of how parameters like place and radius_km are used. It does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds recreational routes near a named place by geocoding and bounding box search. It positions itself as 'the primary way' to answer that question, distinguishing it from siblings like find_routes_in_bbox (raw bbox search) and geocode_place (separate geocoding step).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is the primary way to answer what trails are near <place>', giving clear when-to-use guidance. It doesn't explicitly list when-not-to-use or alternatives, but the context implies that for coordinate-based searches, find_routes_in_bbox would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a place name (city, region, landmark, mountain pass, etc.) into geographic coordinates using OpenStreetMap's Nominatim geocoder. Returns candidate matches with lat/lon and a bounding box. Use this when you have a place name and need coordinates — for example before calling find_routes_in_bbox. To find trails near a place in one step, prefer find_routes_near_place instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Place name to look up, e.g. 'Zermatt', 'Lake District', 'Stok La'. | |
| limit | No | Maximum number of candidate matches to return (1-10). | |
| language | No | Preferred language for place names (BCP-47 code, e.g. 'en', 'de'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it uses Nominatim, returns candidate matches with lat/lon and bounding box. Does not mention rate limits, delays, or error handling, but overall adequately describes behavior for a geocoding tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; first sentence defines purpose and process, second provides usage guidance and alternative. Front-loaded and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description covers purpose, usage, and output format. Lacks error handling details or external service dependencies, but is sufficiently complete for a typical geocoding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context for the query parameter by listing examples of place types, which enriches the schema meaning. Does not add beyond schema for limit or language, but the additional context warrants a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting a place name into geographic coordinates using Nominatim. It specifies types of places (city, region, landmark, mountain pass) and distinguishes itself from sibling tools, particularly find_routes_near_place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the tool ('when you have a place name and need coordinates') and provides a before-use scenario ('before calling find_routes_in_bbox'). Also gives an alternative recommendation for a one-step operation ('prefer find_routes_near_place instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a guidepost (waymarking signpost node) by its OSM node id: name, elevation, lon/lat position, and OSM tags. Guidepost ids come from map tiles or other tools, not from route searches.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | OSM node id of the guidepost. | |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
| language | No | Preferred language for names (BCP-47 code, e.g. 'en', 'de', 'fr'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states what data is returned (name, elevation, position, tags) but does not disclose whether the operation is read-only, any prerequisites, rate limits, or how the response is structured. It adequately describes a simple data retrieval tool but lacks depth typical of higher scores.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. It front-loads the purpose and key fields, followed by a single clarifier about id sourcing. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (1 required) and no output schema, the description is fairly complete. It covers what the tool returns, how to get the id, and the meaning of flavour/language defaults. It leaves some ambiguity about return format but is sufficient for straightforward use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds that guidepost ids are from map tiles/other tools (not schema) but otherwise does not enhance parameter meaning beyond the schema. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves guidepost details by OSM node id, listing the specific fields returned (name, elevation, position, tags). It distinguishes itself by noting that guidepost ids come from map tiles or other tools, not route searches, which differentiates it from siblings like get_route_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on where to obtain the guidepost id (from map tiles or other tools, not route searches). This helps the agent understand the source of valid inputs. It does not explicitly exclude contexts, but the intended use is clear given the sibling tools (routes, geocoding, forecasts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch machine-readable weather, marine, or air-quality forecast data for a lat/lon point from the Windy Point Forecast API (https://api.windy.com/point-forecast). Requires WINDY_API_KEY. Returns shaped timesteps with decoded wind direction, precipitation type, and WMO weather codes plus a parameterGuide explaining each requested variable. Pick a regional model when available (iconEu for Europe, hrrrConus for US, arome for France). Use list_forecast_options to browse all models, parameters, and pressure levels.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in WGS84 decimal degrees (-90 to 90). Rounded to 2 decimals by the API (~1 km). | |
| lon | Yes | Longitude in WGS84 decimal degrees (-180 to 180). Rounded to 2 decimals by the API (~1 km). | |
| model | No | Numerical weather/sea/air-quality model. Pick a regional model when available for better terrain resolution. Weather models: gfs (global default), icon, iconD2 (DE/AT/CH), iconEu, arome*, nam*, hrrr*, canHrdps. Sea: gfsWave, iconWave, iconEuWave, canRdwpsWave, cmems. Air quality: cams (global), camsEu (Europe + pollen). Details: gfs: Global (NOAA GFS, ~13 km). Default worldwide fallback. — Any location globally when no regional high-res model applies. Good baseline for multi-day trail planning. | icon: Global (DWD ICON-Global). — Global coverage with a European model; alternative to GFS worldwide. | iconD2: Germany, Austria, Switzerland — high resolution (~2 km). — Alpine trails in DE/AT/CH where terrain detail matters. | iconEu: Europe and surrounding areas (~7 km). — European hiking/cycling; better than GFS for the Alps, Pyrenees, etc. | arome: France and surrounding areas (Météo-France AROME). — French trails including Alps, Massif Central, Pyrenees fringes. | aromeAntilles: French Antilles (Caribbean). — Guadeloupe, Martinique, and nearby islands. | aromeFrance: Metropolitan France only. — Mainland France trails when you want the France-specific AROME run. | aromeReunion: Réunion island (Indian Ocean). — Piton des Neiges, cirques, and Réunion hiking. | namConus: Continental USA and surrounding areas (NAM). — US lower-48 trail forecasts (Appalachian, Rockies, etc.). | namHawaii: Hawaii. — Hawaiian island trails and volcanoes. | namAlaska: Alaska and surrounding areas. — Alaskan wilderness and mountain routes. | hrrrConus: Continental USA — high resolution (~3 km, short-range). — Same-day / next-day US trail weather where convection and terrain matter. | hrrrAlaska: Alaska — high resolution short-range. — Detailed short-range forecasts for Alaskan trails. | canHrdps: Canada — high resolution (HRDPS). — Canadian Rockies, Coast Mountains, and other CA trail areas. | gfsWave: Global ocean waves (excludes Hudson Bay partly, Black Sea, Caspian, most Arctic). — Coastal hikes, beach trails, kayak/ferry crossings on open ocean. | iconWave: Global wave model (DWD ICON-GWAM). — Global marine conditions; alternative wave model to gfsWave. | iconEuWave: European seas (ICON-EWAM). — Mediterranean, Atlantic fringe, North Sea coastal trails. | canRdwpsWave: Canadian waters. — Pacific/Atlantic/Arctic coastal routes in Canada. | cmems: Global ocean currents (Copernicus Marine Service). — Coastal current safety for swimming, paddling, or tidal flat crossings. | cams: Global air quality (Copernicus CAMS). — Smoke, dust, or pollution affecting trail air quality worldwide. | camsEu: Europe — includes pollen (CAMS regional). — European trails during hay-fever season or smog events. | gfs |
| parameters | No | One or more forecast parameters. Default bundle covers typical trail planning: temp, wind, windGust, precip, rh, pressure, ptype, lclouds. | |
| levels | No | Pressure/geopotential levels for level-aware params (temp, dewpoint, wind, rh, gh). Other params always use surface. Default ['surface']. Levels: surface: Surface level (default). Best for trailhead conditions: ground temperature, surface wind, and precipitation at the coordinate. | 1000h: 1000 hPa (~sea level). Useful for coastal/lowland forecasts when surface orography differs from the model grid cell. | 950h: 950 hPa (~500 m). Lower foothills and valley inversions. | 925h: 925 hPa (~800 m). Mid-elevation valleys and lower mountain slopes. | 900h: 900 hPa (~1 km). Lower mountain ridges and high valleys. | 850h: 850 hPa (~1.5 km). Standard level for free-atmosphere temperature/wind; often used for mountain-pass and sub-alpine conditions. | 800h: 800 hPa (~2 km). High ridges and lower alpine terrain. | 700h: 700 hPa (~3 km). High alpine / treeline elevation band. | 600h: 600 hPa (~4.2 km). Upper alpine and lower glaciated terrain. | 500h: 500 hPa (~5.6 km). High peaks and upper-atmosphere weather systems. | 400h: 400 hPa (~7.2 km). Very high summits; jet-stream proximity. | 300h: 300 hPa (~9.1 km). Jet-stream level; strong winds aloft. | 200h: 200 hPa (~11.8 km). Upper troposphere. | 150h: 150 hPa (~13.5 km). Near tropopause. | |
| max_steps | No | Optional cap on returned forecast timesteps (from the start). Omit for the full model run. Use to keep responses small (e.g. 24 for ~3 days of 3-hourly data). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It explains that the tool 'Returns shaped timesteps with decoded wind direction, precipitation type, and WMO weather codes plus a parameterGuide' and mentions lat/lon rounding. It could be more transparent about error handling or rate limits, but overall it provides good insight into behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a recommendation) and front-loaded with purpose and authentication. It could be more structured, but it avoids unnecessary verbosity and is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and no output schema, the description covers core purpose, authentication, model choice guidance, and return format. It lacks details on pagination or large response handling, but overall it is fairly complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3. The description adds little beyond the schema for parameters, as the schema already contains extremely detailed descriptions for model and parameters. However, the tool description does list a default parameter set, providing some added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly specify 'Fetch machine-readable weather, marine, or air-quality forecast data for a lat/lon point from the Windy Point Forecast API.' The verb 'Fetch' and resource 'forecast data' are specific, and it distinguishes from siblings like list_forecast_options (which browses options) and route-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the requirement for WINDY_API_KEY and advises to 'Pick a regional model when available' while referencing list_forecast_options to browse all models. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full information about a single route by its OSM relation id: name, reference, network, total length, operator, description, website, Wikipedia, bounding box (lon/lat), raw OSM tags, and any sub-/super-routes. Geometry is summarised by default to keep the response small — set geometry_detail to 'full' for every coordinate or 'none' to omit it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | OSM relation id of the route. | |
| geometry_detail | No | How much path geometry to include: 'none' (counts only), 'summary' (~30 lon/lat points, default), or 'full' (every coordinate). | summary |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
| language | No | Preferred language for names (BCP-47 code, e.g. 'en', 'de', 'fr'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full burden. It discloses that geometry is summarized by default and explains options. It lists all returned fields, but does not mention error handling, rate limits, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence front-loads the core purpose and outputs; the second clarifies geometry behavior. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main functionality with 4 parameters and full schema. Mentions key outputs but omits error scenarios and response size. For a single-route detail tool, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description adds value by explaining the implications of geometry_detail levels and the purpose of flavour and language parameters, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full information about a single route by its OSM relation id.' It lists specific fields returned (name, reference, etc.), distinguishing it from sibling tools that handle multiple routes or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details of a specific route by ID. It provides guidance on geometry options but lacks explicit when-not-to-use or alternatives like searching by name first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the elevation profile of a route by its OSM relation id: minimum/maximum elevation and elevation points (lon, lat, ele in metres, pos along the way) per segment. Note: elevation data is only available on some flavours/servers; if unavailable a not_found result is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | OSM relation id of the route. | |
| simplify | No | Optional simplification: maximum segment length in metres. 0 = no simplification. | |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
| language | No | Preferred language for names (BCP-47 code, e.g. 'en', 'de', 'fr'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral info. It discloses that elevation data may be unavailable and returns a not_found result. It does not cover authentication, rate limits, or performance expectations, but the information provided is adequate for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly stating the purpose and a key caveat. No superfluous information, perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return value structure (min/max elevation, elevation points with lon, lat, ele, pos). It could clarify point ordering or coordinate system, but overall provides sufficient context for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description adds only the context of 'by OSM relation id' which is redundant. It provides output details but does not enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the elevation profile of a route using an OSM relation id, specifying the output includes min/max elevation and elevation points. This is distinct from sibling tools which focus on route finding, details, segments, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (when elevation data is needed for a route by OSM id) and mentions a limitation (availability on some servers). However, it does not explicitly state when not to use or compare with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch summary entries for multiple routes at once by their OSM relation ids. Returns the same compact shape as the search tools. For full detail on a single route use get_route_details.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | OSM relation ids to look up (1-50). | |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
| language | No | Preferred language for names (BCP-47 code, e.g. 'en', 'de', 'fr'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Fetch') and mentions the output shape, but does not disclose potential behaviors like auth requirements, rate limits, or error conditions. The description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a clear purpose: first defines the core action, second adds context and distinguishes from a sibling. No unnecessary words, and it is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description references 'same compact shape as the search tools' which is helpful but vague. While it provides enough context for an agent familiar with the domain, it could be more self-contained by briefly describing the return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters well. The description does not add additional meaning beyond what the schema provides, staying at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'summary entries for multiple routes', and the method 'by OSM relation ids'. It also distinguishes from sibling tools by mentioning the return shape and directing to get_route_details for full detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (when you have multiple IDs and need summaries) and explicitly says when not to use (for full detail on a single route, use get_route_details). It could be more specific about alternatives like search tools, but it mentions the output shape matches search tools, implying they can also be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the on-map geometry of one or more routes, clipped to a WGS84 lon/lat bounding box, as GeoJSON (reprojected to lon/lat). Useful for drawing the part of a trail inside a map viewport. Geometry is summarised by default; set geometry_detail to 'full' for all coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | OSM relation ids whose geometry to return. | |
| min_lon | Yes | Western longitude of the clip box. | |
| min_lat | Yes | Southern latitude of the clip box. | |
| max_lon | Yes | Eastern longitude of the clip box. | |
| max_lat | Yes | Northern latitude of the clip box. | |
| geometry_detail | No | Geometry verbosity: 'none', 'summary' (default), or 'full'. | summary |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that geometry is reprojected to lon/lat, clipped, and default summarization is used. However, it does not mention error handling, performance, or what happens with invalid inputs (e.g., out-of-bounds coordinates, missing routes). The behavior is adequately but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the main action, and includes a use case and a note about default behavior. Every sentence adds value, and there is no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and moderate complexity (clipping, reprojection), the description covers the output format (GeoJSON), the default behavior (summary), and the optional parameter (geometry_detail). It does not explain return value structure or error cases, but given the schema coverage, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description reinforces that the bounding box parameters define the clip region and that geometry_detail defaults to 'summary', but it adds little new information beyond the schema descriptions. The mention of WGS84 and reprojection is helpful but not critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves on-map geometry of routes clipped to a bounding box, output as GeoJSON. The verb 'get' and resource 'route segments' are specific, and the description distinguishes it from siblings like find_routes_in_bbox (which finds routes) and get_route_details (which returns metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'drawing the part of a trail inside a map viewport.' This gives context for when to use the tool. However, it does not explicitly mention when not to use it or compare to alternatives like get_route_elevation or get_route_symbol, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the waymarking symbol (route shield) SVG for a given symbol_id. The symbol_id is the value returned as 'symbol_id' by the search/detail tools. Returns the symbol as an image plus the raw SVG markup.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol_id | Yes | The symbol identifier from a route's symbol_id field. | |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that the tool returns 'image plus the raw SVG markup', which is good, but does not explicitly confirm it is read-only or guarantee no side effects. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then providing critical context. Every sentence serves a purpose with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters (1 required) and no output schema, the description covers the necessary context: how to get the symbol_id, what the output contains (image and SVG), and the flavour options. It is nearly complete, though a brief note on the absence of side effects would perfect it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both parameters have descriptions. The description adds value by specifying that symbol_id originates from search/detail tools and explaining the flavour enum values. This goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the specific verb 'Fetch' and the resource 'waymarking symbol (route shield) SVG', clearly differentiating it from sibling tools like get_route_details or get_route_elevation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the symbol_id comes from search/detail tools, providing context on when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, though no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the Wikipedia article URL for a route by its OSM relation id (if the route is tagged with one). Returns the URL; returns a not_found result if the route has no Wikipedia link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | OSM relation id of the route. | |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
| language | No | Preferred language for names (BCP-47 code, e.g. 'en', 'de', 'fr'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool returns a URL or a not_found result, which covers the key behavioral outcomes. However, since there are no annotations, it would benefit from explicitly stating that the operation is read-only or has no side effects. The clarity is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundant information, and the key points are front-loaded. Every sentence adds value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no output schema, few parameters), the description covers the main purpose and behavior adequately. It mentions the condition and the two possible return types. It could be improved by noting any error cases or the format of the not_found result, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for all three parameters (100% coverage). The description does not add extra meaning beyond what is in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a Wikipedia article URL for a route by OSM relation id. It specifies the condition (if tagged) and the outcome (URL or not_found). The purpose is well-defined but could be slightly more specific about when to use this tool versus siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool only works if the route is tagged with a Wikipedia link, but it doesn't explicitly explain when to prefer this over related tools like get_route_details or search_routes_by_name. No alternative guidance or context for usage is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full catalog of Windy Point Forecast models, parameters, and pressure levels with descriptions and model–parameter compatibility. Does not call the Windy API (no quota used). Use before get_point_forecast to choose valid model/parameter combinations.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter models and parameters by category. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility. It discloses that no API call is made (no quota used), which is valuable. However, it omits details like whether data is static or dynamic, or any caching behavior, though for a catalog listing this is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains zero superfluous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter with full schema), no output schema required, and the description covering the purpose and usage context, it is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'category' fully described via enum and default. The description does not add extra meaning about the parameter's effect, but the baseline is 3 due to high schema coverage, and no additional info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns a catalog of forecast models, parameters, and pressure levels with compatibility info. It distinguishes itself from get_point_forecast by positioning as a prerequisite, ensuring clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool ('Use before get_point_forecast to choose valid model/parameter combinations'), providing explicit context for usage in relation to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy-search recreational routes by name or reference code (e.g. 'GR20', 'E5', 'Pennine Way'). Returns summary route entries (id, name, ref, network group, symbol). Use get_route_details with a returned id for full information. To search by location instead of name, use find_routes_near_place.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Route name or reference code to search for. | |
| limit | No | Max results per page (1-100). | |
| page | No | Result page (1-10). | |
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
| language | No | Preferred language for names (BCP-47 code, e.g. 'en', 'de', 'fr'). | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses fuzzy-search behavior, return fields (id, name, ref, network group, symbol), and advises using another tool for details. It omits pagination details and rate limits but provides solid transparency for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, output summary, and guidance. No unnecessary text, front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return fields, search behavior, and next steps. For a search tool with 5 parameters, it is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds no extra semantic detail beyond examples, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does fuzzy-search by name or reference code, with specific examples like 'GR20', 'E5'. It distinguishes from siblings by explicitly mentioning the alternative find_routes_near_place for location searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use get_route_details for full info, and use find_routes_near_place for location-based searches. This clearly tells the agent when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a Waymarked Trails map flavour is online and when its OpenStreetMap data was last refreshed. Useful as a health check.
| Name | Required | Description | Default |
|---|---|---|---|
| flavour | No | Which activity map to query: hiking, cycling, mtb (mountain biking), riding (horse), skating (inline), or slopes (ski/winter). Defaults to hiking. | hiking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description specifies it checks online status and last refresh, implying a non-destructive read. However, it does not disclose potential error conditions, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers its health check purpose and behavior. It could mention expected output format but is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds minimal value beyond the existing parameter description; the default value is already stated in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether a map flavour is online and when data was refreshed, using specific verb 'check' and resource. It distinguishes from sibling tools that focus on route finding and geocoding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'useful as a health check' but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools like route searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0find_routes_in_bboxfind_routes_near_placegeocode_placeget_guidepostget_point_forecastget_route_detailsget_route_elevationget_route_segmentsget_route_symbolget_route_wikilinkget_routes_by_idslist_forecast_optionssearch_routes_by_nametrails_statusAll tools have clearly distinct purposes supported by detailed descriptions. Overlap between find_routes_in_bbox and find_routes_near_place is explicitly disambiguated in descriptions, and no two tools do the same thing.
Tool names predominantly follow a verb_noun pattern (e.g., find_routes_near_place, get_route_details), but trails_status breaks the pattern by being a noun phrase without a verb. The variety of verbs (find, get, list, search, geocode) is acceptable given the diverse operations.
With 14 tools covering route search, details, elevation, segments, symbol, wikilink, geocoding, forecast, and health check, the count is well-scoped for a comprehensive trail information server.
The tool set covers the full lifecycle of querying routes: search by name, location, bbox; get details, elevation, segments, symbol, wikilink; batch retrieval; geocoding; forecast; and server status. No obvious gaps for a read-only API.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Plan your hike. Get your developer token at https://Infoseek.ai/mcp
Search and compare outdoor experiences. Public keyless API; booking and payment happen on Viator.
US outdoor recreation: 37k+ trails, 30k+ campgrounds, parks, weather + wildfire safety. Read-only.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chiraggahujaa/trails-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
