Skip to main content
Glama

hikes-trails

Global Waymarked Trail & Mountain Route Explorer. Queries real-time OpenStreetMap relation networks for designated hiking, biking, and mountain trails anywhere in the world.

USE FOR:

  • "How long does it take to hike up Črna Prst from Podbrdo?"

  • "Are there any marked mountain paths near this coordinate?"

  • "Find biking or mountain biking (MTB) trails around this area."

  • Discovering waymark symbols, route difficulty metrics, and trail networks.

CRITICAL INSTRUCTIONS FOR AGENT:

  • Use this tool instead of standard street routers (geo-route) if the destination is a mountain peak, ridge, national park trail, or alpine hut.

  • Set a small buffer (e.g., 0.005 for 500m, up to 0.02 for ~2km) around coordinates to avoid massive data payloads.

  • Accept the features returned by this tool as complete. DO NOT iteratively search or run multiple tag queries sequentially. Read the returned trail distances, calculate speed profiles, and answer immediately.

NOT FOR: Street-grid driving directions, finding urban shops/cafes, raw city geocoding.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYesTarget center latitude coordinate of the trail scan.
lonYesTarget center longitude coordinate of the trail scan.
typeNoLimit the scanned infrastructure footprint. Choose from: 'hiking', 'biking', or 'all'.all
bufferNoBounding search window radius in decimal degrees. (0.005 is ~500m, Max allowed is 0.05 / ~5km).
endpointNoSelect a high-availability server mirror track number (1: kumi-systems, 2: de-main, 3: openstreetmap-fr).1

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, but the description discloses real-time OSM query behavior, network scope (hiking/biking/mountain trails), and instructs the agent to accept returned features as complete. It hints at non-iterative usage but lacks explicit mention of response format or rate limits, which are minor gaps.

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 with sections (header, USE FOR, CRITICAL INSTRUCTIONS, NOT FOR). Every sentence adds value: examples, constraints, and behavioral guidance. No redundancy; front-loaded with key purpose.

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

Completeness4/5

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

Given the tool has 5 parameters, no output schema, and no annotations, the description is quite thorough. It explains usage context, buffer limits, and endpoint options. It could be improved by specifying the return format (e.g., features with geometry and properties), but the instruction to 'calculate speed profiles' implies output structure. Slight gap for full completeness.

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 parameters well. The description adds context like buffer examples (0.005 for 500m) and endpoint mirror options, but does not fundamentally expand beyond what the schema provides. 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 it explores global waymarked trails via OpenStreetMap relation networks for hiking, biking, and mountain routes. It provides specific use cases and distinguishes from sibling tools like geo-route (street routing) and geo-osm (raw OSM).

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?

Explicitly provides 'USE FOR' examples, 'NOT FOR' exclusions, and critical instructions including when to use instead of geo-route, setting buffer limits, and not iterating queries. This gives clear decision context for the agent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (geocoding vs routing vs POI search). However, the multiple Slovenian cadastral tools (simple, deep, wfs-expert) overlap in functionality, potentially confusing an agent on which to use for a given task.

Naming Consistency3/5

Tools within subgroups like 'geo-*' follow a consistent verb_noun pattern, and 'slovenia-*' tools use a noun_adjective pattern. However, across the whole set there is no unified naming convention, mixing prefixes like 'eu-', 'events-', 'hikes-', and 'hostel-'.

Tool Count4/5

With 16 tools, the server is slightly above the ideal range (3-15) but still well-scoped. Each tool addresses a distinct geographic need, although the breadth across many domains (transit, cadastre, weather, hostels) feels a bit broad.

Completeness4/5

The tool set covers core geographic operations (geocoding, routing, POI, isochrones, reverse geocoding) plus specialized Slovenian data and travel amenities. Minor gaps exist, such as lack of general worldwide POI beyond OSM or event discovery beyond Luma, but overall it is comprehensive for its domain.

Resources