Skip to main content
Glama

google_maps

Destructive

当用户需要查询 Google Maps 地点、商家、本地位置、地图搜索结果,或基于经纬度、地点 ID、CID、地图缩放范围获取地图数据时触发。

Input Schema

NameRequiredDescriptionDefault
mNo定义以米为单位的地图高度。最小值为 1,最大值为 15028132,大致相当于赤道上的 3z。最终会被编码为 ll 参数的一部分。使用 location 或 lat/lon 参数时,必须指定 m 或 z。
qYes定义想要搜索的查询内容。调用方必须提供非空值,不使用默认值。
zNo定义地图缩放级别。最小值为 3(地图完全缩小),最大有效值取决于位置,范围从 18 到 23。使用 location 或 lat/lon 参数时,必须指定 z 或 m。
glNo定义 Google 地图搜索要使用的国家/地区。它是一个两位数的国家/地区代码。例如 us 代表美国,uk 代表英国,fr 代表法国。
hlNo定义 Google 地图搜索要使用的语言。它是一个两位数的语言代码。例如 en 代表英语,es 代表西班牙语,fr 代表法语。
llNo定义搜索起点的 GPS 坐标。其值必须符合 @ + 纬度 + , + 经度 + , + 缩放级别/地图高度格式,例如 @40.7455096,-74.0083012,14z 或 @43.8521864,11.2168835,10410m。此参数不能与 location、lat、lon、z 或 m 参数一起使用。
latNo定义搜索起点的 GPS 纬度,最终会被编码为 ll 参数的一部分。使用 lon 参数时必须同时提供此参数。此参数应与 z 或 m 参数一起使用,不能与 ll 或 location 参数一起使用。
lonNo定义搜索起点的 GPS 经度,最终会被编码为 ll 参数的一部分。使用 lat 参数时必须同时提供此参数。此参数应与 z 或 m 参数一起使用,不能与 ll 或 location 参数一起使用。
dataNo此参数已弃用,请改用 place_id 或 data_cid。该参数可用于过滤搜索结果。
jsonNo定义采集结果的输出格式。1 返回 JSON 格式数据,2 返回 JSON+HTML 格式数据,3 返回 HTML 格式数据,4 返回 Light JSON。默认值为 1。1
typeNo定义要执行的搜索类型。search 返回 q 参数列出的结果列表;place 在设置 data 参数时返回特定地点结果。使用 place_id 或 data_cid 时不需要此参数。
startNo定义结果偏移量。它跳过指定数量的结果,用于分页。例如 0 默认是第一页结果,20 是第二页结果,40 是第三页结果,依此类推。0
nearbyNo强制返回更接近指定位置的搜索结果。当 q 参数包含 near me 关键词时,强烈建议使用此参数;当 q 参数包含地点时,不建议使用。此参数应与 ll、location 或 lat/lon 参数一起使用。可设置为 true 或 false。
data_cidNo定义地点的 Google CID(客户标识符)。data_cid 和 place_id 不能同时使用。
locationNo定义地点,其 GPS 坐标用作搜索起点,最终会被编码为 ll 参数的一部分。此参数应与 z 或 m 参数一起使用,不能与 ll、lat 或 lon 参数一起使用。
no_cacheNo默认情况下,5 分钟内缓存相同参数的搜索结果。设为 true 可跳过缓存,设为 false(默认)则使用缓存结果。缓存搜索免费,且不计入搜索统计。false
place_idNo定义 Google 地图中地点的唯一引用。地点 ID 可用于大多数地点,包括企业、地标、公园和交叉路口。
google_domainNo定义要使用的 Google 域名。默认为 google.com。google.com

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3/5.0
Behavior1/5

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

Annotations declare readOnlyHint=false and destructiveHint=true, i.e. a state-mutating, destructive operation, while the description frames the tool purely as a retrieval/query ('查询', '获取地图数据'). The description adds no behavioral context (cost, quotas, caching, side effects) and its read framing opposes the destructive annotation, so this is an annotation contradiction.

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

Conciseness4/5

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

A single sentence with no filler, front-loaded as a trigger condition, which is the right shape for a dispatch-style description. It is a somewhat long enumeration of trigger keywords, but nothing is redundant.

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

Completeness3/5

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

For an 18-parameter tool with no output schema and heavy parameter interdependencies, a trigger-only description leaves the agent with the schema as its sole guide. The schema is complete so the call itself is executable, but the description contributes nothing about scope boundaries, output shape or the free-vs-billed cache behaviour that matters operationally.

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% — all 18 parameters, including the ll/lat/lon/location/z/m interplay, enums and defaults, are fully documented in the schema. The description only alludes to lat/lon, place ID, CID and zoom without adding any format or constraint detail beyond the schema, so the baseline 3 applies.

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?

States a clear verb+resource: '查询 Google Maps 地点、商家、本地位置、地图搜索结果' and retrieval by lat/lon, place ID, CID, zoom range. This distinguishes it from bing_maps and the generic search siblings, but it does not differentiate it from Google-Maps-adjacent siblings like google_local, google_map_details and google_map_comment, whose scope it overlaps almost entirely.

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 whole description is a trigger clause ('当用户需要...时触发'), which gives implicit usage context but no explicit when-to-use vs when-not-to-use and names no alternative tool. An agent must still guess whether google_local or google_map_details is the better pick for a 'local places' request.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources