overpass-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.8/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![overpass-mcp MCP server](https://glama.ai/mcp/servers/Rusty0508/overpass-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Rusty0508/overpass-mcp)

Score Badge

Copy to your README.md:

[![overpass-mcp MCP server](https://glama.ai/mcp/servers/Rusty0508/overpass-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Rusty0508/overpass-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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