Skip to main content
Glama
kevinwuhoo

Google Maps Geocoding MCP Server

by kevinwuhoo
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Google Maps Geocoding MCP Server

NPM Version NPM Downloads License Node.js Version GitHub Stars GitHub Issues

A Model Context Protocol (MCP) server that provides access to Google Maps Geocoding API. This server enables LLM clients like Claude Desktop and Cursor to perform address geocoding, reverse geocoding, and place ID lookups. The aim of this MCP is only the Geocoding API. This is because there isn't great support for connecting to many MCP servers yet in most tools.

Features

  • 🗺️ Forward Geocoding: Convert addresses to coordinates

  • đź“Ť Reverse Geocoding: Convert coordinates to addresses

  • 🏢 Place Geocoding: Convert Google Place IDs to addresses

  • 🌍 Multi-language Support: Get results in different languages

  • 🎯 Advanced Filtering: Filter by result types, location types, and components

  • 🚀 Built on Official SDK: Uses Google's official @googlemaps/google-maps-services-js library will full TypeScript support

Related MCP server: Local Business Data MCP Server

Prerequisites

  1. Google Maps API Key: Get one from the Google Cloud Console

  2. Node.js: Version 18 or higher

  3. Claude Desktop or Cursor (or another MCP-compatible client)

Setup with MCP Clients

Claude Desktop

Edit your Claude Desktop config file:

Platform

Config File Location

macOS

~/Library/Application Support/Claude/claude_desktop_config.json

Windows

%APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "google-maps-geocoding": {
      "command": "npx",
      "args": ["google-maps-geocoding-mcp"],
      "env": {
        "GOOGLE_MAPS_API_KEY": "your_api_key_here"
      }
    }
  }
}

Then restart Claude Desktop and ask Claude to geocode an address!

Cursor

Add to your Cursor settings (Settings → Extensions → MCP Servers):

{
  "mcp.servers": [
    {
      "name": "google-maps-geocoding",
      "command": "npx",
      "args": ["google-maps-geocoding-mcp"],
      "env": {
        "GOOGLE_MAPS_API_KEY": "your_api_key_here"
      }
    }
  ]
}

Test the integration using the AI chat!

Usage Examples

Forward Geocoding (Address → Coordinates)

Ask your AI client:

"Geocode the address '1600 Amphitheatre Parkway, Mountain View, CA'"

Reverse Geocoding (Coordinates → Address)

Ask your AI client:

"What address is at coordinates 37.4224764, -122.0842499?"

Place Geocoding (Place ID → Address)

Ask your AI client:

"Get the address for Google Place ID 'ChIJd8BlQ2BZwokRAFUEcm_qrcA'"

Advanced Usage

With component filtering:

"Find 'Main Street' in San Francisco, CA, US"

With language preferences:

"Geocode 'Champs-Élysées' in French"

With regional biasing:

"Find restaurants near coordinates 37.7749, -122.4194 in the US region"

Common Issues

MCP Server not connecting:

  • Verify Node.js version is 18+

  • Check your MCP client configuration

API key errors:

  • Verify your API key is correct

  • Check that the Geocoding API is enabled in Google Cloud Console

  • Ensure API key restrictions allow your usage

Debug Mode

Enable debug logging by setting:

LOG_LEVEL=debug npx google-maps-geocoding-mcp

Contributing

Contributions are welcome! Please see CONTRIBUTING.md for development setup, guidelines, and how to submit changes.

Available Tools

3 tools
geocode_forwardB

Convert an address to geographic coordinates (latitude/longitude) using Google Maps Geocoding API.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesAddress to geocode. Example: "1600 Amphitheatre Parkway, Mountain View, CA"
componentsNoComponent filtering (optional)
boundsNoViewport bounds for biasing results (optional)
languageNoLanguage for results (e.g., "en", "es")
regionNoRegion bias (e.g., "us", "uk")
result_typeNoFilter by result types (e.g., ["street_address"])
location_typeNoFilter by location precision (e.g., ["ROOFTOP"])

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the external API being used, it doesn't disclose important behavioral traits like rate limits, authentication requirements, error handling, cost implications, or what happens with ambiguous addresses. The description is minimal and lacks operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward geocoding operation and is front-loaded with the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the return values look like (coordinates format, confidence levels, multiple results handling), doesn't mention error cases or limitations, and provides no context about the external API's constraints or behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Convert an address to geographic coordinates') and identifies the exact resource ('using Google Maps Geocoding API'). It distinguishes from sibling tools by specifying forward geocoding (address→coordinates) versus reverse geocoding or place-based geocoding.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (forward geocoding) but doesn't explicitly state when to use this tool versus the sibling tools 'geocode_place' or 'geocode_reverse'. No guidance is provided about alternative approaches or when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

geocode_placeC

Convert a Google Place ID to a human-readable address using Google Maps Geocoding API.

ParametersJSON Schema
NameRequiredDescriptionDefault
place_idYesGoogle Place ID. Example: "ChIJd8BlQ2BZwokRAFUEcm_qrcA"
languageNoLanguage for results (e.g., "en", "es")
regionNoRegion bias (e.g., "us", "uk")
result_typeNoFilter by result types (e.g., ["street_address"])
location_typeNoFilter by location precision (e.g., ["ROOFTOP"])

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the API used but does not cover critical traits such as rate limits, authentication requirements, error handling, or response format. For a tool with no annotations, this leaves significant gaps in understanding its operational behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core purpose and uses clear terminology, making it easy to understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a geocoding tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., API constraints), output format, and differentiation from siblings. While the schema covers parameters well, the overall context for effective tool use is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, meaning all parameters are documented in the input schema with descriptions. The description adds no additional semantic details about parameters beyond what the schema provides, such as examples or usage tips. With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate but also does not detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: converting a Google Place ID to a human-readable address using the Google Maps Geocoding API. It specifies the verb ('Convert'), resource ('Google Place ID'), and target ('human-readable address'), but does not explicitly differentiate from sibling tools like geocode_forward or geocode_reverse, which likely handle different inputs (e.g., addresses or coordinates).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its siblings (geocode_forward and geocode_reverse), nor does it mention any prerequisites, exclusions, or alternative scenarios. It only states what the tool does without contextual usage information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

geocode_reverseB

Convert geographic coordinates (latitude/longitude) to a human-readable address using Google Maps Geocoding API.

ParametersJSON Schema
NameRequiredDescriptionDefault
latlngYesLatitude,longitude coordinates. Example: "40.714224,-73.961452"
languageNoLanguage for results (e.g., "en", "es")
regionNoRegion bias (e.g., "us", "uk")
result_typeNoFilter by result types (e.g., ["street_address"])
location_typeNoFilter by location precision (e.g., ["ROOFTOP"])

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the external API but does not disclose behavioral traits such as rate limits, authentication needs, error handling, or response format. This leaves significant gaps for a tool interacting with an external service.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and uses clear, direct language without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of an external API tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., rate limits, errors) and output format, which are critical for proper tool invocation and integration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Convert geographic coordinates to a human-readable address'), identifies the resource ('using Google Maps Geocoding API'), and distinguishes from siblings by specifying reverse geocoding (vs. forward geocoding or place geocoding).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (when coordinates need conversion to addresses) but does not explicitly state when to use this tool versus alternatives like 'geocode_forward' or 'geocode_place'. It lacks explicit guidance on exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: geocode_forward handles addresses to coordinates, geocode_place converts Place IDs to addresses, and geocode_reverse does coordinates to addresses. There is no overlap or ambiguity between these three operations.

Naming Consistency5/5

All tool names follow a consistent 'geocode_' prefix with descriptive suffixes (forward, place, reverse), using snake_case uniformly. This pattern is predictable and enhances readability.

Tool Count5/5

With 3 tools, the server is well-scoped for geocoding operations, covering the essential forward, reverse, and Place ID conversions. Each tool earns its place without being excessive or insufficient for the domain.

Completeness5/5

The tool set provides complete coverage for the Google Maps Geocoding domain, including forward geocoding, reverse geocoding, and Place ID resolution. There are no obvious gaps, as these are the core operations offered by the API.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kevinwuhoo/google-maps-geocoding-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server