geospatial-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for HTTP transport. The server binds 127.0.0.1 unless PORT is set. | 8000 |
| GEO_CACHE | No | Set to 0 to disable the disk cache. | 1 |
| PHOTON_URL | No | Point at a self-hosted Photon instance. | |
| GEO_TOOLSETS | No | Specifies which toolset to load: `default`, `all`, `offline`, or a comma-separated list. | default |
| OVERPASS_URL | No | Point at a self-hosted Overpass API instance. | |
| VALHALLA_URL | No | Point at a self-hosted Valhalla instance. | |
| GEO_CACHE_DIR | No | Response cache location. Default is ~/.cache/geospatial-mcp. | ~/.cache/geospatial-mcp |
| NOMINATIM_URL | No | Point at a self-hosted Nominatim instance. | |
| GEO_USER_AGENT | No | Override the User-Agent sent to providers. | |
| OPENCELLID_API_KEY | No | Optional; larger cell-tower database. | |
| OPEN_METEO_API_KEY | No | Required for commercial weather use. | |
| OPEN_METEO_BASE_URL | No | Point at a self-hosted Open-Meteo instance. | |
| OPENROUTESERVICE_API_KEY | No | Optional routing upgrade over the keyless default. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| coord_convertA | Convert a position between every common coordinate notation at once. Detects the input format automatically and returns decimal degrees, DMS, USNG/MGRS, UTM, geohash, H3, Plus Code, quadkey and GeoJSON together, so one call answers any "what is this in X?" question. Use this for format conversion. For a different datum or projection (British National Grid, State Plane, Web Mercator) use coord_transform_crs. To check whether a string is a valid coordinate without converting it, use coord_describe. |
| coord_describeA | Check whether a string is a valid coordinate and report its precision. Identifies which notation it is, normalises it, and states the ground accuracy the notation implies -- a grid reference with four digits names a 1 km square, not a point, and a 5-character geohash is about 5 km wide. Returns is_valid=false with an explanation rather than failing, so it is safe to use for validating user input before acting on it. |
| coord_transform_crsA | Transform coordinates between any two coordinate reference systems. For national grids (EPSG:27700 British National Grid, EPSG:2154 Lambert-93, State Plane), Web Mercator (EPSG:3857) and any other EPSG-registered CRS. Reports the transformation PROJ used for this point and its published accuracy. ballpark=true means no published transformation links the two datums, so the shift was ignored: expect tens to hundreds of metres of error. When a more accurate transformation needs a grid file that is not installed, missing_grids names it. Inputs and outputs are always x/easting first, y/northing second, regardless of the axis order the CRS authority declares. |
| geom_measureA | Measure geodesic distance and bearing between points, or a geometry's area. Distances use Karney's algorithm on the WGS84 ellipsoid, accurate to millimetres at any distance including near-antipodal pairs. Areas are computed on the ellipsoid, not in degree space. This is straight-line ("as the crow flies") distance. For travel distance and time along real roads, use route_directions instead -- road distance is typically 20-40% longer. |
| geom_transformA | Reshape a geometry: buffer, simplify, hull, centroid, repair or bounding box. All distances are true ground metres. Buffering projects to an azimuthal equidistant plane centred on the geometry, so a 5 km buffer is 5 km on the ground at every latitude -- not an ellipse stretched by longitude convergence, which is what buffering in degrees produces. concave_hull traces the real outline of a scattered point set (a service territory, a fire perimeter); convex_hull bridges across genuine gaps. |
| geom_overlayA | Combine two geometries with a set operation, reporting the resulting area. The workhorse of overlay analysis: how much of this delivery zone falls inside that flood extent (intersection), what is the combined footprint of these service areas (union), which part of a territory is not yet covered (difference). Invalid input geometries are repaired automatically before the operation, since self-intersecting polygons are common in real data. |
| geom_relateA | Test the spatial relationship between two geometries. Answers point-in-polygon, overlap, containment and adjacency in one call, plus the shortest geodesic distance between them and the nearest point on each. Use this for geofence checks ("is this vehicle inside the zone?"), territory assignment and proximity screening. |
| place_geocodeA | Find the coordinates of an address, place name or landmark. Uses OpenStreetMap: Nominatim for exact structured lookups, or Photon when fuzzy=true for misspelled or partial input (Nominatim's usage policy forbids autocomplete-style queries, so route those here). To go the other way -- coordinates to an address -- use place_reverse. To find categories of thing nearby (fuel, hospitals, hotels) rather than one named place, use place_search. |
| place_reverseA | Find the address or place name at a set of coordinates. The inverse of place_geocode. Useful for labelling GPS traces, describing a delivery destination, or identifying the administrative area a position falls in (lower the zoom to get city, region or country instead of a street address). |
| place_searchA | Find points of interest of a given category near a location. Searches OpenStreetMap for facilities by type -- fuel stations along a route, hospitals near an incident, EV chargers in a city, warehouses in a catchment, communication towers on a ridge. Results are sorted by distance and include the bearing from the search centre. For one specific named place, use place_geocode instead. |
| route_directionsA | Get driving, cycling or walking directions along real roads. Returns distance, travel time and turn-by-turn instructions using OpenStreetMap road data via Valhalla -- no API key needed. Use this for anything involving actual travel: delivery and field-service scheduling, ambulance response-time modelling, freight planning with vehicle restrictions, commute estimation, hiking and cycling routes. For straight-line distance instead, use geom_measure -- it is much cheaper and needs no network. To find everywhere reachable within a time budget rather than the path to one place, use route_isochrone. For travel times between many places at once, use route_matrix rather than calling this repeatedly. |
| route_isochroneA | Map everywhere reachable within a travel-time budget. Returns drive-time (or walk-time, cycle-time) polygons. This is the tool for catchment and accessibility questions: which customers are within 30 minutes of a depot, what a store's 15-minute trade area looks like, how many homes a fire station covers in 8 minutes, where to site a warehouse. direction='to' computes the reverse catchment, which is the correct choice when siting a facility people travel to. Returns polygons that can be passed straight to geom_relate or geom_overlay to count what falls inside them. For the path to one specific destination, use route_directions instead. |
| route_matrixA | Get road travel times and distances between many origins and destinations at once. One call answers "which depot is closest by road to each customer", "which crew can reach each job fastest", or ranks candidate sites by access. Returns a duration and distance for every origin-destination pair, indexed [origin][destination], plus the nearest destination for each origin. Unreachable pairs are null. For turn-by-turn directions on one trip, use route_directions. For everywhere reachable within a time budget, use route_isochrone. For straight-line distance, use geom_measure. |
| terrain_elevationA | Get ground elevation above sea level at a location. Returns height in metres and feet from the Copernicus GLO-90 global DEM (90 m resolution), relative to the EGM2008 geoid -- that is, orthometric height above mean sea level, which is what "elevation" normally means. GNSS receivers report ellipsoidal height, which differs by tens of metres. For elevation along a path rather than at one point, use terrain_profile -- it fetches up to 100 samples in a single request. |
| terrain_profileA | Get the terrain elevation profile along a path between two points. Samples the ground along a true geodesic and returns the full profile plus statistics: minimum, maximum, relief, total ascent and descent. All samples come from one batched request rather than one call per point. Use this for cycling and hiking route difficulty, pipeline and cable routing, drainage assessment, or sizing earthworks. For the elevation at a single point, or at a scattered set of them, use terrain_elevation -- this tool always samples the straight line between two ends. |
| env_weatherA | Get current weather and a multi-day forecast for a location. Returns temperature, precipitation, wind, cloud cover, humidity and visibility from Open-Meteo -- no API key needed. Useful for delivery and field-work scheduling, construction and outdoor event planning, agricultural spray windows, and travel decisions. Note the free Open-Meteo tier is licensed for non-commercial use; set OPEN_METEO_API_KEY and OPEN_METEO_BASE_URL for commercial deployments. |
| sun_moonA | Get sunrise, sunset, twilight, golden hour and moon phase for a location. Computed offline from astronomical formulas -- no network needed. Includes the shadow-length ratio, which is what construction shadow studies, right-to-light assessments and solar-panel shading analysis actually need: a 10 m object at 30 degrees solar elevation casts a 17.3 m shadow. Also used for photography scheduling, crop modelling, delivery windows before dusk, and retail daylight-hours analysis. Inside the polar circles, events that do not occur are returned as null with an explanation rather than as an error. |
| time_at_locationA | Get the time zone and current local time at a location. Returns the IANA zone name, current local time, UTC offset, whether daylight saving is active, and when the next DST transition happens. Computed offline from a bundled boundary dataset. Useful for scheduling across sites, interpreting timestamps in GPS traces, and working out delivery or support-window overlaps. |
| data_convertA | Convert geospatial data between GeoJSON, WKT, WKB, KML, GPX, CSV and polyline. Detects the input format automatically and validates the result, reporting specific problems (self-intersections, out-of-range coordinates, the removed RFC 7946 'crs' member) rather than a bare pass/fail. Handles the everyday format wrangling of real work: a customer sends KML, the routing engine wants an encoded polyline, the warehouse system exports CSV, the web map needs GeoJSON. Runs entirely offline. |
| geo_capabilitiesA | List which geospatial toolsets are enabled and what else is available. Call this when a capability seems to be missing, before telling the user something is impossible -- the tool they need may simply be in a toolset that is switched off, and this returns the exact command to enable it. Also reports which optional API keys are configured and where the response cache lives. |
| rf_link_budgetA | Calculate maximum allowable path loss and the resulting cell radius. Works out EIRP, the loss budget available to the link, and how far that reaches under the chosen propagation model. Use it to size cell coverage, compare frequency bands, or check whether a proposed link closes. Reports a warning when parameters fall outside the model's published validity range -- an empirical model used out of range still returns a confident number, and nothing else will catch that. This is a statistical model over an idealised environment, not a specific path: it answers "how far does this radio reach here?", not "does this exact link clear that ridge?". For the ground between two points, use terrain_profile. For what is already transmitting nearby, use rf_towers. |
| rf_towersA | Find known cell towers near a location. Returns crowdsourced tower records with radio technology (GSM/UMTS/LTE/NR), operator MCC-MNC and approximate position. Useful for coverage benchmarking, IoT and fixed-wireless site qualification, and understanding why signal is poor at a specific address. Uses OpenCelliD when OPENCELLID_API_KEY is set, otherwise the keyless BeaconDB. Coverage is crowdsourced and sparse outside dense urban areas -- an empty result means no contributor has mapped the area, not that no towers exist. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Each tool has a clearly distinct purpose: coordinate validation/conversion/CRS transformation, geometry operations, place lookup, routing modes, terrain, weather, time, data conversion, and RF analysis are all separated. Descriptions explicitly cross-reference similar tools (e.g., coord_convert vs coord_transform_crs, geom_measure vs route_directions), so misselection is unlikely.
Tool names follow a predictable lower_snake_case prefix-based pattern (coord_, geom_, place_, route_, terrain_, rf_) and are readable. However, not all follow a single verb_noun grammar: some are noun_noun (route_directions, env_weather) or noun_prep_noun (time_at_location), making the convention consistent but not perfectly uniform.
At 22 tools, the count sits above the typical 3-15 range and feels slightly heavy, but the broad geospatial domain justifies the number. Each tool covers a distinct capability with no obvious redundancy, and the prefix grouping keeps the set navigable.
The tool surface covers core geospatial workflows well: coordinate/CRS handling, geometry analysis, geocoding/search, routing, terrain, weather, timezone, data conversion, and RF. Minor gaps such as batch geocoding, historical weather, or route optimization exist, but most are workarounds and tools compose cleanly (e.g., isochrones into geom_overlay/relate).