18 tools — 14 atomic + 4 composite (explore-area, plan-route, compare-places, local-rank-tracker)
3 modes — stdio, StreamableHTTP, standalone exec CLI
Agent Skill — built-in skill definition teaches AI how to chain geo tools (skills/google-maps/)
This project | ||
Tools | 18 | 3 |
Geocoding | Yes | No |
Step-by-step directions | Yes | No |
Elevation | Yes | No |
Distance matrix | Yes | No |
Place details | Yes | No |
Timezone | Yes | No |
Weather | Yes | Yes |
Air quality | Yes | No |
Map images | Yes | No |
Composite tools (explore, plan, compare) | Yes | No |
Open source | MIT | No |
Self-hosted | Yes | Google-managed only |
Agent Skill | Yes | No |
# stdio (Claude Desktop, Cursor, etc.)
npx @cablate/mcp-google-map --stdio
# exec CLI — no server needed
npx @cablate/mcp-google-map exec geocode '{"address":"Tokyo Tower"}'
# HTTP server
npx @cablate/mcp-google-map --port 3000 --apikey "YOUR_API_KEY"Special thanks to @junyinnnn for helping add support for streamablehttp.
Related MCP server: SearchAPI MCP Server
Tool | Description |
| Find places near a location by type (restaurant, cafe, hotel, etc.). Supports filtering by radius, rating, and open status. |
| Free-text place search (e.g., "sushi restaurants in Tokyo"). Supports location bias, rating, open-now filters. |
| Get full details for a place by its place_id — reviews, phone, website, hours. Optional |
| Convert an address or landmark name into GPS coordinates. |
| Convert GPS coordinates into a street address. |
| Calculate travel distances and times between multiple origins and destinations. |
| Get step-by-step navigation between two points with route details. |
| Get elevation (meters above sea level) for geographic coordinates. |
| Get timezone ID, name, UTC/DST offsets, and local time for coordinates. |
| Get current weather conditions or forecast — temperature, humidity, wind, UV, precipitation. |
| Get air quality index, pollutant concentrations, and health recommendations by demographic group. |
| Generate a map image with markers, paths, or routes — returned inline for the user to see directly. |
| Geocode up to 50 addresses in one call — returns coordinates for each. |
| Search for places along a route between two points — ranked by minimal detour time. |
Composite Tools | |
| Explore what's around a location — searches multiple place types and gets details in one call. |
| Plan an optimized multi-stop route — uses Routes API waypoint optimization (up to 25 stops) for efficient ordering. |
| Compare places side-by-side — searches, gets details, and optionally calculates distances. |
| Track a business's local search ranking across a geographic grid — like LocalFalcon. Supports up to 3 keywords for batch scanning. Returns rank at each point, top-3 competitors, and metrics (ARP, ATRP, SoLV). |
All tools are annotated with readOnlyHint: true and destructiveHint: false — MCP clients can auto-approve these without user confirmation.
Prerequisite: Enable Places API (New) and Routes API in Google Cloud Console before using place-related and routing tools.
Works with Claude Desktop, Cursor, VS Code, and any MCP client that supports stdio:
{
"mcpServers": {
"google-maps": {
"command": "npx",
"args": ["-y", "@cablate/mcp-google-map", "--stdio"],
"env": {
"GOOGLE_MAPS_API_KEY": "YOUR_API_KEY"
}
}
}
}Reduce context usage — If you only need a subset of tools, set GOOGLE_MAPS_ENABLED_TOOLS to limit which tools are registered:
{
"env": {
"GOOGLE_MAPS_API_KEY": "YOUR_API_KEY",
"GOOGLE_MAPS_ENABLED_TOOLS": "maps_geocode,maps_directions,maps_search_places"
}
}Omit or set to * for all 18 tools (default).
For multi-session deployments, per-request API key isolation, or remote access:
npx @cablate/mcp-google-map --port 3000 --apikey "YOUR_API_KEY"
# Bind to all interfaces for remote access (e.g. Docker, LAN)
npx @cablate/mcp-google-map --host 0.0.0.0 --port 3000 --apikey "YOUR_API_KEY"Then configure your MCP client:
{
"mcpServers": {
"google-maps": {
"type": "http",
"url": "http://localhost:3000/mcp"
}
}
}Transport: stdio (--stdio) or Streamable HTTP (default)
Tools: 18 Google Maps tools (14 atomic + 4 composite) — filterable via GOOGLE_MAPS_ENABLED_TOOLS
Use tools directly without running the MCP server:
npx @cablate/mcp-google-map exec geocode '{"address":"Tokyo Tower"}'
npx @cablate/mcp-google-map exec search-places '{"query":"ramen in Tokyo"}'All 18 tools available: geocode, reverse-geocode, search-nearby, search-places, place-details, directions, distance-matrix, elevation, timezone, weather, air-quality, static-map, batch-geocode-tool, search-along-route, explore-area, plan-route, compare-places, local-rank-tracker. See skills/google-maps/ for the agent skill definition and full parameter docs.
Geocode hundreds of addresses from a file:
npx @cablate/mcp-google-map batch-geocode -i addresses.txt -o results.json
cat addresses.txt | npx @cablate/mcp-google-map batch-geocode -i -Input: one address per line. Output: JSON with { total, succeeded, failed, results[] }. Default concurrency: 20 parallel requests.
API keys can be provided in three ways (priority order):
HTTP Headers (Highest priority)
{
"mcp-google-map": {
"transport": "streamableHttp",
"url": "http://localhost:3000/mcp",
"headers": {
"X-Google-Maps-API-Key": "YOUR_API_KEY"
}
}
}Command Line
mcp-google-map --apikey YOUR_API_KEYEnvironment Variable (.env file or command line)
GOOGLE_MAPS_API_KEY=your_api_key_here
MCP_SERVER_PORT=3000
MCP_SERVER_HOST=0.0.0.0# Clone the repository
git clone https://github.com/cablate/mcp-google-map.git
cd mcp-google-map
# Install dependencies
npm install
# Set up environment variables
cp .env.example .env
# Edit .env with your API key
# Build the project
npm run build
# Start the server
npm start
# Or run in development mode
npm run dev# Run smoke tests (no API key required for basic tests)
npm test
# Run full E2E tests (requires GOOGLE_MAPS_API_KEY)
npm run test:e2esrc/
├── cli.ts # CLI entry point
├── config.ts # Tool registration and server config
├── index.ts # Package exports
├── core/
│ └── BaseMcpServer.ts # MCP server with streamable HTTP transport
├── services/
│ ├── NewPlacesService.ts # Google Places API (New) client
│ ├── PlacesSearcher.ts # Service facade layer
│ ├── RoutesService.ts # Google Routes API client (directions, distance matrix, waypoint optimization)
│ └── toolclass.ts # Google Maps API client (geocoding, timezone, elevation, static map)
├── tools/
│ └── maps/
│ ├── searchNearby.ts # maps_search_nearby tool
│ ├── searchPlaces.ts # maps_search_places tool
│ ├── placeDetails.ts # maps_place_details tool
│ ├── geocode.ts # maps_geocode tool
│ ├── reverseGeocode.ts # maps_reverse_geocode tool
│ ├── distanceMatrix.ts # maps_distance_matrix tool
│ ├── directions.ts # maps_directions tool
│ ├── elevation.ts # maps_elevation tool
│ ├── timezone.ts # maps_timezone tool
│ ├── weather.ts # maps_weather tool
│ ├── airQuality.ts # maps_air_quality tool
│ ├── staticMap.ts # maps_static_map tool
│ ├── batchGeocode.ts # maps_batch_geocode tool
│ ├── searchAlongRoute.ts # maps_search_along_route tool
│ ├── exploreArea.ts # maps_explore_area (composite)
│ ├── planRoute.ts # maps_plan_route (composite)
│ ├── comparePlaces.ts # maps_compare_places (composite)
│ └── localRankTracker.ts # maps_local_rank_tracker (composite)
└── utils/
├── apiKeyManager.ts # API key management
└── requestContext.ts # Per-request context (API key isolation)
tests/
└── smoke.test.ts # Smoke + E2E test suite
skills/
├── google-maps/ # Agent Skill — how to USE the tools
│ ├── SKILL.md # Tool map, recipes, invocation
│ └── references/
│ ├── tools-api.md # Tool parameters + scenario recipes
│ ├── travel-planning.md # Travel planning methodology
│ └── local-seo.md # Local SEO / Google Business Profile ranking analysis
└── project-docs/ # Project Skill — how to DEVELOP/MAINTAIN
├── SKILL.md # Architecture overview + onboarding
└── references/
├── architecture.md # System design, code map, 9-file checklist
├── google-maps-api-guide.md # API endpoints, pricing, gotchas
├── geo-domain-knowledge.md # GIS fundamentals, Japan context
└── decisions.md # 10 ADRs (design decisions + rationale)TypeScript - Type-safe development
Node.js - Runtime environment
@googlemaps/places - Google Places API (New) for place search and details
Google Routes API - Directions, distance matrix, and waypoint optimization via REST
@googlemaps/google-maps-services-js - Geocoding, timezone, elevation
@modelcontextprotocol/sdk - MCP protocol implementation (v1.27+)
Express.js - HTTP server framework
Zod - Schema validation
API keys are handled server-side
Per-session API key isolation for multi-tenant deployments
DNS rebinding protection available for production
Input validation using Zod schemas
For enterprise security reviews, see Security Assessment Clarifications — a 23-item checklist covering licensing, data protection, credential management, tool contamination, and AI agent execution environment verification.
To report a vulnerability, see SECURITY.md.
Tool / Feature | What it unlocks | Status |
| Map images with pins/routes — multimodal AI can "see" the map | Done |
| AQI, pollutants — health-aware travel, outdoor planning | Done |
| Geocode up to 50 addresses in one call — data enrichment | Done |
| Find places along a route ranked by detour time — trip planning | Done |
| One-call neighborhood overview (composite) | Done |
| Optimized multi-stop itinerary (composite) | Done |
| Side-by-side place comparison (composite) | Done |
| Geographic grid rank tracking — local SEO analysis (composite) | Done |
| Filter tools to reduce context usage | Done |
Feature | What it unlocks | Status |
| Place photos for multimodal AI — "see" the restaurant ambiance | Planned |
Language parameter | Multi-language responses (ISO 639-1) across all tools | Planned |
MCP Prompt Templates |
| Planned |
Geo-Reasoning Benchmark | 10-scenario test suite measuring LLM geospatial reasoning accuracy | Research |
These are the real-world scenarios driving our tool decisions:
Travel planning — "Plan a day trip in Tokyo" (geocode → search → directions → weather)
Real estate analysis — "Analyze this neighborhood: schools, commute, flood risk" (search-nearby × N + elevation + distance-matrix)
Logistics optimization — "Route these 12 deliveries efficiently from the warehouse" (plan-route)
Field sales — "Visit 6 clients in Chicago, minimize drive time, find lunch spots" (plan-route + search-nearby)
Disaster response — "Nearest open hospitals? Am I in a flood zone?" (search-nearby + elevation)
Content creation — "Top 5 neighborhoods in Austin with restaurant density and airport distance" (explore-area + distance-matrix)
Accessibility — "Wheelchair-accessible restaurants, avoid steep routes" (search-nearby + place-details + elevation)
Local SEO — "Audit my restaurant's ranking vs competitors within 1km" (search-places + compare-places + explore-area)
See CHANGELOG.md for version history.
MIT
Community participation and contributions are welcome! Please read CONTRIBUTING.md for development setup, coding guidelines, and the pull request process.
Submit Issues: Report bugs or provide suggestions
Create Pull Requests: Submit code improvements
Documentation: Help improve documentation
Email: reahtuoo310109@gmail.com
GitHub: CabLate
獲取特定地點的詳細資訊
| Name | Required | Description | Default |
|---|---|---|---|
| placeId | Yes | Google Maps 地點 ID |
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. While '獲取' implies a read-only operation, the description doesn't specify authentication requirements, rate limits, error conditions, or what constitutes '詳細資訊' (detailed information) in the response. This leaves significant gaps for a tool that likely interacts with external APIs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any redundant information. It's appropriately front-loaded with the core functionality and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 '詳細資訊' includes (e.g., address, coordinates, ratings), potential authentication needs, or error handling. Given the likely complexity of interacting with Google Maps APIs and the lack of structured output documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'placeId' clearly documented as 'Google Maps 地點 ID'. The description doesn't add any additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('獲取' meaning 'get/fetch') and the resource ('特定地點的詳細資訊' meaning 'specific place's detailed information'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling tools like 'search_nearby' or 'maps_geocode', which might also provide place information in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. With sibling tools like 'search_nearby' and 'maps_geocode' available, there's no indication of whether this tool is for looking up known place IDs versus searching by name or coordinates, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
獲取兩點之間的路線指引
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | 終點地址或座標 | |
| mode | No | 交通模式 | driving |
| origin | Yes | 起點地址或座標 |
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. It states what the tool does but doesn't describe how it behaves: no information about rate limits, authentication needs, response format, error conditions, or whether this is a read-only operation. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's zero wasted language, and it's front-loaded with the core functionality. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a route planning tool with 3 parameters and no output schema, the description is incomplete. It doesn't explain what the tool returns (route steps, duration, distance, etc.), doesn't mention common use cases or limitations, and provides no behavioral context. With no annotations and no output schema, users must guess about the tool's behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain format expectations, coordinate systems, or provide 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '獲取兩點之間的路線指引' (get route directions between two points), which specifies the verb (get) and resource (route directions). It distinguishes from siblings like maps_distance_matrix (distance calculations) and maps_geocode (address conversion), but doesn't explicitly differentiate from potential route-planning alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives like maps_distance_matrix (for distance/time only) or search_nearby (for points of interest). It doesn't mention prerequisites, limitations, or typical use cases beyond the basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
計算多個起點和終點之間的距離和時間
| Name | Required | Description | Default |
|---|---|---|---|
| destinations | Yes | 終點地址或座標列表 | |
| mode | No | 交通模式 | driving |
| origins | Yes | 起點地址或座標列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose rate limits, authentication requirements, cost implications, error conditions, or output format. For a tool that likely calls an external API with potential usage constraints, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it easy to parse and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 insufficient. It doesn't explain what the output looks like (matrix format? units?), doesn't mention API limitations or costs, and doesn't provide context about when this tool is preferable to sibling tools. The 100% schema coverage helps, but the description should do more heavy lifting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it just restates the core functionality without explaining parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as calculating distances and times between multiple origins and destinations, which is specific (verb+resource). However, it doesn't distinguish this from sibling tools like maps_directions, which might provide similar routing functionality but with different output formats or use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives like maps_directions or search_nearby. It doesn't mention prerequisites, typical use cases, or limitations, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
獲取位置的海拔數據
| Name | Required | Description | Default |
|---|---|---|---|
| locations | Yes | 要獲取海拔數據的位置列表 |
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 '獲取' (get/retrieve) implies a read operation, the description doesn't address important behavioral aspects like rate limits, authentication requirements, data freshness, accuracy, or what happens with invalid coordinates. For a tool with zero annotation coverage, this represents significant gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase that directly states the tool's purpose without any unnecessary words. It's front-loaded with the essential information and contains zero wasted content. Every word earns its place in communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficiently complete. For a tool that presumably returns elevation data, the description doesn't indicate what format the elevation data comes in (meters/feet, precision), whether it returns single values or arrays, or what happens with multiple locations. The lack of behavioral context combined with no output information creates significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'locations' well-documented in the schema as an array of latitude/longitude objects. The description mentions '位置' (locations) which aligns with the parameter name but adds no additional semantic context beyond what the schema already provides. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '獲取位置的海拔數據' clearly states the tool's purpose: retrieving elevation data for locations. It uses a specific verb ('獲取' - get/retrieve) and identifies the resource ('海拔數據' - elevation data). However, it doesn't differentiate from sibling tools like 'maps_geocode' or 'maps_reverse_geocode' which handle different geographic data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. There are multiple sibling mapping tools (geocode, reverse geocode, directions, etc.), but the description doesn't indicate that this tool specifically handles elevation data rather than other geographic information. No explicit when/when-not instructions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
將地址轉換為座標
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | 要轉換的地址或地標名稱 |
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 only states the basic function without mentioning any behavioral traits such as rate limits, accuracy considerations, error handling, authentication needs, or output format. For a geocoding tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose. There is no wasted language or unnecessary elaboration, making it efficient and easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a geocoding tool. It doesn't explain what the coordinates output looks like (e.g., latitude/longitude format), potential limitations, or how it integrates with sibling tools. The minimal description fails to provide sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'address' fully documented in the schema as '要轉換的地址或地標名稱' (address or landmark name to convert). The description adds no additional semantic information beyond what the schema provides, such as examples or formatting tips. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 addresses to coordinates. It specifies the verb '轉換為' (convert to) and the resource '地址' (address), making the function unambiguous. However, it doesn't explicitly differentiate from its sibling 'maps_reverse_geocode', which performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. It doesn't mention the sibling tools like 'maps_reverse_geocode' for the opposite conversion, 'search_nearby' for location-based searches, or other mapping tools. There's no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
將座標轉換為地址
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | 緯度 | |
| longitude | Yes | 經度 |
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. While '將座標轉換為地址' implies a read-only lookup operation, it doesn't disclose any behavioral traits such as rate limits, authentication requirements, error conditions, or what happens with invalid coordinates. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with a single sentence that directly states the tool's function. There is zero wasted language, and every word earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., address format, possible fields), error handling, or any behavioral context. For a tool with 2 parameters and no structured output documentation, the description should provide more contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('latitude' and 'longitude') clearly documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides (e.g., coordinate formats, valid ranges, or examples). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 coordinates to an address. It uses a specific verb ('轉換為' meaning 'convert to') and identifies the resource (coordinates to address). However, it doesn't differentiate from sibling tools like 'maps_geocode' which likely performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. It doesn't mention sibling tools like 'maps_geocode' (likely address to coordinates), 'get_place_details', or 'search_nearby', nor does it specify any prerequisites, constraints, or appropriate contexts for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋附近的地點
| Name | Required | Description | Default |
|---|---|---|---|
| center | Yes | 搜尋中心點 | |
| keyword | No | 搜尋關鍵字（例如：餐廳、咖啡廳） | |
| minRating | No | 最低評分要求（0-5） | |
| openNow | No | 是否只顯示營業中的地點 | |
| radius | No | 搜尋半徑（公尺） |
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 only states the action ('搜尋附近的地點') without mentioning permissions, rate limits, pagination, or what the search returns (e.g., list of places with details). For a search tool with 5 parameters and no output schema, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('搜尋附近的地點') that is front-loaded and wastes no words. However, it's overly concise to the point of under-specification, missing context that would help the agent. It earns a 4 for brevity but loses points for not being sufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what the tool returns, how results are filtered or sorted, or error conditions. For a search tool with rich input options, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 5 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain how 'center' interacts with 'radius' or typical use cases for 'keyword'). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '搜尋附近的地點' (Search for nearby places) states the general purpose but lacks specificity. It mentions the verb '搜尋' (search) and resource '地點' (places), but doesn't distinguish from siblings like 'maps_geocode' or 'get_place_details' which also involve location-related operations. The purpose is clear but not differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or exclusions. Given siblings like 'maps_geocode' (for address conversion) and 'get_place_details' (for specific place info), the lack of usage guidelines leaves the agent uncertain about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_place_detailsmaps_directionsmaps_distance_matrixmaps_elevationmaps_geocodemaps_reverse_geocodesearch_nearby每個工具都有明確且不同的用途：get_place_details 用於地點詳細資訊，maps_directions 用於路線指引，maps_distance_matrix 用於距離計算，maps_elevation 用於海拔數據，maps_geocode 用於地址轉座標，maps_reverse_geocode 用於座標轉地址，search_nearby 用於搜尋附近地點。這些工具之間沒有重疊或混淆的風險，因為每個都針對 Google Maps API 的特定功能。
工具命名整體上一致，使用 snake_case 格式和描述性名稱，如 maps_directions、maps_geocode 等，但 get_place_details 和 search_nearby 沒有前綴 'maps_'，這是一個小偏差。儘管如此，命名模式仍然清晰可讀，沒有混用不同風格。
7 個工具對於 Google Maps 伺服器的範圍來說非常合適。它涵蓋了核心功能，如地理編碼、路線規劃、距離計算和地點搜尋，沒有過多或過少的工具。每個工具都有其存在的價值，符合典型的 3-15 個工具的範圍。
工具集完整覆蓋了 Google Maps API 的關鍵操作，包括地理編碼（正向和反向）、路線指引、距離矩陣、海拔數據、地點詳細資訊和附近搜尋。沒有明顯的缺口，代理可以處理從地址轉換到路線規劃的完整工作流程，沒有死胡同。
The Google Maps MCP server is a fully-managed server provided by the Maps Grounding Lite API that connects AI applications to Google Maps Platform services. It provides three main tools for building LLM applications: searching for places, looking up weather information, and computing routes with details like distance and travel time. The server acts as a proxy that translates Google Maps data into a format that AI applications can understand, enabling agents to accurately answer real-world location and travel queries.
Live Google Maps business search, review, and photo data for AI agents over MCP.
Google Maps MCP Pack — geocoding, places, directions, distance matrix, elevation.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cablate/mcp-google-map'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
