bbox-mcp-server

get_bounds

Read-onlyIdempotent

Convert bounding boxes, coordinates, WKT/GeoJSON, map tiles, or place names into formatted bounds with optional metric buffering for mapping, queries, and spatial APIs.

Instructions

Get converted coordinates for a bounding box or natural-language location search (powered by Nominatim with configurable Photon & optional Mapbox fallbacks). Supports parsing WKT, GeoJSON, ogrinfo extent, Web Mercator tiles ('z/x/y'), single points ('lat,lng'), and raw coordinate strings, plus optional metric buffering.

Input Schema

Name	Required	Description
`bbox`	No	The geometry to parse. Can be a raw bounding box string ('lat1,lng1,lat2,lng2'), a single point ('lat,lng'), a Web Mercator tile ('z/x/y'), a WKT polygon/linestring/point, a GeoJSON payload, or an `ogrinfo` extent block. Either 'location' or 'bbox' MUST be provided.
`epsg`	No	The projected EPSG code (e.g. '3857'). Defaults to '4326' (WGS84). Over 3,900 bundled projections; unknown codes are auto-fetched from epsg.io.
`zoom`	No	The map zoom level (0-22) used to calculate the map tile coordinates for the centroid. Defaults to 15.
`format`	No	Format of the output. Options: wkt, geojson-bbox, leaflet, overpass, ogc-bbox, kml, geojson-polygon, csv, stac-bbox. Default: csv.
`location`	No	A text location to search for (e.g. 'New York City', 'Central Park'). Uses OpenStreetMap Nominatim (or configurable NOMINATIM_API_URL / PHOTON_API_URL / optional MAPBOX_ACCESS_TOKEN). Either 'location' or 'bbox' MUST be provided.
`precision`	No	The number of decimal places to output coordinate strings as (defaults to 6).
`coord_order`	No	Toggle between 'lng,lat' (default) and 'lat,lng' coordinate ordering in the formatted output. Useful for APIs that expect swapped coordinate orders.
`buffer_meters`	No	Optional distance in meters to expand (positive) or shrink (negative) the bounding box in all directions. Ideal for creating a bounding box around a single point.

Output Schema

Name	Required	Description	Default
`epsg`	Yes
`center`	Yes
`format`	Yes
`area_km2`	Yes
`complete`	Yes
`warnings`	Yes
`precision`	Yes
`projected`	Yes
`share_url`	Yes
`dimensions`	Yes
`provenance`	Yes
`coord_order`	Yes
`alternatives`	No
`tile_indices`	Yes
`matched_place`	No
`original_wgs84`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.5.0Nov 4, 2026

changedInput schema / properties / bbox / description

Previous value: -"The geometry to parse. Can be a raw bounding box string ('lat1,lng1,lat2,lng2'), a WKT polygon/linestring/point, a GeoJSON payload, or an `ogrinfo` extent block. The Minimum Bounding Rectangle (MBR) encapsulating the geometry will be extracted. Either 'location' or 'bbox' MUST be provided."New value: +"The geometry to parse. Can be a raw bounding box string ('lat1,lng1,lat2,lng2'), a single point ('lat,lng'), a Web Mercator tile ('z/x/y'), a WKT polygon/linestring/point, a GeoJSON payload, or an `ogrinfo` extent block. Either 'location' or 'bbox' MUST be provided."

addedInput schema / properties / buffer_meters

Added value: +{
+  "description": "Optional distance in meters to expand (positive) or shrink (negative) the bounding box in all directions. Ideal for creating a bounding box around a single point.",
+  "type": "number"
+}

changedInput schema / properties / location / description

Previous value: -"A text location to search for (e.g. 'New York City'). Requires MAPBOX_ACCESS_TOKEN env var. Either 'location' or 'bbox' MUST be provided."New value: +"A text location to search for (e.g. 'New York City', 'Central Park'). Uses OpenStreetMap Nominatim (or configurable NOMINATIM_API_URL / PHOTON_API_URL / optional MAPBOX_ACCESS_TOKEN). Either 'location' or 'bbox' MUST be provided."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "alternatives": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "area_km2": {
+      "type": "number"
+    },
+    "center": {
+      "properties": {
+        "lat": {
+          "type": "number"
+        },
+        "lng": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "lat",
+        "lng"
+      ],
+      "type": "object"
+    },
+    "complete": {
+      "type": "boolean"
+    },
+    "coord_order": {
+      "type": "string"
+    },
+    "dimensions": {
+      "properties": {
+        "height_km": {
+          "type": "number"
+        },
+        "width_km": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "width_km",
+        "height_km"
+      ],
+      "type": "object"
+    },
+    "epsg": {
+      "type": "string"
+    },
+    "format": {
+      "type": "string"
+    },
+    "matched_place": {
+      "type": "string"
+    },
+    "original_wgs84": {
+      "properties": {
+        "lat1": {
+          "type": "number"
+        },
+        "lat2": {
+          "type": "number"
+        },
+        "lng1": {
+          "type": "number"
+        },
+        "lng2": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "lat1",
+        "lng1",
+        "lat2",
+        "lng2"
+      ],
+      "type": "object"
+    },
+    "precision": {
+      "type": "number"
+    },
+    "projected": {
+      "properties": {
+        "xmax": {
+          "type": "number"
+        },
+        "xmin": {
+          "type": "number"
+        },
+        "ymax": {
+          "type": "number"
+        },
+        "ymin": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "xmin",
+        "ymin",
+        "xmax",
+        "ymax"
+      ],
+      "type": "object"
+    },
+    "provenance": {
+      "properties": {
+        "attribution": {
+          "type": "string"
+        },
+        "cache_age_ms": {
+          "type": "number"
+        },
+        "cached": {
+          "type": "boolean"
+        },
+        "data_timestamp": {
+          "type": "string"
+        },
+        "provider": {
+          "type": "string"
+        },
+        "usage_policy": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "provider",
+        "data_timestamp",
+        "cached",
+        "cache_age_ms"
+      ],
+      "type": "object"
+    },
+    "share_url": {
+      "type": "string"
+    },
+    "tile_indices": {
+      "properties": {
+        "x": {
+          "type": "number"
+        },
+        "y": {
+          "type": "number"
+        },
+        "z": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "x",
+        "y",
+        "z"
+      ],
+      "type": "object"
+    },
+    "warnings": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "original_wgs84",
+    "projected",
+    "center",
+    "tile_indices",
+    "epsg",
+    "format",
+    "coord_order",
+    "precision",
+    "area_km2",
+    "dimensions",
+    "share_url",
+    "provenance",
+    "complete",
+    "warnings"
+  ],
+  "type": "object"
+}

First observedv1.2.4Apr 2, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive) and openness, so the description's job is narrower and it delivers: it discloses the external dependency on Nominatim with configurable Photon/Mapbox fallbacks, and that unknown EPSG codes are auto-fetched from epsg.io — both network-facing behaviors an agent should know about. It does not mention latency, rate limits, or failure behavior when the geocoder misses.

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 front-loaded sentence that leads with the primary capability and the two input modes, then the format list. It is dense and slightly run-on, and the format enumeration duplicates the bbox schema, but no sentence is wasted.

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?

An output schema exists, so return values need not be explained. Given the input schema, annotations, and output schema, the description supplies the remaining essentials: the external geocoding providers, the projection-source fallback, and the accepted geometry formats.

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%, so baseline is 3. The description restates the bbox input variants and 'optional metric buffering' (buffer_meters), but adds no syntax, defaults, or edge-case guidance beyond what the property descriptions already say; epsg, zoom, format, precision, and coord_order are untouched.

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?

States a specific verb and resource ('Get converted coordinates') and names the two input modes it handles: a bounding box or a natural-language location search. An agent can tell this is a coordinate-conversion helper rather than a geocoder or route tool, though it never names a sibling (e.g. reverse_geocode) to draw the boundary explicitly.

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 only implied: the enumerated input formats (WKT, GeoJSON, ogrinfo extent, z/x/y tiles, 'lat,lng', raw strings) suggest when the tool fits, but there is no explicit 'use this when…' or 'use reverse_geocode instead when…' routing. With nine siblings including reverse_geocode and spatial_calc, the overlap remains for the agent to infer.

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

Deploy Server