Skip to main content
Glama

openstreetmap-mcp-server

Execute a raw Overpass QL query

openstreetmap_query_raw
Read-onlyIdempotent

Execute a raw Overpass QL query for advanced spatial queries that the convenience tools do not cover. Use for multi-type queries, union queries, relation membership, historical queries, or any operation requiring full Overpass QL expressiveness. The query must include [out:json]. Example: "[out:json][timeout:15];node"natural"="peak";out body;" Returns one page of the result set: use limit and offset to page through it, and read totalFound and truncated to see how much the query matched. Validate complex queries at overpass-turbo.eu before use. For simple "what's near X?" or "what's in this area?" queries, use openstreetmap_query_nearby or openstreetmap_query_bbox instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum elements to return. Applied after the Overpass query — if the query matched more, they are truncated.
queryYesOverpass QL query string. Must include [out:json]. The server sets the endpoint and User-Agent; do not include those. Example: "[out:json][timeout:15];node[\"natural\"=\"peak\"](47.5,-122.5,47.7,-122.2);out body;"
offsetNoNumber of matching elements to skip before applying limit, for paging through a large result set. The full match set is fetched and cached ~10 minutes keyed by the query, so re-paging at a new offset is deterministic and costs no extra upstream request; a result over 100000 elements is served but not cached, so paging that far re-queries and depends on the endpoint returning the same order. Pass the nextOffset value from a prior truncated response.
timeout_secondsNoQuery timeout in seconds, bounding how long Overpass itself spends on the query. The [timeout:N] directive in the query string takes precedence if present. The client waits for what is requested here, up to 180s, so a long-running query is not cut off early — but the endpoint enforces its own budget and may answer HTTP 504 first.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when the page came back empty. Distinguishes a query that matched nothing (check syntax or broaden the filter) from an offset past the end of a non-empty result set (retry at a lower offset). Absent when results were returned.
elementsNoRaw Overpass API response elements for this page, up to the limit. Structure varies by query type — nodes have lat/lon, ways have nodes[], relations have members[].
truncatedNoTrue if elements were cut at the limit. Narrow the query, or page with offset to retrieve the rest.
nextOffsetNoOffset to pass on the next call to retrieve the following page of elements. Present only when more elements remain beyond this page.
totalFoundNoTotal elements returned by Overpass before limit truncation.
attributionNoRequired data attribution: Data © OpenStreetMap contributors, ODbL 1.0.
data_timestampNoOSM data freshness timestamp from the Overpass response. Absent when the endpoint reported no freshness metadata.
effectiveQueryNoThe Overpass QL string as sent to the API (after any timeout injection).
total_elementsNoNumber of elements returned on this page. See totalFound for the full match count.
servingEndpointNoOverpass endpoint that produced this response, as origin and path. Differs from the first configured endpoint when a mirror answered after the primary failed, and names the endpoint that served a cached response rather than the one this call would have tried. Pair it with data_timestamp when a result looks unexpectedly slow, sparse, or stale.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly, openWorld, and idempotent hints, and the description adds valuable behavior beyond them: it explains that only one page is returned, how to page with limit/offset, the meaning of totalFound and truncated, and the caching behavior of the endpoint (including the 100k element limit and re-query caveat). It also notes that the server sets endpoint and User-Agent, which is an operational constraint. No contradiction with annotations.

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 information-dense but every sentence earns its place: purpose, use cases, required syntax, example, paging behavior, validation tip, and alternatives are all included without redundancy. The opening sentence immediately clarifies the tool's niche and the example is concrete. It is front-loaded and well-organized.

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

Completeness5/5

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

The description is fully complete for a raw query tool: it covers purpose, when to use, syntax requirements, paging mechanics, output signals (totalFound/truncated), validation advice, and alternatives. The output schema exists, so return format details are not required. The caching behavior and timeout precedence are also disclosed, leaving no critical gaps for correct invocation.

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% and each parameter has a detailed description (limit, offset with caching semantics, timeout with precedence). The tool description reinforces how to use limit/offset for paging but does not add meaning beyond the schema; it mostly echoes the schema's explanations. Baseline 3 is appropriate given complete schema coverage.

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 states a clear verb and resource ('Execute a raw Overpass QL query') and goes further by enumerating specific use cases (multi-type, union, relation membership, historical queries) that distinguish it from the convenience tools. It explicitly names sibling tools for the simple cases, so an agent can differentiate it without inspecting schemas.

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?

The description provides explicit when-to-use guidance (advanced queries requiring full Overpass expressiveness) and when-not-to-use guidance, naming the alternative tools (openstreetmap_query_nearby and openstreetmap_query_bbox) for simple spatial queries. It also advises validating queries at overpass-turbo.eu, covering the practical decision path.

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

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct operation: lookup by ID, bbox query, proximity query, raw Overpass, reverse geocode, and place search. Descriptions explicitly cross-reference when to use each, leaving no ambiguity.

Naming Consistency5/5

All tools follow a consistent openstreetmap_<verb>_<object/qualifier> pattern in snake_case, with clear verb choices (lookup, query, reverse, search) and a coherent query_* subfamily.

Tool Count5/5

Six tools is ideal for a read-only OSM server, covering geocoding, spatial queries, ID lookup, and raw Overpass without redundancy.

Completeness5/5

The surface covers the full lifecycle of geospatial lookups: name-to-coordinates, coordinates-to-address, ID-to-details, area/radius searches, and arbitrary raw queries, with no obvious gaps for the intended domain.