cablate/mcp-google-map: An MCP Server That Wraps 18 Google Maps Tools
A powerful Model Context Protocol (MCP) server providing comprehensive Google Maps API integration with LLM processing capabilities.
At a glance
- What is it?
- A TypeScript Model Context Protocol server that exposes Google Maps geocoding, routing, places, weather and air quality as MCP tools, plus four composite tools for area exploration and route planning. The main judgement: it is a thin, MIT-licensed wrapper, so your real costs are Google Cloud API billing and key handling, not the server itself.
- Who is it for?
- Adopt it if your agent already needs Google Maps data and you want it behind the MCP protocol without writing your own tool schemas; the stdio install is a single npx command and the tool list is filterable through GOOGLE_MAPS_ENABLED_TOOLS. Do not adopt it if you need provider independence, since every tool call reaches Google's APIs and the README requires Places API (New) and Routes API enabled in Google Cloud Console.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills between an LLM and Google Maps
A language model cannot resolve "Tokyo Tower" to a latitude and longitude, cannot compute a driving time that respects toll avoidance, and cannot tell you the air quality index at a coordinate. Those are API calls with structured responses, and the Model Context Protocol exists to give those calls a schema an agent can invoke. This project supplies that schema for Google Maps. It is aimed at people building agents in Claude Desktop, Cursor, VS Code or any other MCP client, and at people who want the same tools available from a shell script without running a server at all. The README frames the goal as giving an agent the ability to "understand the physical world" through geocode, route, search and reasoning steps. The concrete deliverable is 18 tools: 14 atomic ones covering geocoding, reverse geocoding, place search, place details, distance matrix, directions, elevation, timezone, weather, air quality, static map images, batch geocoding and search along a route, plus four composite tools. Nothing here is a new geospatial engine. It is an adapter layer, and that is the honest description of its value.
Four composite tools and the Agent Skill that chains them
The interesting design choice is the composite layer. maps_explore_area searches multiple place types around a location and pulls details in one call. maps_plan_route orders a multi-stop itinerary using Routes API waypoint optimization, with a stated ceiling of 25 stops. maps_compare_places searches, fetches details and optionally computes distances for a side-by-side view. maps_local_rank_tracker scans a geographic grid for a business's local search ranking, accepts up to 3 keywords per batch, and returns the rank at each grid point plus the top three competitors and metrics the README names as ARP, ATRP and SoLV. That last tool is the one that behaves least like a convenience wrapper and most like a purpose-built product, since grid rank tracking normally means a separate subscription. Alongside the tools sits an Agent Skill definition under skills/google-maps/ that the README says teaches an AI how to chain the geo tools. The skill file is the part worth reading before you trust the composites, because chaining decisions live there rather than in the server.
Three transports, one tool surface
The server runs in three modes. stdio is the default recommendation for desktop clients. Streamable HTTP is the default transport otherwise and is meant for multi-session deployments, per-request API key isolation or remote access, which the README credits to contributor @junyinnnn. The third mode is a standalone exec CLI that runs a single tool without a server process. Tool registration is filterable: set GOOGLE_MAPS_ENABLED_TOOLS to a comma-separated list such as maps_geocode,maps_directions,maps_search_places, or omit it (or set it to *) to register all 18. That filter is the practical answer to context bloat, because every registered tool contributes its schema to the model's context window whether or not the conversation needs it. Note the naming asymmetry: the environment variable uses the MCP tool names with the maps_ prefix, while exec mode uses short names. The README shows exec geocode and exec search-places, not exec maps_geocode, so a filtered stdio config and an exec command do not share one identifier vocabulary. That is a small trap for anyone generating configs programmatically.
Getting it running: stdio, HTTP and exec commands
The stdio path is a JSON block in your MCP client config: command npx, args ["-y", "@cablate/mcp-google-map", "--stdio"], and an env object holding GOOGLE_MAPS_API_KEY. For HTTP, run npx @cablate/mcp-google-map --port 3000 --apikey "YOUR_API_KEY", optionally adding --host 0.0.0.0 to bind all interfaces for Docker or LAN access, then point the client at http://localhost:3000/mcp with type set to http. For one-off calls, exec takes a tool name and a JSON argument string, as in npx @cablate/mcp-google-map exec geocode '{"address":"Tokyo Tower"}' or exec search-places '{"query":"ramen in Tokyo"}'. Two operational details deserve attention. First, the README states a prerequisite: enable Places API (New) and Routes API in Google Cloud Console before place-related and routing tools will work, so a key that only has Geocoding enabled will fail partway through the tool list. Second, all tools are annotated readOnlyHint true and destructiveHint false, which the README says lets MCP clients auto-approve them without user confirmation. That annotation is accurate about the API calls, but it also means a misconfigured agent can issue a large number of billable requests without a prompt. Set quotas in Google Cloud Console before you rely on auto-approval.
Where it stops being the right tool
The server is a pass-through, so its failure modes are mostly Google's failure modes with an extra hop. Latency is the sum of the MCP round trip and the upstream API call. Cost is entirely Google's pricing, and the tool list is broad enough that an agent exploring freely can fan out: maps_explore_area issues multiple searches and details lookups in one invocation, and maps_local_rank_tracker scans a grid, which multiplies requests by grid size and keyword count. There is no caching layer described in the material, so repeated identical geocodes are repeated billable calls. The batch ceiling is real: maps_batch_geocode caps at 50 addresses and maps_plan_route at 25 stops, so larger jobs need client-side chunking. Provider lock-in is total. Every tool targets Google, and the README's comparison table against Google's own Grounding Lite is a feature-count argument, not a portability argument. If your requirement is to swap geocoders per region, or to avoid Google's terms entirely, this project is the wrong shape and no configuration flag changes that.
Grounding Lite and hand-rolled MCP servers as the alternatives
The README positions the project against Google's Grounding Lite, which it lists as offering 3 tools to this project's 18, with weather as the only overlap. The table marks Geocoding, step-by-step directions, elevation, distance matrix, place details, timezone, air quality and map images as absent from Grounding Lite, and notes that Grounding Lite is Google-managed with no self-hosting and no Agent Skill. The difference in approach matters more than the count. Grounding Lite is a managed endpoint you call; this is an npm package you run, which means you own the process, the key distribution and the upgrade cadence. The second alternative is writing your own MCP server against the Google Maps client libraries. That gives you exactly the tools you need, your own caching, and your own naming conventions, at the cost of building and maintaining the schemas, the transport wiring and the three run modes. The honest trade-off: this project is worth adopting when 18 tools is close to what you would have written anyway, and worth skipping when it is not, because the composite tools are the only part that is genuinely more than boilerplate.
Maintenance cadence, MIT licence and what that implies
The release history shows v0.0.53 in July 2026, then v0.0.54 and v0.0.55 in mid-August 2026, so the project is moving in small increments rather than long-stable plateaus. The 0.0.x versioning is a signal in itself: there is no declared stable API surface, and a minor version bump can change tool names, argument shapes or the enabled-tools filter without a major-version warning. Pin the version in your MCP client config rather than relying on npx resolving the latest tag, and read the release notes before bumping. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive grant on the server code only. It says nothing about your use of Google Maps data, which is governed by your Google Cloud agreement and the Maps Platform terms, and nothing about the API key you embed in a client config file. This is not legal advice; check the terms that apply to your deployment. The maintenance cost you should actually budget for is Google's side, not this repository's: API deprecations, new required API enablements and quota changes all land on you, and the README already shows one such requirement in the Places API (New) and Routes API prerequisite.
Editorial conclusion
Adopt it if your agent already needs Google Maps data and you want it behind the MCP protocol without writing your own tool schemas; the stdio install is a single npx command and the tool list is filterable through GOOGLE_MAPS_ENABLED_TOOLS. Do not adopt it if you need provider independence, since every tool call reaches Google's APIs and the README requires Places API (New) and Routes API enabled in Google Cloud Console. Before wiring it into anything shared, verify your API key restrictions and quota limits in Google Cloud Console, and confirm which of the 18 tools your client actually registers after filtering.
Community notes