Skip to main content
Glama

google_search

Destructive

当用户需要通过 Google 搜索公开网页信息、获取通用网页搜索结果,或按国家、语言、位置、设备、时间条件等控制 Google 搜索结果时触发。

Input Schema

NameRequiredDescriptionDefault
qYes定义搜索的查询内容。调用方必须提供非空值,不使用默认值。
crNo定义一个或多个将搜索限制在的国家/地区。它使用 country{两位大写国家/地区代码} 指定国家/地区,并使用 I 作为分隔符。例如 countryFRIcountryDE 将仅搜索法国和德国的页面。
glNo定义 Google 搜索要使用的国家/地区。它是一个两位数的国家/地区代码。例如 us 代表美国,uk 代表英国,fr 代表法国。
hlNo定义 Google 搜索要使用的语言。它是一个两位数的语言代码。例如 en 代表英语,es 代表西班牙语,fr 代表法语。
lrNo定义一个或多个将搜索限制在的语言。它使用 lang_{两位语言代码} 指定语言,并使用 I 作为分隔符。例如 lang_frIlang_de 将仅搜索法语和德语的页面。
tbsNo定义常规查询字段中无法实现的高级搜索参数。例如专利、日期、新闻、视频、图片、应用或文本内容的高级搜索。
jsonNo定义采集结果的输出格式。1 返回 JSON 格式数据,2 返回 JSON+HTML 格式数据,3 返回 HTML 格式数据,4 返回 Light JSON。默认值为 1。1
nfprNo当原始查询拼写错误时,定义是否排除来自自动更正查询的结果。设置为 1 排除这些结果,设置为 0 包含它们(默认)。
safeNo定义成人内容的过滤级别。可以设置为 active 或 off,默认情况下 Google 会模糊处理露骨内容。
uuleNo希望用于搜索的 Google 编码位置。此参数不能与 location、lat、lon 和 radius 参数一起使用。
startNo定义结果偏移量。它跳过指定数量的结果,用于分页。例如 0 默认是第一页结果,10 是第二页结果,20 是第三页结果,以此类推。0
deviceNo定义用于获取结果的设备。可设置为 desktop(默认值)使用常规浏览器,tablet 使用平板浏览器(目前使用 iPad),或 mobile 使用移动浏览器。desktop
filterNo定义“类似结果”和“省略结果”的过滤器是开启还是关闭。设置为 1(默认)启用这些过滤器,设置为 0 禁用这些过滤器。1
locationNo定义搜索发起的地理位置。如果有多个位置与请求的位置匹配,将选择最受欢迎的一个。此参数不能与 uule、lat 和 lon 参数一起使用。
no_cacheNo默认情况下,5 分钟内缓存相同参数的搜索结果。设为 true 可跳过缓存,设为 false(默认)则使用缓存结果。缓存搜索免费,且不计入搜索统计。false
render_jsNo如果为 true,系统将使用浏览器执行页面脚本并返回完整渲染后的 HTML。开启后会显著增加采集耗时,请按需使用。
ai_overviewNo控制是否获取 Google 搜索结果中的 AI 概览(AI Overview)内容。成功获取 AI 概览通常计为 1 次响应;当首次请求仅返回 page_token 时,系统自动进行的第二次请求将额外计费,总共消耗 2 次响应。
google_domainNo定义要使用的 Google 域名。默认为 google.com。google.com

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare the full safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false), yet the description adds no behavioral context of its own: nothing on billing/response consumption, caching, rate limits, or why a search is flagged destructive. Caching and cost details exist only inside individual parameter descriptions, not here.

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 front-loaded sentence with no filler or repetition — the trigger condition comes first and the capability list follows. It is dense but every clause maps to real functionality, so nothing needs cutting.

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, open-world search tool with no output schema, the schema-rich parameters plus annotations cover most invocation needs, but the description says nothing about pagination (start), output-format selection (json), or cost implications, and gives no routing among the large family of sibling search tools.

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% across all 18 parameters, including enums, defaults, and mutually exclusive pairs (uule vs location/lat/lon), so the schema carries the semantics. The description only generically alludes to country/language/location/device/time control and adds no syntax or format detail beyond the schema, which is the baseline-3 case.

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

Purpose3/5

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

The description conveys a search of public web pages via Google, with capability categories (country, language, location, device, time filters), so the resource is identifiable. However it is phrased as a trigger condition rather than a functional statement ('当用户需要...时触发'), and it never distinguishes this from the many sibling search tools (bing_search, duckduckgo_search, yandex_search), leaving the core verb and scope only implied.

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?

It does give a when-to-trigger condition covering general web lookups and filter control, which is a form of usage context. But it offers no when-not-to-use guidance and names no alternative, so an agent gets no help deciding between this, bing_search, or the vertical Google tools (google_news, google_images) for the same query.

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