GeospatialMCPforAIPlanning
AI assistants can draft itineraries, suggest attractions, and estimate budgets -- but they cannot reason about physical space. Ask Claude how long it takes to get from the hotel to the museum, and it will guess. Ask it to order five stops efficiently, and it will hallucinate travel times. This technique connects Claude to a live maps service via MCP, replacing guesses with real API data.
Planning a day out with Claude produces a plausible-looking list of places. It falls apart the moment geography matters. Map UIs like Google Maps use JavaScript that Claude cannot parse via web fetch. Without an API connection, Claude has no access to real distances, travel durations, place ratings, or opening hours. Time estimates come from training data -- often wrong, always unverifiable.
An MCP server acts as a bridge between Claude and a maps API. Claude calls the server's tools mid-conversation -- geocoding an address, querying travel time between two points, or finding restaurants near a location -- and reasons over the structured response. The user never leaves the conversation.
- Stop sequencing: Claude calculates travel time between all stops and proposes the most efficient visit order.
- Realistic ETAs: driving, walking, and transit times from live routing data, not estimates.
- Place discovery: find restaurants, attractions, or services near any point in the itinerary.
- Contextual details: opening hours, ratings, and price levels surfaced without tab-switching.
- Multi-city awareness: correct local times and time zone offsets for trips spanning regions.
This technique can be applied at two levels depending on how much planning infrastructure the user wants.
The minimal implementation: a single MCP server that gives Claude access to a maps API. Claude answers spatial questions mid-conversation -- distances, ETAs, nearby places -- without the user setting up additional infrastructure.
Google Maps Platform community MCP servers expose up to six tools: place search, place details, nearby search, directions, geocoding, and reverse geocoding. A Google Maps API key is required. Free OpenStreetMap alternatives exist but are early-stage with limited maintenance and no stable releases. OpenRouteService, a hosted routing and geocoding service built on OpenStreetMap data, is a third free option in this path, distinct from the two community MCP servers above -- it exposes separate routing profiles for walking, cycling, and driving rather than defaulting to one. It is not packaged as an MCP server; reliability under sustained use has not been confirmed. See below.
This path fixes the core pain point: Claude stops guessing and starts querying real data.
The heavier implementation: a self-hosted trip planning application with a built-in MCP server. Claude connects via OAuth 2.1 over HTTP transport and manages the trip programmatically -- creating days, adding stops, querying itinerary structure -- without the user opening a browser. The user can optionally open the application to see the map and itinerary rendered visually, with Claude's changes already reflected.
A self-hosted trip planner can expose 150+ tools covering trip management, place discovery, budgets, and packing lists. It runs in Docker on localhost and supports machine clients with no browser login -- the mode recommended for AI agents.
This path goes beyond fixing the pain point: Claude becomes an agent managing a persistent, structured trip plan rather than answering one-off queries.
- Real-time traffic data requires a paid maps tier. Free OpenStreetMap routing calculates ETAs from speed limits only, with no live congestion data.
- Free OpenStreetMap MCP options (openstreetmap-mcp and osmaps-mcp) are early-stage community projects. openstreetmap-mcp has 5 commits and no releases; osmaps-mcp exposes a single routing tool with 1 star and no recent activity.
- The official Google Maps MCP server in the Anthropic reference repository has been archived. Community forks exist but carry no Anthropic endorsement and limited adoption.
- Google's pricing update (March 2025) replaced the previous $200/month credit with free monthly call limits per SKU. The Directions and Distance Matrix APIs are classified as Legacy SKUs -- their eligibility for the free monthly threshold is not confirmed in Google's documentation. Google Maps Platform also requires a credit card on file to issue an API key at all, regardless of tier.
- The full-stack path requires Docker, a correctly set APP_URL environment variable, enabling the MCP addon in the Admin Panel, and registering an OAuth client -- four sequential steps before the first Claude connection works.
- Free geocoding services do not reliably cover real, currently operating places. Testing against a specific hotel found no match under multiple name variants in a widely used free OpenStreetMap-based geocoder, while a keyed alternative returned an exact match on the first attempt.
- A public routing demo server tested during this assessment returned identical distance and duration for a walking-profile request and a driving-profile request between the same two points, with no error indicating the mismatch. The requested travel mode was silently ignored.
- Access to at least one keyed routing API was found to depend on more than the credential itself: identical authenticated requests succeeded consistently from one client environment and failed consistently from another over more than 30 minutes of testing. The cause was not identified.
- Where a keyed routing API was reachable and returned a correct-profile result for real coordinates, the walking-time estimate still diverged substantially from an actual observed walk in one tested case, understating it by roughly half. Whether a fixed correction factor would close this gap has not been tested beyond a single data point.
Placed at Assess. The pain point is confirmed from first-hand itinerary planning experience: Claude cannot parse JavaScript-rendered map UIs, and training-data time estimates are unreliable. The architecture is sound -- MCP servers for Google Maps Platform and OpenStreetMap both exist and expose the right primitives. A validation attempt against a real itinerary problem was made during this assessment. It surfaced concrete failures beyond general ecosystem immaturity: a free geocoder missing a real business, a public routing demo silently substituting the wrong travel mode, inconsistent access to a keyed API across client environments, and a working, correctly configured lookup that still understated an actual walk by roughly half. Ring remains Assess; the attempt argues for continued caution rather than promotion to Trial.
