Execute Overpass QL over OSM nodes, ways, and relations with bounded output. Subscription or approved x402 payment required. No historical attic queries. Check service_status before claiming global results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A complete bounded Overpass QL query, with explicit timeout and output limit. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses payment requirements, the bounded-output constraint, the attic-query prohibition, and the dependency on service_status. It does not cover rate limits, error behavior, or result format, but the critical operational constraints are surfaced.
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 dense sentences with no filler: the first front-loads the purpose and scope, and the second lists requirements and operational cautions. Every clause contributes distinct information, making it both concise and well-structured.
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 complex Overpass QL tool without an output schema or annotations, the description leaves out the return shape, how 'global results' are defined, and how payment approval is verified. It covers important preconditions but is not fully self-sufficient for an agent deciding whether and how to 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?
The schema already documents the query parameter at 100% coverage, including that it must be a complete bounded Overpass QL query with explicit timeout and output limit. The tool description mostly restates 'bounded output' without adding syntax, format, or additional semantic details 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 a specific verb, 'Execute Overpass QL,' and the resource, 'OSM nodes, ways, and relations,' while adding the key constraint of 'bounded output.' This sufficiently differentiates it from siblings like basemap_catalog and service_status by making both the domain and the operation explicit.
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 gives explicit preconditions: subscription or approved x402 payment, no historical attic queries, and checking service_status before claiming global results. It provides clear exclusions and usage context, though it does not explicitly name an alternative tool or say 'use X instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tools are mostly distinct: basemap_catalog, elevation, and service_status each target unique resources, while find_features and overpass_query both touch OSM data but are differentiated by abstraction level (preset categories in a small bbox vs. raw Overpass QL). Agents could still hesitate between the two OSM search tools, so not a perfect 5.
All names are lowercase snake_case, but they don't follow a consistent verb_noun pattern: most are noun phrases (elevation, overpass_query, service_status) and only find_features uses a verb. This is readable but stylistically mixed.
Five tools is a well-scoped set for a geospatial API: catalog, elevation, feature search, raw Overpass query, and service status. Each tool has a clear role and none feel redundant or excessive.
The core read-only geospatial workflows are covered: discover basemaps, sample elevation, search OSM features, run arbitrary Overpass queries, and check data/service state. Minor gaps exist (e.g., no direct basemap tile fetching or geocoding/reverse-geocoding), but agents can work around these with Overpass and the catalog details.