Summary: This server exposes read-only Google Maps tools for nearby search, place details, geocoding, reverse geocoding, distance matrix, directions, and elevation.
Search nearby places by center point, radius, keyword, open-now, and minimum rating.
Fetch detailed information for a Google Maps place by place ID.
Convert addresses or landmarks into coordinates.
Convert coordinates into addresses.
Calculate distances and travel times between multiple origins and destinations.
Get route directions between two points for driving, walking, bicycling, or transit.
Retrieve elevation data for one or more locations.
Requires Google Cloud Console for API setup and key generation to enable the Google Maps services.
Provides comprehensive Google Maps API integration with location search, place details, geocoding, distance calculation, directions, and elevation data retrieval capabilities.
Serves as the runtime environment for the MCP server, enabling server-side execution of the Google Maps integration.
Provides the package management and distribution mechanism for installing the MCP server.
Used as the programming language for implementing the MCP server functionality.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Google Map Server get directions from Times Square to Central Park"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Stop rebuilding place search, routing, and location workflows for every AI app.
@cablate/mcp-google-map turns Google Maps Platform into 18 read-only agent tools and three focused Skills. An agent can find real places, verify routes, compare options, build practical itineraries, or audit local search visibility—through MCP or a standalone CLI.
You choose the integration model: Codex or Claude Code Plugin when you want Skills without MCP setup, stdio for desktop MCP clients, or Streamable HTTP for shared and remote deployments.
Giving an agent a raw Maps API is only the beginning. Useful answers often require several dependent calls: resolve a place, preserve its identity, search around it, check opening details, calculate travel time, and explain what was actually verified. This project packages that work into one consistent interface.
Move from lookup to outcome. Atomic tools handle geocoding, place details, directions, weather, air quality, and maps. Composite tools explore areas, compare candidates, optimize stops, and measure local rankings.
Use the same capabilities with or without MCP. The standalone exec CLI works with Agent Skills and automation; the MCP server exposes the same 18 tools over stdio or HTTP.
Give agents workflow guidance, not just function names. Three Skills cover general map research, evidence-backed travel planning, and local SEO. Codex loads their full instructions only when a request matches.
Keep deployment and credentials under your control. Run locally or self-host. API keys remain in your environment or request headers, with per-session isolation for HTTP deployments.
Start narrow and grow later. Register only the tools you need with GOOGLE_MAPS_ENABLED_TOOLS, or use the full catalog.
Related MCP server: SearchAPI MCP Server
Outcome | How the project helps |
Find and evaluate real places | Natural-language and nearby search, place details, ratings, hours, reviews, and distance comparison |
Build a trip that works geographically | Candidate discovery, along-route stops, travel-time checks, multi-stop optimization, weather, and static maps |
Research a neighborhood | Multi-category exploration plus targeted distance, elevation, timezone, weather, and air-quality checks |
Plan field work or deliveries | Route matrices and optimized stop ordering for up to 25 stops |
Audit local search visibility | Geographic grid ranking, competitor discovery, ARP, ATRP, and SoLV metrics |
Enrich location data | Single or batch geocoding, reverse geocoding, and structured JSON output |
These are data and planning tools, not guarantees of safety, accessibility, opening status, or ranking outcomes. Applications displaying Places reviews, photos, or AI summaries must follow the content attribution and storage guidance.
Use | Best for | What runs |
Codex Plugin | Asking Codex map, travel, or local SEO questions without MCP configuration | A matching Skill loads on demand and calls the standalone CLI |
Claude Code Plugin | Installing the same three Skills from a Claude marketplace | Skills are namespaced under |
Standalone CLI | Scripts, automation, and other Skill-compatible agents | One stateless command returns JSON |
MCP stdio | Claude Desktop, Cursor, VS Code, and other local MCP clients | The client starts a local MCP process |
Streamable HTTP | Multi-session, containerized, LAN, or remote access | A self-hosted server exposes |
All options require Node.js 18+ and a Google Maps Platform API key. Live calls may be billable. Enable the APIs needed by your selected tools; common place and route workflows require Places API (New), Routes API, and often Geocoding API.
codex plugin marketplace add cablate/mcp-google-map --ref main
codex plugin add mcp-google-map@cablateSet GOOGLE_MAPS_API_KEY in the environment where Codex runs, then start a new conversation. Verify the local setup without making a Google API request:
npx -y @cablate/mcp-google-map doctorSuccess means the node, package, and api-key checks pass and live-api is skipped. Use doctor --live only when you intend to send potentially billable checks to Geocoding, Places, and Routes.
Try asking:
Plan a practical two-day Kyoto itinerary. Group nearby places, check travel times, and explain any opening-hour assumptions.
Codex selects google-maps for general location research, google-maps-travel-planning for itineraries, or google-maps-local-seo for business visibility analysis. The plugin does not register or start an MCP server. See the no-MCP walkthrough for a reproducible example.
claude plugin marketplace add cablate/mcp-google-map
claude plugin install mcp-google-map@cablate-mapsStart a new Claude Code session, set GOOGLE_MAPS_API_KEY in its environment, and run the same doctor check shown above. Claude exposes the installed Skills with the plugin namespace, for example /mcp-google-map:google-maps-travel-planning.
Each GitHub release also includes a versioned mcp-google-map-claude-plugin-v*.zip and SHA-256 checksum for direct distribution. The release workflow builds this archive from the same skills/ source and validates it with Claude Code's official strict validator before publishing.
Every MCP tool also has a short CLI name:
npx -y @cablate/mcp-google-map exec geocode '{"address":"Tokyo Tower"}'
npx -y @cablate/mcp-google-map exec search-places '{"query":"quiet cafes in Kyoto"}'
npx -y @cablate/mcp-google-map exec directions '{"origin":"Tokyo Station","destination":"Tokyo Skytree","mode":"transit"}'Each call is stateless. Successful calls return { "success": true, "data": ... } on stdout; failures exit nonzero and write structured JSON to stderr.
For bulk address enrichment:
npx @cablate/mcp-google-map batch-geocode -i addresses.txt -o results.json
cat addresses.txt | npx @cablate/mcp-google-map batch-geocode -i -{
"mcpServers": {
"google-maps": {
"command": "npx",
"args": ["-y", "@cablate/mcp-google-map", "--stdio"],
"env": { "GOOGLE_MAPS_API_KEY": "YOUR_API_KEY" }
}
}
}To reduce tool-list context, add a comma-separated allowlist such as "GOOGLE_MAPS_ENABLED_TOOLS": "maps_geocode,maps_directions,maps_search_places". Omit it or use * to expose all tools.
npx @cablate/mcp-google-map --host 127.0.0.1 --port 3000 --apikey "YOUR_API_KEY"{
"mcpServers": {
"google-maps": {
"type": "http",
"url": "http://127.0.0.1:3000/mcp"
}
}
}Bind to 0.0.0.0 only when the server must accept external connections. For multi-tenant deployments, prefer the X-Google-Maps-API-Key request header so keys remain isolated by session.
Group | Tools |
Places and discovery |
|
Location and routing |
|
Context and visualization |
|
Local SEO |
|
All 18 tools declare readOnlyHint: true and destructiveHint: false. Exact parameters, response shapes, and workflow recipes live in the tool reference.
The key must belong to a Google Cloud project with billing enabled and restrictions compatible with the runtime. The setup and diagnostics guide maps each capability to its required API and explains common failures.
Credential priority is:
X-Google-Maps-API-Key HTTP request header
--apikey command-line option
GOOGLE_MAPS_API_KEY environment variable
Prefer environment variables or request headers. Command-line secrets can appear in shell history and process listings.
Place and route facts come from the Google Maps Platform APIs enabled for your project; weather availability has regional limitations.
A successful API response does not prove accessibility, safety, legal suitability, or real-time availability.
The package preserves source and disclosure metadata where returned, but your interface remains responsible for compliant attribution and storage.
HTTP mode supports per-session API-key isolation and DNS rebinding protection.
This project is MIT licensed and self-hostable. See SECURITY.md for vulnerability reporting and Security Assessment Clarifications for the review checklist.
git clone https://github.com/cablate/mcp-google-map.git
cd mcp-google-map
npm ci
npm run build
npm run test:unit
npm testLive E2E calls require GOOGLE_MAPS_API_KEY and may be billable: npm run test:e2e.
Contributions are welcome. Read CONTRIBUTING.md before opening a pull request. Release history is in CHANGELOG.md.
Thanks to @junyinnnn for helping add Streamable HTTP support.
獲取特定地點的詳細資訊
| 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.
v1.0.0get_place_detailsmaps_directionsmaps_distance_matrixmaps_elevationmaps_geocodemaps_reverse_geocodesearch_nearbyScored across 7 tools
每個工具都有明確且不同的用途：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…
