mcp-server-geo-optimizer
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NODE_ENV | No | production hides unexpected error details from clients | development |
| OSRM_URL | No | http(s) OSRM endpoint | https://router.project-osrm.org |
| LOG_LEVEL | No | debug, info, warn, error | info |
| HTTP_RETRIES | No | Retries for 5xx, 429, and network errors, 0-5 | 2 |
| GEO_USER_AGENT | No | User-Agent sent on every outbound request. Recommended. Include contact details for Nominatim. | |
| HTTP_TIMEOUT_MS | No | Outbound HTTP timeout per attempt | 10000 |
| CACHE_TTL_SECONDS | No | In-memory LRU TTL for geocoding and OSRM responses | 300 |
| GEOCODING_API_KEY | No | Provider API key. Required when GEOCODING_PROVIDER is google or mapbox. Redacted from all logs and error messages. | |
| GEOCODING_PROVIDER | No | Geocoding provider: nominatim (default), google, or mapbox | nominatim |
| HAVERSINE_SPEED_KMH | No | Speed used to convert straight-line km to minutes when OSRM is not used | 40 |
| OSRM_MAX_TABLE_SIZE | No | Max coordinates per OSRM table request, checked before any call | 100 |
| PUBLIC_API_MIN_INTERVAL_MS | No | Minimum spacing between requests to the public Nominatim and OSRM hosts, >= 1000 | 1000 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| optimize_routeA | Order stops for one or more vehicles (TSP/VRP) starting at waypoints[startIndex], with optional capacity and time windows in minutes after route start. Returns per-vehicle stop order (waypoint indices) with arrival/wait/departure minutes, distance in km, time-window violations and unassigned stops. Uses straight-line distances unless useOsrm is true. |
| geocodeA | Forward-geocode an address or reverse-geocode lat/lng using the configured provider (Nominatim by default, rate-limited to 1 request per second). Returns lat, lng and a display name. |
| distance_matrixA | Compute distances (km) and travel times (minutes) from each origin (rows) to each destination (columns). At most 2500 cells per request. haversine is local; osrm calls the configured OSRM server. |
| cluster_pointsA | Group geographic points with deterministic k-means (seeded) or DBSCAN (epsKm radius). Returns clusters with size, centroid (date-line safe) and member points; DBSCAN noise is returned as a cluster with noise=true. |
| boundary_checkA | Point-in-polygon, convex hull and bounding box for {lat,lng} points; handles the antimeridian. A bounding box that crosses the antimeridian has minLng > maxLng (RFC 7946). |
| geojson_utilsA | Validate GeoJSON (structure, coordinate ranges, closed rings), simplify lines and polygon rings (altitude preserved), or convert {lat,lng} points to a FeatureCollection. |
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 6 tools
Each tool targets a distinct geographic operation: geocoding, distance computation, route optimization, clustering, spatial boundary checks, and GeoJSON utilities. Boundaries are clear despite distance_matrix and optimize_route both involving distances, because their purposes and outputs differ substantially.
All names use snake_case, but the conventions are mixed: geocode is a bare verb, distance_matrix and geojson_utils are noun phrases, boundary_check reverses verb/noun order, and optimize_route and cluster_points use verb_noun. This is readable but not a predictable pattern.
Six tools is well-scoped for a geo-optimization server, covering the main operations without bloat. Each tool earns its place by handling a distinct stage of geographic analysis or routing.
The surface covers geocoding, distance matrices, route optimization, clustering, boundary checks, and GeoJSON processing, which is strong for the stated purpose. Minor gaps like isochrone generation or elevation lookup are not essential for core geo-optimizer workflows.