# cablate/mcp-google-map: 18 Google Maps tools for MCP clients

> A TypeScript MCP server that exposes geocoding, places, routing, weather and air quality to LLM agents, with a stdio mode, a Streamable HTTP mode and a standalone exec CLI. The tool count is the selling point; the API key and the enabled-API prerequisites are the cost.

**cablate/mcp-google-map** — A powerful Model Context Protocol (MCP) server providing comprehensive Google Maps API integration with LLM processing capabilities.

- Repository: https://github.com/cablate/mcp-google-map
- Stars: 467 · Forks: 90
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/cablate-mcp-google-map

## Who needs 18 geospatial tools inside an MCP client

The problem is not that Google Maps data is hard to reach. It is that an LLM agent has no way to reach it. A model asked to plan a two-day Kyoto itinerary, find ramen near a hotel, or check whether a route avoids tolls will produce plausible text and no coordinates. cablate/mcp-google-map is the adapter layer: a Model Context Protocol server that registers Google Maps operations as callable tools and lets the client decide when to call them.

The target user is someone running an MCP-capable client (the README names Claude Desktop, Cursor and VS Code) who wants location reasoning inside the same conversation as everything else. The repository also ships a skill definition under skills/google-maps/, described as teaching an AI how to chain geo tools, which points at multi-step workflows rather than single lookups. Four of the tools are explicitly composite: maps_explore_area, maps_plan_route, maps_compare_places and maps_local_rank_tracker. Those exist because a model calling maps_search_nearby and then maps_place_details for twelve results burns turns and context. Bundling the loop into one tool is the design bet.

The narrower audience is worth naming. maps_local_rank_tracker scans a business's local search ranking across a geographic grid and returns rank at each point, top-3 competitors and metrics the README abbreviates as ARP, ATRP and SoLV. That is a local-SEO workflow, not a general assistant feature. If you are not doing rank tracking, one of the eighteen tools is dead weight you still pay for in context.

## How the server maps MCP tool calls onto Google APIs

The package is TypeScript, built with tsup, and depends on @modelcontextprotocol/sdk plus @googlemaps/google-maps-services-js and @googlemaps/places. So the transport and protocol handling come from the official MCP SDK, while the actual HTTP calls to Google go through Google's own client libraries. This is a thin layer, not a reimplementation, which matters when you are judging what breaks: a Google API change surfaces here as a dependency bump, not as bespoke request code.

The tool surface splits into 14 atomic and 4 composite tools. Atomic entries are one-to-one with a Google capability: maps_geocode, maps_reverse_geocode, maps_search_nearby, maps_search_places, maps_place_details, maps_distance_matrix, maps_directions, maps_elevation, maps_timezone, maps_weather, maps_air_quality, maps_static_map, maps_batch_geocode, maps_search_along_route. Composite entries orchestrate several atomic calls behind one name. maps_plan_route is the clearest example: it uses Routes API waypoint optimization for up to 25 stops, which means the ordering decision happens at Google, not in the model's head.

Every tool is annotated with readOnlyHint: true and destructiveHint: false. The README states this lets MCP clients auto-approve them without user confirmation. That is a real convenience and a real design claim: the server asserts that no tool mutates anything. It reads maps data. Nothing here writes to a Google account, so the annotation is defensible, but it also means the client will stop asking before each call, and cost control moves entirely to your Google Cloud quota settings.

Three execution modes share the same tool set. stdio is the default recommendation for desktop clients. Streamable HTTP runs a server on a port and is aimed at multi-session deployments, per-request API key isolation and remote access. The exec CLI runs a single tool from the shell with no server process at all.

## Installing cablate/mcp-google-map and running a first geocode

There is no build step for the common case. The package is published to npm as @cablate/mcp-google-map and the README's quick start invokes it through npx, so nothing is installed globally. Node 18 or newer is required according to the engines field in package.json.

The fastest way to see whether it works is the exec CLI, which skips the MCP server entirely and calls one tool. The README gives this exact invocation:

```bash
npx @cablate/mcp-google-map exec geocode '{"address":"Tokyo Tower"}'
```

You should get coordinates back for the address. If the process exits with an API error instead, the cause is almost always the key or the enabled APIs rather than the CLI, because this path exercises the same Google clients as the server.

For an MCP client, the README's stdio configuration block is the one to copy. It goes in the client's server configuration file:

```json
{
  "mcpServers": {
    "google-maps": {
      "command": "npx",
      "args": ["-y", "@cablate/mcp-google-map", "--stdio"],
      "env": {
        "GOOGLE_MAPS_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}
```

After restarting the client, the eighteen tools should appear in its tool list. If you want fewer, add a second environment variable. The README shows GOOGLE_MAPS_ENABLED_TOOLS taking a comma-separated list, for example maps_geocode,maps_directions,maps_search_places. Omitting it, or setting it to *, registers all eighteen. This is the single most useful knob in the project, because tool definitions occupy model context whether or not they are called.

For an HTTP deployment there is a second path. The README's command is:

```bash
npx @cablate/mcp-google-map --port 3000 --apikey "YOUR_API_KEY"
```

The client then points at http://localhost:3000/mcp using type http. Adding --host 0.0.0.0 binds all interfaces for Docker or LAN access, which is also the point at which the API key stops being a local secret. The repository's Dockerfile exposes port 3020 and runs node dist/cli.js, a different port from the README's 3000 example, so check which one your container actually publishes.

## The Places API (New) and Routes API prerequisite is where setup fails

The README carries one prerequisite line, and it is the one that costs people an afternoon: enable Places API (New) and Routes API in Google Cloud Console before using place-related and routing tools. A Google Maps API key alone is not sufficient. Keys are commonly created with only the legacy Places API or Geocoding API enabled, and the place and routing tools will then fail while geocoding appears to work, which makes the failure look selective rather than configuration-wide.

Two more constraints are visible in the repository. The Dockerfile runs npm install rather than npm ci and copies the whole working tree before building, which is a development-shaped image rather than a minimal production one. And the HTTP mode's --apikey flag puts the key on the command line, where it lands in shell history and in process listings. The README presents HTTP mode as suitable for remote access; nothing in the documentation describes authentication in front of that endpoint, so exposing it beyond localhost is a decision the operator owns.

Cost is the limitation the README does not discuss at all. Eighteen tools against paid Google APIs, with readOnlyHint set so clients auto-approve calls, means an agent in a loop can issue many billable requests without a confirmation prompt. There is no rate limiting, caching or budget guard described anywhere in the documentation. If your agent retries on ambiguous results, that is your Google Cloud bill, and the only lever the project documents is GOOGLE_MAPS_ENABLED_TOOLS.

## Google Grounding Lite versus a self-hosted Maps MCP server

The README's own comparison table sets this project against Google's Grounding Lite MCP support. The difference is not feature parity, it is control. Grounding Lite is Google-managed and, per that table, exposes three tools with weather but no geocoding, no directions, no elevation, no distance matrix, no place details, no timezone, no air quality and no map images. It is also not open source.

cablate/mcp-google-map is MIT-licensed and self-hosted, which is the actual trade. You get eighteen tools and the ability to run the process wherever you want, including inside your own network with your own key. You also inherit the operational work: keeping Node current, rebuilding when Google's client libraries change, and managing the key. Grounding Lite removes that work and removes the tool surface with it.

The honest read of the comparison table is that it is a feature checklist, and feature checklists flatter the project with more tools. The question a reader should ask is whether their workflow needs geocoding, step-by-step directions or elevation at all. A travel-planning agent does. A weather-checking agent does not, and for that case the managed option is less to maintain. The composite tools are the part Google's offering has no answer for, and maps_plan_route's 25-stop waypoint optimization is the most concrete example.

## Maintenance, versioning and the MIT licence

The repository is not archived, and the last push was on 2026-08-16, which is recent enough that the project is under current development. The release cadence is telling: v0.0.53 on 2026-07-08, v0.0.54 on 2026-08-13, v0.0.55 on 2026-08-16. Three releases inside five weeks, all still in the 0.0.x range. The version number is honest about API stability: nothing here promises that a tool name or parameter will survive the next minor bump, and there is no 1.0 to anchor expectations to.

Upgrade cost is low in the common case, because npx pulls the latest published version each time a stdio client starts. That is also a risk. A client configured with npx -y @cablate/mcp-google-map --stdio has no version pin, so an upgrade happens silently on the next launch. Pinning to an exact version in the args array is the obvious mitigation and is not mentioned in the README. For HTTP deployments the running process is whatever you started, so upgrades are manual by construction.

The licence is MIT, which permits commercial use, modification and redistribution with the licence and copyright notice retained. That is a permissive arrangement. It says nothing about Google's terms, and those are separate: your use of the Maps APIs is governed by your Google Cloud agreement, and the MIT grant covers this repository's code only. The repository also carries a SECURITY.md and a SECURITY_ASSESSMENT.md, which is more than most projects at this version number provide.

## Conclusion

Adopt it if you already have a Google Cloud project with Places API (New) and Routes API enabled and you want an agent to call geocoding, routing and place lookup without writing your own wrapper. Skip it if you need a managed endpoint or cannot put a Google Maps API key in the client config. Before wiring it into anything, confirm which of the 18 tools you actually need and set GOOGLE_MAPS_ENABLED_TOOLS accordingly, because 18 tool definitions are registered into the model context by default.

## FAQ

### Does Google have an MCP server for Maps?

The README compares this project against Google's Grounding Lite MCP support, which it lists as exposing 3 tools including weather but no geocoding, directions, elevation, distance matrix, place details, timezone, air quality or map images. cablate/mcp-google-map is a separate, MIT-licensed, self-hosted alternative with 18 tools.

### How do I connect cablate/mcp-google-map to Claude?

Add an entry to the client's mcpServers configuration using command npx with args -y, @cablate/mcp-google-map, --stdio, and set GOOGLE_MAPS_API_KEY in the env block. The README lists Claude Desktop as a supported stdio client, and the 18 tools appear after the client restarts.

### What API key does cablate/mcp-google-map need?

It needs a Google Maps API key, passed as GOOGLE_MAPS_API_KEY in stdio mode or with the --apikey flag in HTTP mode. The README also states you must enable Places API (New) and Routes API in Google Cloud Console before place-related and routing tools will work.

### Can I run cablate/mcp-google-map without an MCP client?

Yes. The exec CLI runs a single tool from the shell with no server process, for example npx @cablate/mcp-google-map exec geocode with a JSON address argument. The README describes this as the Agent Skill path and says all 18 tools are available through it.

### How do I reduce the number of tools cablate/mcp-google-map registers?

Set the GOOGLE_MAPS_ENABLED_TOOLS environment variable to a comma-separated list such as maps_geocode,maps_directions,maps_search_places. Omitting it or setting it to * registers all 18 tools, which is the default.

## Sources

- [cablate/mcp-google-map on GitHub](https://github.com/cablate/mcp-google-map)
- [Issues](https://github.com/cablate/mcp-google-map/issues)
- [License: MIT](https://github.com/cablate/mcp-google-map/blob/main/LICENSE)
- [README](https://github.com/cablate/mcp-google-map/blob/main/README.md)
- [Releases](https://github.com/cablate/mcp-google-map/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cablate-mcp-google-map