Which integrations are available for this server?

Provides read-only query tools for OpenStreetMap data imported into a PostGIS database, enabling searches by name, tags, bounding box, and proximity, as well as schema discovery and category counts.

How do I use osm-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@osm-mcp find all schools in Tokyo" 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.

osm-mcp

by a-tsitanov

Overview Schema Related Servers Score Discussions

Python

Hybrid

osm-mcp

An MCP (Model Context Protocol) server that exposes read-only query tools over osm2pgsql-imported OpenStreetMap data in PostGIS (planet_osm_* tables).

Quick start

uv sync --extra dev              # creates .venv + uv.lock
cp .env.example .env             # then set OSM_MCP_DSN
docker compose up -d             # optional: demo PostGIS with seed data on localhost:55432

.env.example documents the settings:

OSM_MCP_DSN — required libpq connection string. Use a read-only DB role (see the comment in .env.example for the recommended GRANTs).
OSM_MCP_SRID — SRID of the way geometry column (default 3857).
OSM_MCP_STATEMENT_TIMEOUT_MS — per-query statement timeout (default 5000).
OSM_MCP_MAX_ROWS — row cap applied to result sets (default 200).

Related MCP server: mcp-db-server

Running the server

uv run osm-mcp

Runs over stdio by default (how local MCP clients launch it).

HTTP streaming transport

Set OSM_MCP_TRANSPORT=streamable-http (alias http) to serve over HTTP instead of stdio; sse is also supported. Host/port come from OSM_MCP_HOST / OSM_MCP_PORT (default 127.0.0.1:8000); the endpoint path is /mcp.

OSM_MCP_TRANSPORT=http OSM_MCP_HOST=127.0.0.1 OSM_MCP_PORT=8000 \
OSM_MCP_DSN=postgresql://osm_readonly:secret@localhost:5432/osm \
uv run osm-mcp
# -> serves on http://127.0.0.1:8000/mcp

An HTTP-capable MCP client then connects with:

{ "mcpServers": { "osm": { "type": "http", "url": "http://127.0.0.1:8000/mcp" } } }

Unlike stdio, the HTTP/SSE transports print a startup line to stderr showing the URL. (stdio stays silent — its stdout is the protocol channel.)

MCP client config (stdio)

{
  "mcpServers": {
    "osm": {
      "command": "osm-mcp",
      "env": {
        "OSM_MCP_DSN": "postgresql://osm_readonly:secret@localhost:5432/osm"
      }
    }
  }
}

Tools

Tool	Purpose
`describe_schema`	List available `planet_osm_*` tables, their tag columns, and geometry SRID.
`list_categories`	Top values (with counts) of key OSM tags, to discover filters.
`search_features`	Search features by name (ILIKE) and/or tag filters, optional bbox.
`find_nearby`	Features within N meters of a lat/lon, ordered by distance (points + POI polygons; excludes admin/boundary polygons).
`features_in_area`	Features inside a bbox or a named/osm_id polygon.
`count_by_category`	Counts of features per tag value, optionally scoped to an area.
`run_sql`	Escape hatch: run a single read-only `SELECT`/`WITH` query against the OSM tables.

Full reference — parameters, return shapes, and worked examples for every tool: docs/TOOLS.md.

Performance notes

list_categories and area-less count_by_category do full-table scans over unindexed tag columns; prefer scoping them with an area/table, or use them only on modest-size datasets.

Coordinates, SRID, and read-only access

Public tool coordinates (lat/lon in arguments and results) are always WGS84 (EPSG:4326). The DB geometry column (way) is stored in OSM_MCP_SRID (default 3857) and reprojected at the query boundary.
Distance calculations (find_nearby) use PostGIS geography, so distance_m is a true geodesic distance in meters.
Read-only access is enforced at two layers: the DB role used for OSM_MCP_DSN should itself be read-only, and every query additionally runs inside a READ ONLY transaction. run_sql is further restricted to a single SELECT/WITH statement.

Testing

uv run pytest                      # unit + integration
uv run pytest -m "not integration" # unit only, no DB required
uv run pytest tests/unit/test_config.py::test_defaults_applied -v  # single test

Integration tests need a live PostGIS (docker compose up -d); they skip automatically if the DB at OSM_MCP_TEST_DSN (defaults to postgresql://osm:osm@localhost:55432/osm) is unreachable.

Available Tools

7 tools

count_by_categoryB

Count features per value of a tag (default amenity), optionally within an area.

ParametersJSON Schema

Name	Required	Description	Default
`area`	No
`group_by`	No		amenity

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the disclosure is minimal. It mentions counting per tag and optional area, but does not state if it is read-only or any side effects. Adequate for a simple query tool.

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?

Extremely concise single sentence, front-loaded with action. No wasted words, though could include more detail without becoming verbose.

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?

No output schema and no description of return values. Lacks context on how results are structured or how it relates to sibling tools like 'list_categories'.

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 description coverage is 0%, so description must compensate. It adds meaning for 'group_by' as a tag name and 'area' as a geographic filter, but does not explain area format (array or object) or tag values.

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 counts features per tag value, with default 'amenity' and optional area, differentiating it from sibling tools like 'features_in_area' or 'list_categories'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'list_categories' or 'search_features'. The description only states what it does, not when it is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

describe_schemaA

List available planet_osm_* tables, their tag columns, and geometry SRID.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided. The description accurately conveys a read-only metadata listing operation without contradictions.

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?

A single, concise sentence with no extraneous information.

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?

For a simple metadata tool with no output schema, the description fully covers what is returned: tables, tag columns, and SRID.

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?

No parameters exist; baseline of 4 applies as description adds no confusion.

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 lists planet_osm_* tables, tag columns, and SRID. It is specific and distinct from siblings which deal with features, categories, and SQL.

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?

Usage is implied from the description (for schema discovery), but no explicit guidance on when to use versus alternatives like run_sql.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

features_in_areaC

Features inside a bbox [min_lon,min_lat,max_lon,max_lat] or a named/osm_id polygon.

ParametersJSON Schema

Name	Required	Description	Default
`area`	Yes
`limit`	No
`filters`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic functionality, omitting any behavioral traits such as read-only nature, pagination, authentication requirements, error handling, or impact on data. The lack of destructive hint or rate limit information leaves agents underinformed.

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?

A single, well-structured sentence that front-loads the core purpose. Every word is essential; no redundancy or filler. The bbox format is clearly given, and the alternative polygon input is mentioned concisely.

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?

Given the tool's moderate complexity (spatial query with three parameters, no output schema, no annotations), the description is too sparse. It lacks details on return format, result limits, how to handle errors, and additional filtering capabilities. The agent would need to infer or experiment to use the tool effectively.

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 description coverage is 0%, so the description must add meaning. It clarifies the 'area' parameter format (bbox array or polygon object), but does not explain the 'limit' parameter (e.g., maximum features returned, default behavior) or the 'filters' parameter (how to construct filter objects). The added value is limited to one parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns features inside a bounding box or polygon, specifying the bbox format and alternative polygon via name/OSM ID. It distinguishes from sibling tools like find_nearby (point proximity) and search_features (text search). However, it lacks an explicit verb like 'retrieve' or 'list', making it slightly less direct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies spatial area queries, but does not mention when not to use it or direct users to other tools for different needs (e.g., count_by_category for counts, find_nearby for proximity).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_nearbyB

Features within radius_m meters of (lat, lon), ordered by distance.

ParametersJSON Schema

Name	Required	Description	Default
`lat`	Yes
`lon`	Yes
`limit`	No
`filters`	No
`radius_m`	No

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It mentions ordering by distance but omits key behaviors such as whether results are limited, what 'features' includes, or if the operation is read-only. The 'filters' parameter is not explained.

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 conveys the core purpose efficiently. It is concise, but lacks structure such as bullet points for parameters, which would improve scannability.

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?

Given 5 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the output format, pagination, or the role of 'filters'. A more complete description would include parameter details and result expectations.

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 description coverage is 0%, so the description should explain parameters. It implicitly covers lat, lon, and radius_m but does not describe 'limit', 'filters' (including its anyOf type), or provide value ranges or formatting. The default values are mentioned in schema but not in description.

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 returns features within a radius of a point, ordered by distance. It uses specific verbs ('find') and resource ('features'), and distinguishes from siblings like 'features_in_area' which may not order by distance.

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 for nearby spatial searches but does not explicitly state when to use this tool versus alternatives like 'features_in_area' or 'search_features'. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_categoriesC

Top values (with counts) of key OSM tags, to discover filters.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`table`	No

TDQS

C2.2/5.0

Behavior2/5

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

No annotations are provided, and the description does not mention any behavioral traits such as read-only nature, resource impact, or rate limits. It only states the output type (top values with counts) without further behavioral detail.

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

Conciseness3/5

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

The description is a single sentence with no wasted words, but it is underspecified. It could be more informative without being longer, so it achieves baseline conciseness but not excellence.

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?

Given no output schema and no annotations, the description is incomplete. It does not explain the return format, parameter usage, or how to effectively use the tool for its stated purpose.

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

Parameters1/5

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

Schema description coverage is 0% and the description does not explain the two parameters ('limit' and 'table') at all. The agent has no guidance on what 'table' means or how 'limit' affects results, leaving significant ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it lists top values with counts of OSM tags to discover filters, which is somewhat clear but lacks specificity about which tags or how 'top' is determined. It distinguishes from siblings only implicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like count_by_category. The phrase 'to discover filters' is vague and does not provide clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_sqlC

Run a single read-only SELECT/WITH query against the OSM tables.

ParametersJSON Schema

Name	Required	Description	Default
`params`	No
`sql_text`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It specifies read-only and single query, but lacks details on authentication, error handling, rate limits, output format, or behavior on invalid queries.

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?

Single sentence efficiently front-loads key info (read-only, SELECT/WITH). Could be improved with structured details but is not verbose.

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?

Given the complexity of a general SQL tool and no output schema, the description omits critical details like error handling, result limits, and handling of large queries. The sibling tools list is available but not leveraged.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description does not explain the parameters. 'sql_text' is implied to be a SQL query but no format or placeholder info; 'params' is not mentioned at all.

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 runs a single read-only SELECT/WITH query against OSM tables. This is a specific verb+resource and distinguishes it from sibling tools like search_features or count_by_category which are more specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for arbitrary SQL queries not covered by siblings, but does not mention when not to use it or recommend specific alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_featuresA

Search OSM features by name (ILIKE) and/or tag filters, optional bbox.

ParametersJSON Schema

Name	Required	Description	Default
`bbox`	No
`limit`	No
`query`	No
`filters`	No

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description must disclose behavioral traits. It mentions ILIKE search (case-insensitive) and optional bbox filtering, but omits details like pagination, sorting, or behavior with zero results. The description is adequate but not fully transparent.

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 sentence of 10 words, very concise. It front-loades the key verb and resources, but could benefit from slightly more structure to clarify the parameter roles.

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?

Given the tool has 4 parameters, no output schema, and no annotations, the description is too minimal. It omits details on parameter formats, return values, and typical use cases, leaving the agent under-informed 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 0%, so the description must add meaning to parameters. It mentions 'name (ILIKE)' (query), 'tag filters' (filters), and 'optional bbox' (bbox), but does not explain the 'limit' parameter or the format of the filters object. This partially compensates but leaves gaps.

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 purpose: searching OSM features by name (with case-insensitive pattern matching) and/or tag filters, with an optional bounding box. It implicitly distinguishes from siblings like 'features_in_area' (area-based) and 'find_nearby' (proximity).

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 specifies the context (search by name and/or tags, optional bbox) but does not explicitly state when not to use this tool or point to alternatives. The sibling tool names suggest other specialized searches, but no direct guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: counting, schema description, spatial querying, nearby search, category listing, SQL execution, and general search. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., count_by_category, search_features). No mixing of styles or unconventional names.

Tool Count5/5

With 7 tools, the set is well-scoped for OSM data querying. Each tool serves a distinct operation, and the count is neither too small nor overwhelming for the domain.

Completeness4/5

Covers key OSM query patterns: spatial filters, text search, counts, schema introspection, and custom SQL. A minor gap is the lack of a dedicated tool to fetch a single feature by ID, but run_sql can handle it.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ShowMeOnMap A
com.showmeonmap
Ask in plain English, get a rendered, shareable map from live public data. 24 geospatial tools.
Location Services Data Visualization Open Data
292
openstreetmap-mcp-server A
io.github.cyanheads
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
Location Services Open Data
625
nominatim-mcp-server
io.github.cyanheads
Geocode, reverse geocode, and run Overpass spatial queries on OpenStreetMap data.
Location Services Open Data
25
Wherobots A
com.wherobots
Generate and run high performance queries on open and private spatial data at-scale in the cloud
Location Services Cloud Platforms Data Platforms
2

Related MCP Servers

PostGIS Yukon MCP
Databases Location Services
zmGiser
A
license
Not graded
quality
F
maintenance
Enables natural language and geospatial queries on PostGIS databases, with 32 tools for spatial analysis, geometry operations, and database management.
Updated 9 months ago (2025-11-19 07:41 UTC)
4
MIT
mcp-db-server
Databases Search
ExigerDev
F
license
Not graded
quality
D
maintenance
Enables querying PostgreSQL and MySQL databases using natural language, with RESTful endpoints for listing tables, describing schemas, and executing read-only queries.
Updated 6 months ago (2026-02-28 18:46 UTC)
1
SQL Generative MCP
Databases Search
Denuwanhh
A
license
A
quality
B
maintenance
Enables natural language querying of PostgreSQL databases under read-only mode, returning results as structured XML.
Updated 3 months ago (2026-06-14 09:44 UTC)
1
MIT
MCP PostgreSQL
Databases Developer Tools
cuevacelis
A
license
Not graded
quality
D
maintenance
A read-only MCP server for PostgreSQL that enables safe database introspection and querying via natural language.
Updated 3 months ago (2026-05-22 15:45 UTC)
751
MIT

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/a-tsitanov/osm_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server