Provides tools for accessing OpenStreetMap data, including geocoding place names, finding tagged elements near a point or in an area, fetching individual elements by type and ID, counting matching elements, listing common OSM tag keys and values, and running raw Overpass QL queries.
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., "@overpass-mcp Find coffee shops within 500 meters of Alexanderplatz, Berlin"
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.
An MCP (Model Context Protocol) server that gives an AI agent typed, structured access to OpenStreetMap data through two public, key-free APIs: Overpass (feature queries) and Nominatim (geocoding). No API keys, no paid tier — just the public OSM infrastructure, used the way its operators ask it to be used.
Seven tools, each returning a Pydantic-validated, JSON-serializable result:
geocoding a place name to coordinates and a bounding box
finding tagged elements (amenity=cafe, shop=bakery, ...) near a point or
inside a bounding box
fetching a single OSM element by type and id
counting matches cheaply, without pulling full geometry
listing common OSM tag keys/values as a static, offline reference
running a raw Overpass QL query as an escape hatch
Every tool returns either a valid result or a structured error object — never an exception. See Design notes below for why that distinction matters for an MCP server specifically.
Related MCP server: Geo MCP Worker
git clone https://github.com/Rusty0508/overpass-mcp.git
cd overpass-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"Requires Python 3.11+.
Add the server to your MCP client's config (for Claude Desktop, this is
claude_desktop_config.json; for the Claude Code CLI, .mcp.json or via
claude mcp add):
{
"mcpServers": {
"overpass": {
"command": "/absolute/path/to/overpass-mcp/.venv/bin/overpass-mcp"
}
}
}The overpass-mcp console script is installed by pip install -e . (see
[project.scripts] in pyproject.toml) and talks over stdio, which is what
most MCP clients expect by default. Alternatively, run it directly:
python -m overpass_mcp.serverNo environment variables or API keys are needed — both upstream APIs are public and unauthenticated.
Tool | Parameters | Returns |
|
| List of matches: name, coordinates, bounding box, OSM type/id |
|
| List of |
|
| List of |
|
| A single |
|
|
|
| none | Static dict of tag key -> popular values (no network call) |
|
| Raw parsed Overpass JSON response |
A Place is {osm_type, osm_id, name, coordinates: {lat, lon} | null, tags}.
Every tool response is wrapped as either {"ok": true, "data": {...}} or
{"ok": false, "error": {"code": ..., "message": ..., "hint": ...}}.
Geocode a place:
{"tool": "geocode_place", "arguments": {"query": "Alexanderplatz, Berlin"}}{"ok": true, "data": {"results": [{"name": "Alexanderplatz, Mitte, Berlin, Germany",
"coordinates": {"lat": 52.521, "lon": 13.413},
"bounding_box": {"south": 52.520, "west": 13.410, "north": 52.522, "east": 13.416},
"osm_type": "way", "osm_id": 123456}]}}Find cafes within 500m of a point:
{"tool": "find_places_nearby",
"arguments": {"lat": 52.521, "lon": 13.413, "radius_m": 500, "tag_key": "amenity", "tag_value": "cafe"}}Count fuel stations in a bounding box without fetching their geometry:
{"tool": "count_places",
"arguments": {"south": 52.3, "west": 13.0, "north": 52.7, "east": 13.7, "tag_key": "amenity", "tag_value": "fuel"}}A failure looks like this (never a stack trace, never a raised exception):
{"ok": false, "error": {"code": "TIMEOUT",
"message": "timeout calling https://overpass-api.de/api/interpreter",
"hint": "upstream did not respond in time; retry, or reduce the search radius/area"}}Every tool in this server catches its own failures and returns a structured
{"ok": false, "error": {"code", "message", "hint"}} object instead of letting
an exception propagate out of the tool call. This is a deliberate choice, not
an oversight of Python idiom.
An MCP tool call happens inside an agent's reasoning loop. If the tool raises,
the exception surfaces as a protocol-level failure the agent cannot reason
about the way it can reason about data — depending on the client, it can look
like the tool doesn't exist, or it can terminate the turn outright. Either way,
the agent loses the chance to notice what kind of failure happened and
decide what to do next: retry a timeout, back off on a 429, or tell the user a
bounding box was invalid and to please review it. A structured error is just
another shape of successful tool output — the agent reads error.code, decides
on a strategy, and keeps going. The distinction that matters here is not
"exception vs. return value" as a Python style preference; it is "does the
protocol layer see a broken tool, or does the agent see actionable
information." An MCP server is a service boundary, and prompted agents behave
better with predictable failure data than with the interruption of an
exception.
client._request_with_retry retries on timeout and 5xx responses, with
exponential backoff, for both the Overpass POST call and the Nominatim GET
call. The common heuristic — "retry GET, never retry POST" — uses the HTTP
method as a proxy for whether a retry is safe. That heuristic is the right
default when the method is unknown, but here the actual property that matters
is checked directly: neither upstream API has a write endpoint at all, and
both calls used by this server are pure reads. Overpass happens to use POST
only because a QL query body doesn't fit comfortably into a query string —
semantically it is a GET. Retrying is therefore safe for both calls: repeating
the same request cannot create a duplicate side effect, because there is no
side effect to duplicate. A 429 is handled separately from timeouts/5xx: if the
response carries a Retry-After header, the retry waits exactly that long
instead of using its own backoff schedule, because the upstream server is
telling us precisely how long to wait.
Both APIs are free, key-free, and run by volunteers/small teams on donated infrastructure — nothing about them requires payment, but that also means nothing stops a careless client from taking them down for everyone else. This server takes their published usage policies as hard constraints, not suggestions:
Nominatim's documented limit of one request per second is enforced in code
(asyncio.Lock + a monotonic timestamp), not left to the caller's
discipline — the lock ensures it holds even under concurrent tool calls
from the same process.
Every request sends a descriptive User-Agent identifying the project,
because Nominatim blocks generic/default user agents outright.
Every request has an explicit connect/read/write/pool timeout — nothing waits forever, and the server does not hold a connection open speculatively.
raw_overpass_query has a hard length cap (8000 characters) so a single
agent-generated query cannot balloon into something that hurts a shared
public endpoint.
out center for way/relationOverpass elements come in three kinds — node, way, relation — and only
node carries coordinates directly. A way is a sequence of node references;
a relation is a set of member references; neither has a lat/lon of its
own. Every query built by this server appends out center;, which asks
Overpass to compute and attach a centroid to way/relation elements. Forgetting
this is a common, easy-to-miss bug: the query still succeeds, still returns
elements, and roughly half the results (every non-node) simply come back
with no usable position — a silent hole in the data rather than a visible
error. element_to_place reads lat/lon directly for nodes and falls back
to center.lat/center.lon for ways/relations, and its coordinates field
is only None in the rare case where Overpass itself could not resolve a
center.
source .venv/bin/activate
python -m pytest tests/ -v
ruff check .All network access in tests is mocked with respx
at the httpx transport layer — the test suite never contacts
overpass-api.de or nominatim.openstreetmap.org.
MIT — see LICENSE.
Count OSM elements matching a tag within a bounding box (cheaper than full geometry).
| Name | Required | Description | Default |
|---|---|---|---|
| east | Yes | ||
| west | Yes | ||
| north | Yes | ||
| south | Yes | ||
| tag_key | Yes | ||
| tag_value | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description makes clear that the tool produces a count, not geometries, and hints at a performance advantage ('cheaper'). However, since no annotations are provided, it does not disclose details such as whether the count includes both nodes and ways, or any potential rate limits or exact matching 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 entire description is a single, well-structured sentence that leads with the verb and includes the key context. Every word contributes 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?
The description is sufficient for a simple counting tool, and the presence of an output schema handles return value details. However, the lack of parameter documentation and explicit usage guidance means the agent might need to rely on schema inspection and sibling context to fully understand invocation.
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 0%, and the description only mentions 'a tag' and 'bounding box' without mapping them to the parameter names. It doesn't clarify that tag_value is optional or explain the coordinate semantics beyond their numeric type ranges.
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 action (count), the object (OSM elements), the filter (matching a tag), and the scope (within a bounding box). The verb 'count' differentiates it from sibling tools that 'find' or 'geocode'.
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 phrase 'cheaper than full geometry' implies the tool is intended for lightweight count operations rather than retrieving geometries, but it does not explicitly state when to choose this over siblings like find_places_in_area or list_common_tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find OSM elements matching a tag within a bounding box.
| Name | Required | Description | Default |
|---|---|---|---|
| east | Yes | ||
| west | Yes | ||
| limit | No | Max number of elements to return | |
| north | Yes | ||
| south | Yes | ||
| tag_key | Yes | OSM tag key, e.g. "shop" | |
| tag_value | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only says 'Find', implying a read-only operation, but does not mention rate limits, result limits, pagination, or any side effects. The description is too sparse to convey the tool's behavior beyond the basic search action.
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 a single, clear sentence with no filler or unnecessary details. It is appropriately front-loaded, placing the verb and action directly at the start, and every word earns its place.
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 an output schema, the tool has 7 parameters with poor schema coverage and no annotations. The description only covers the basic purpose and does not provide enough context for an agent to correctly choose parameters (e.g., bounding box semantics, optional tag_value), making it incomplete for reliable invocation.
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 only 29% schema coverage, the description must compensate for the undocumented parameters, but it does not. It merely mentions 'a tag' and 'bounding box' without explaining the coordinate order, how tag_value relates to tag_key, or the meaning of the limit parameter. The schema descriptions for limit and tag_key already cover some semantics, but the description adds no new parameter insight.
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 OSM elements by tag within a bounding box, using a specific verb ('Find'), resource ('OSM elements'), and scope ('bounding box'). This distinguishes it from sibling tools like find_places_nearby, which likely use a different spatial query approach.
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 when a bounding box and tag are provided, but it does not explicitly state when to use this tool over alternatives such as raw_overpass_query or find_places_nearby. No exclusions or alternative guidance are given, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find OSM elements matching a tag within a radius of a point.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Center point latitude | |
| lon | Yes | Center point longitude | |
| limit | No | Max number of elements to return | |
| tag_key | Yes | OSM tag key, e.g. "amenity" | |
| radius_m | Yes | Search radius in meters, max 50000 | |
| tag_value | No | OSM tag value, e.g. "cafe"; omit to match any value |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It provides no details about whether ways/nodes/relations are included, whether results are sorted by distance, how the optional tag_value affects matching, or what happens when no matches are found. The schema describes parameters, not runtime 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 a single, front-loaded sentence that efficiently states the tool's purpose without redundancy. It could include more context, but it is appropriately concise and not padded with filler.
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 presence of a complete output schema and 100% schema description coverage, the description is minimally sufficient for a simple search tool. However, it lacks key contextual guidance such as the type of OSM elements searched, sorting behavior, and how the optional tag_value affects results, leaving some gaps for an agent to infer.
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 documents all six parameters with 100% coverage, so the baseline is 3. The description only restates the tag/radius concept and adds no new semantic detail about parameter formats, defaults, or edge cases beyond what is in 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 uses a specific verb ('Find') with a clear resource ('OSM elements') and an explicit spatial scope ('within a radius of a point'). It naturally distinguishes itself from the sibling tool find_places_in_area by specifying the point-radius search geometry.
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 implies the use case for radial proximity searches around a coordinate, making the core scenario evident. It does not explicitly mention alternatives or exclusions, such as when to prefer find_places_in_area or geocode_place, but the point-versus-area distinction is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Geocode a place name to coordinates and a bounding box via Nominatim.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of matches to return | |
| query | Yes | Free-text place name or address |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions 'via Nominatim,' which indicates an external service dependency, but does not disclose rate limits, error behavior, no-result handling, or any other operational caveats. For a tool with zero annotation coverage, this is insufficiently 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 a single, information-dense sentence that front-loads the primary purpose and output. There is no redundant or filler content.
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 simple two-parameter tool with a rich input schema and an output schema present, the description is largely complete. It conveys the core functionality and the external service. The only minor gap is the lack of differentiation from sibling tools, which is not critical given the descriptive name and clear purpose.
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 provides 100% description coverage for both parameters (query and limit), including defaults, constraints, and meanings. The tool description adds no additional parameter-level detail, so the baseline score of 3 is appropriate without extra credit.
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 uses a specific verb ('Geocode') and identifies both the input (place name) and output (coordinates and bounding box). It clearly distinguishes this tool from siblings like 'find_places_nearby' or 'find_places_in_area' which operate on spatial proximity rather than text-to-coordinate conversion.
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 when a textual place name needs to be converted to coordinates. However, it does not explicitly state when to use this tool versus alternatives such as find_places_nearby or raw_overpass_query, nor does it mention any exclusions or prerequisites. This is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single OSM element by type and id, with coordinates resolved via out center.
| Name | Required | Description | Default |
|---|---|---|---|
| element_id | Yes | OSM element id | |
| element_type | Yes | OSM element type |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 does disclose one behavioral trait (coordinate resolution via 'out center'), but it does not mention error handling (e.g., element not found), auth requirements, or rate limits. For a fetch tool, the description adds some value but omits important 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 a single, front-loaded sentence that efficiently conveys the action, resource, and a key behavioral nuance. No filler or redundant 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?
With a simple tool, full parameter schema coverage, and an output schema present, the description need not explain return values. It adequately covers the core purpose and one behavioral detail. It lacks explicit usage guidelines, but given the simplicity and available structured data, it is mostly 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?
Schema coverage is 100%, with clear descriptions for both element_type and element_id. The description simply restates the parameters without adding new semantic detail, so it meets 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 states a specific action ('Fetch') with a clear resource ('single OSM element') and the key parameters ('by type and id'). It also adds a distinctive detail ('coordinates resolved via out center') that separates this from sibling tools like geocode_place or find_places_nearby.
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 use when you have a specific element type and ID, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools exist for searches and raw queries, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List common OSM tag keys and their popular values. Static reference, no network call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It explicitly states 'Static reference, no network call,' which is a key behavioral trait, and 'common' implies the list is not exhaustive. This provides useful context beyond the bare functionality without contradicting any structured data.
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 extremely concise and well-structured: two short sentences. The first sentence states the purpose, and the second adds a key behavioral note. Every word earns its place, with no redundancy.
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 (0 parameters, output schema present), the description sufficiently covers its purpose, behavior (static, no network), and scope ('common' tags). The output schema handles return details, so the description is complete enough for an AI agent to decide when and how to use 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?
The tool has 0 parameters, so the baseline score is 4. The description reinforces that no inputs are needed by stating the tool is a static reference, but since there are no parameters, the schema already covers everything. The description adds no extra parameter details, but none are 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 clearly states the tool's function: 'List common OSM tag keys and their popular values.' It uses a specific verb ('List') and resource ('OSM tag keys and their popular values'), and distinguishes itself from siblings by adding 'Static reference, no network call,' which sets it apart from network-based tools like raw_overpass_query.
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 is for quick reference via 'Static reference, no network call,' but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The usage context is clear but not explicitly tied to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a raw Overpass QL query.
Advanced escape hatch for queries the other tools cannot express (custom
filters, out geom;, statistics, etc). Length-validated; empty input is
rejected before any network call is made.
| Name | Required | Description | Default |
|---|---|---|---|
| ql | Yes | Raw Overpass QL query |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully mentions length validation and that empty input is rejected before any network call, but it does not disclose potential risks of raw query execution, error behavior, rate limits, or response size implications.
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: three short sentences with no redundancy. The main purpose is front-loaded in the first sentence, and the remaining sentences add useful context about scope and validation.
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 raw query escape hatch, the description covers purpose, alternatives, examples, and validation, and an output schema exists so return values need not be explained. It is incomplete only in not addressing failure modes or operational limits, such as what happens when a query is invalid or exceeds server-side constraints.
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 describes 'ql' as 'Raw Overpass QL query' with min/max lengths, giving full coverage. The description adds value by enumerating example query contents (custom filters, 'out geom;', statistics) and clarifying validation behavior, which goes slightly 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 opens with a specific verb-resource pair: 'Execute a raw Overpass QL query.' It further distinguishes itself from sibling tools by labeling it an 'Advanced escape hatch' for queries 'the other tools cannot express' and gives concrete examples like custom filters and 'out geom;'.
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 when to use this tool: for queries that other tools cannot express, such as custom filters, 'out geom;', or statistics. This provides clear guidance on usage vs. the sibling geospatial tools, even if it does not enumerate every exclusion.
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.0count_placesfind_places_in_areafind_places_nearbygeocode_placeget_elementlist_common_tagsraw_overpass_queryEach tool targets a distinct operation: geocoding, spatial search by radius or bbox, single-element fetch, counting, raw querying, and tag reference. The two search tools are clearly differentiated by spatial constraint, and the counting tool explicitly avoids returning geometries.
Most tool names follow a verb_noun pattern (e.g., geocode_place, find_places_nearby, get_element), but raw_overpass_query deviates from this pattern by using an adjective_noun construction. Overall, the naming is mostly consistent and easy to predict.
With seven tools, the set is well-scoped for an Overpass API server: it covers common high-level operations plus a raw query escape hatch without unnecessary redundancy. This is within the ideal 3-15 tool range.
The tools cover the core workflow of geocoding, spatial querying, fetching specific elements, and counting. The raw_overpass_query tool ensures any unexpressed Overpass query is still possible, eliminating dead ends and making the surface functionally complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nominatim MCP — wraps OpenStreetMap Nominatim geocoding API (free, no auth)
OpenStreetMap Overpass MCP — programmatic queries against the OSM database
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rusty0508/overpass-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server