Skip to main content
Glama
iamvibhorsingh

bbox-mcp-server

by iamvibhorsingh
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

search_overpass

Query OpenStreetMap for points of interest, roads, or features within a specified area using Overpass QL. Returns structured JSON with a map link.

Instructions

Execute an Overpass QL query to find POIs, roads, or other OSM features within a bounding box or radius. The server wraps your query in the appropriate spatial filter and returns structured JSON with a map link.

SEARCH MODES:

  • Bounding box (default): searches a rectangular area. Use for region/area queries ('hospitals in Manhattan', 'parks in downtown Seattle').

  • Circle: searches within an exact radius. Use ONLY when the user specifies an explicit distance ('within 2km of JFK', '500 metres from the Eiffel Tower', '1 mile from Times Square'). Omit radius_meters for vague terms like 'near' or 'close to'.

COMMON TAG EXAMPLES:

  • Restaurants: nwr["amenity"="restaurant"]

  • Pizza: nwr["amenity"="fast_food"]["cuisine"="pizza"]

  • Supermarkets: nwr["shop"="supermarket"]

  • Parks: nwr["leisure"="park"]

  • Hospitals: nwr["amenity"="hospital"]

  • Schools: nwr["amenity"="school"]

  • Parking: nwr["amenity"="parking"]

  • Highways/Roads: way["highway"]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
locationNoA text location to search for (e.g. 'San Francisco', 'JFK Airport'). Requires MAPBOX_ACCESS_TOKEN env var. Either 'location' or 'bbox' MUST be provided.
bboxNoThe geometry to parse. Can be a raw bounding box string ('lat1,lng1,lat2,lng2'), WKT, GeoJSON, or ogrinfo extent. Either 'location' or 'bbox' MUST be provided.
queryYesThe Overpass QL core query. Example: `node["amenity"="cafe"]` or `nwr["leisure"="park"]`. DO NOT include spatial filters, bounding box, or output directives — the server handles those automatically.
radius_metersNoSearch radius in metres. Enables circle mode — use ONLY when the user specifies an explicit distance (e.g. '2km' → 2000, '500 metres' → 500, '1 mile' → 1609). Omit entirely for area/region queries or vague terms like 'near'.
limitNoMaximum number of elements to return. Default is 100. Increase if you need more results.

Tool Definition Quality

A4.4/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses that the server wraps queries in spatial filters, requires MAPBOX_ACCESS_TOKEN for location, and returns structured JSON with a map link. Does not mention error behavior or rate limits, but those are less critical.

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?

Well-structured with sections (SEARCH MODES, COMMON TAG EXAMPLES) and front-loaded purpose. Could be slightly shorter, but the readability is high and each sentence adds value.

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 no output schema, the description explains return format ('structured JSON with a map link') briefly. It covers the main functionality and constraints, but could elaborate on error cases or pagination. Still, it's sufficient for typical use.

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

Parameters5/5

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

All 5 parameters are described in schema (100% coverage). Description adds value with search mode rules, examples, and contextual hints (e.g., radius only for explicit distances). Exceeds schema detail significantly.

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 executes an Overpass QL query to find OSM features, specifying the return format and spatial filtering. It distinguishes from siblings like aggregate_overpass_h3 or list_osm_tags by focusing on raw query execution.

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?

Provides explicit guidance on when to use bounding box vs radius, and when to include radius_meters (only with explicit distances). Lacks explicit mention of when not to use the tool overall, but context is clear.

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

Install Server

Other Tools

Latest Blog Posts

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/iamvibhorsingh/bbox-mcp-server'

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