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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / properties / error / properties / data / properties / reason / description
      Previous value: -"Machine-readable failure mode. Declared by this tool: `query_error`: Overpass returned a 400 error — malformed query syntax. `query_timeout`: The query exceeded its timeout (Overpass runtime error in response body). `result_too_large`: Overpass runtime error: query ran out of memory — result set exceeds the server memory limit. `rate_limited`: Overpass refused the query as throttled — HTTP 429, or a throttle document instead of JSON — on every configured endpoint. With a list in OSM_OVERPASS_ENDPOINTS the call advances to the next entry first, so this surfaces only once all of them have refused it. `upstream_error`: Overpass reported a runtime error that is neither a timeout nor memory exhaustion — the message carries the remark verbatim. `overpass_gateway_timeout`: Overpass answered HTTP 504 — it accepted the query but its dispatcher gave up before producing a result, so the query exceeded the time budget the endpoint enforces rather than the [timeout:N] directive. `overpass_unavailable`: Overpass answered with an HTTP 5xx other than 504 (500, 501, 502, 503) — the endpoint is down, restarting, or shedding load. The thrown code tracks the status: 500 and 501 surface as InternalError, every other 5xx as ServiceUnavailable. `endpoints_exhausted`: Every Overpass endpoint tried was still unanswered when the call ran out of its total time budget — each accepted the query and held the connection instead of failing outright. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `query_error`: Overpass returned a 400 error — malformed query syntax. `query_timeout`: The query exceeded its timeout (Overpass runtime error in response body). `result_too_large`: Overpass runtime error: query ran out of memory — result set exceeds the server memory limit. `rate_limited`: Overpass refused the query as throttled — HTTP 429, or a throttle document instead of JSON — on every configured endpoint. With a list in OSM_OVERPASS_ENDPOINTS the call advances to the next entry first, so this surfaces only once all of them have refused it. `upstream_error`: Overpass reported a runtime error that is neither a timeout nor memory exhaustion — the message carries the remark verbatim. `overpass_gateway_timeout`: Overpass answered HTTP 504 — it accepted the query but its dispatcher gave up before producing a result, so the query exceeded the time budget the endpoint enforces rather than the [timeout:N] directive. `overpass_unavailable`: Overpass answered with an HTTP 5xx other than 504 (500, 501, 502, 503) — the endpoint is down, restarting, or shedding load. Every one of them surfaces as ServiceUnavailable. `endpoints_exhausted`: Every Overpass endpoint tried was still unanswered when the call ran out of its total time budget — each accepted the query and held the connection instead of failing outright. Other values are possible when a failure originates below the handler."
  2. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "elements",
      +      "total_elements",
      +      "attribution",
      +      "effectiveQuery",
      +      "totalFound",
      +      "truncated"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / error
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "Present when the call failed. Absent on success.",
      +  "properties": {
      +    "code": {
      +      "description": "JSON-RPC error code for this failure.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "data": {
      +      "additionalProperties": {},
      +      "properties": {
      +        "reason": {
      +          "description": "Machine-readable failure mode. Declared by this tool: `query_error`: Overpass returned a 400 error — malformed query syntax. `query_timeout`: The query exceeded its timeout (Overpass runtime error in response body). `result_too_large`: Overpass runtime error: query ran out of memory — result set exceeds the server memory limit. `rate_limited`: Overpass refused the query as throttled — HTTP 429, or a throttle document instead of JSON — on every configured endpoint. With a list in OSM_OVERPASS_ENDPOINTS the call advances to the next entry first, so this surfaces only once all of them have refused it. `upstream_error`: Overpass reported a runtime error that is neither a timeout nor memory exhaustion — the message carries the remark verbatim. `overpass_gateway_timeout`: Overpass answered HTTP 504 — it accepted the query but its dispatcher gave up before producing a result, so the query exceeded the time budget the endpoint enforces rather than the [timeout:N] directive. `overpass_unavailable`: Overpass answered with an HTTP 5xx other than 504 (500, 501, 502, 503) — the endpoint is down, restarting, or shedding load. The thrown code tracks the status: 500 and 501 surface as InternalError, every other 5xx as ServiceUnavailable. `endpoints_exhausted`: Every Overpass endpoint tried was still unanswered when the call ran out of its total time budget — each accepted the query and held the connection instead of failing outright. Other values are possible when a failure originates below the handler.",
      +          "examples": [
      +            "query_error",
      +            "query_timeout",
      +            "result_too_large",
      +            "rate_limited",
      +            "upstream_error",
      +            "overpass_gateway_timeout",
      +            "overpass_unavailable",
      +            "endpoints_exhausted"
      +          ],
      +          "type": "string"
      +        },
      +        "recovery": {
      +          "additionalProperties": {},
      +          "description": "Actionable next step for the caller.",
      +          "properties": {
      +            "hint": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "hint"
      +          ],
      +          "type": "object"
      +        },
      +        "retryable": {
      +          "description": "Whether retrying may succeed.",
      +          "type": "boolean"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "message": {
      +      "description": "Human-readable description of what went wrong.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "code",
      +    "message"
      +  ],
      +  "type": "object"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "elements",
      -  "total_elements",
      -  "attribution",
      -  "effectiveQuery",
      -  "totalFound",
      -  "truncated"
      -]
  3. Changed10 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 20,
      +  "description": "Maximum elements to return. Applied after the Overpass query — if the query matched more, they are truncated.",
      +  "maximum": 500,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Number 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.",
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / timeout_seconds / description
      Previous value: -"Query timeout in seconds. The [timeout:N] directive in the query string takes precedence if present. Max 180s."New value: +"Query 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."
    • changedOutput schema / properties / elements / description
      Previous value: -"Raw Overpass API response elements. Structure varies by query type — nodes have lat/lon, ways have nodes[], relations have members[]."New value: +"Raw 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[]."
    • addedOutput schema / properties / nextOffset
      Added value: +{
      +  "description": "Offset to pass on the next call to retrieve the following page of elements. Present only when more elements remain beyond this page.",
      +  "type": "number"
      +}
    • changedOutput schema / properties / notice / description
      Previous value: -"Guidance when no elements were returned — e.g., check query syntax or broaden the filter. Absent when results were returned."New value: +"Guidance 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."
    • addedOutput schema / properties / totalFound
      Added value: +{
      +  "description": "Total elements returned by Overpass before limit truncation.",
      +  "type": "number"
      +}
    • changedOutput schema / properties / total_elements / description
      Previous value: -"Number of elements returned."New value: +"Number of elements returned on this page. See totalFound for the full match count."
    • addedOutput schema / properties / truncated
      Added value: +{
      +  "description": "True if elements were cut at the limit. Narrow the query, or page with offset to retrieve the rest.",
      +  "type": "boolean"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "elements",
      -  "total_elements",
      -  "attribution",
      -  "effectiveQuery"
      -]New value: +[
      +  "elements",
      +  "total_elements",
      +  "attribution",
      +  "effectiveQuery",
      +  "totalFound",
      +  "truncated"
      +]
  4. Changed1 schema field changed
    • addedOutput schema / properties / servingEndpoint
      Added value: +{
      +  "description": "Overpass 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.",
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • changedOutput schema / properties / data_timestamp / description
      Previous value: -"OSM data freshness timestamp from the Overpass response. Absent if not included in the response."New value: +"OSM data freshness timestamp from the Overpass response. Absent when the endpoint reported no freshness metadata."
  6. Changed3 schema fields changed
    • addedOutput schema / properties / effectiveQuery
      Added value: +{
      +  "description": "The Overpass QL string as sent to the API (after any timeout injection).",
      +  "type": "string"
      +}
    • addedOutput schema / properties / notice
      Added value: +{
      +  "description": "Guidance when no elements were returned — e.g., check query syntax or broaden the filter. Absent when results were returned.",
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "elements",
      -  "total_elements",
      -  "attribution"
      -]New value: +[
      +  "elements",
      +  "total_elements",
      +  "attribution",
      +  "effectiveQuery"
      +]
  7. First observed

TDQS

A4.9/5.0
Behavior5/5

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

annotations already mark readOnly, openWorld, and idempotent, but the description adds substantial context beyond that: result paging via limit/offset, totalFound/truncated semantics, server-side caching and determinism, timeout precedence, and upstream endpoint budget behavior. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but every sentence earns its place: purpose, usage boundaries, query requirements, example, paging, validation tip, and alternative routing. It is front-loaded with the core purpose and compactly 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?

A complete definition for a raw-query tool. It covers how to construct the query, required and optional parameters, result-set semantics, caching behavior, timeout interactions, and validation workflow. The output schema can carry the return-value details, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning that the schema does not: paging semantics, the nextOffset handshake, cache lifetime, and the [timeout:N] directive precedence. The inline example also clarifies the expected query format.

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 uses the specific verb 'Execute' with the resource 'raw Overpass QL query' and immediately distinguishes it from convenience tools. It names what the tool is for and, importantly, what it is not for.

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?

Provides explicit guidance on when to use this tool (multi-type queries, unions, relation membership, historical queries) and names the sibling tools to use instead for simple near/bbox queries. Exclusions and alternatives are both stated clearly.

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.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: forward geocoding, reverse geocoding, ID-based lookup, bbox queries, nearby radius queries, and raw Overpass queries. Even the two spatial query tools are explicitly differentiated by geometry type.

Naming Consistency5/5

All tools follow the openstreetmap_ verb-based snake_case pattern, with action words like lookup, query, search, and reverse. The three query variants are consistently named with clear qualifiers (bbox, nearby, raw).

Tool Count5/5

Six tools is a well-scoped set for an OpenStreetMap read-only server. Each tool covers a distinct core need without redundancy or padding.

Completeness5/5

The surface covers the major OSM read workflows: geocoding both directions, resolving known IDs, spatial filtering by area or proximity, and a raw escape hatch for advanced queries. No critical lifecycle or query operation is missing for the stated domain.