OSM Edit MCP Server

Overview Schema Source Related Servers Discussions Admin

search_osm_elements

Read-onlyIdempotent

Find OpenStreetMap places by name or type within a bounded area, using coordinates or a bounding box to return nearby results sorted by distance.

Instructions

Literal case-insensitive text search in multilingual name/alt_name/ official_name tags (including :* variants) and amenity/tourism/leisure/ historic/shop tags. Requires bbox (west,south,east,north, max 0.25 degrees each side) OR lat/lon/radius_meters (1–10000m). Never a global regex scan. Results sorted by straight-line distance from point or bbox center.

Input Schema

TableJSON Schema

Name	Required	Default
`lat`	No
`lon`	No
`bbox`	No
`limit`	No
`query`	Yes
`element_type`	No	all
`radius_meters`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.2.2Sep 15, 2026

addedInput schema / properties / bbox

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Bbox"
+}

addedInput schema / properties / lat

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Lat"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 20,
+  "title": "Limit",
+  "type": "integer"
+}

addedInput schema / properties / lon

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Lon"
+}

addedInput schema / properties / radius_meters

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Radius Meters"
+}

First observedv0.2.1Sep 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already indicate a read-only, idempotent, non-destructive operation. The description adds meaningful behavioral detail beyond that: literal and case-insensitive matching, multilingual tag variants, spatial constraints, no global regex, and results sorted by straight-line distance. This significantly helps the agent predict behavior and cost.

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?

Three dense sentences, front-loaded with the core search behavior, then constraints and ordering. Every sentence earns its place, and there is no redundant restating of the tool name or schema.

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?

Given seven parameters, zero schema descriptions, and an output schema, the description covers the main search semantics, required spatial constraints, and result ordering. The main missing context is the meaning/possible values of element_type and when to prefer other sibling search tools, but the default and output schema reduce the practical risk.

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?

Schema description coverage is 0%, so the description must compensate. It does for key parameters: bbox format (west,south,east,north, max 0.25 degrees), radius_meters range (1–10000m), and the expected query semantics over specific tags. The element_type parameter is not explained, though its default 'all' mitigates the gap; limit is self-explanatory.

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 names a specific verb and resource: 'Literal case-insensitive text search' over named OSM tags and selected feature tags. It differentiates from sibling tools like get_osm_elements_in_area and search_nearby_places by specifying the exact tag scope and explicitly saying 'Never a global regex scan.' An agent can identify what this tool does without inspecting the schema.

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 gives clear usage context: it requires either a bbox or lat/lon/radius_meters, and it explicitly forbids global regex scans. It does not name alternatives or state when to prefer search_nearby_places or find_nearby_amenities, so it stops short of full when/when-not guidance.

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