Skip to main content
Glama

get_google_search_results

This is a FALLBACK tool — use fast_search first for general web searches. Only use this tool when you need specialized search types that fast_search does not support: news, maps, Google Lens, shopping, image search, or Google AI mode.

Scrape Google search results using ScrapingBee and return the results. This tool can scrape normal results, news results, maps results, search using google lens, shopping related results, image results, and get the result from Google's AI mode. It can even return the HTML along with the search results.

Scope: one query per call. To run many queries in one pass, or to write results to disk instead of into the conversation, use the ScrapingBee CLI — scrapingbee <command> --input-file queries.txt --output-dir results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoResponse-header label only.
nfprNoWhether to disable Google's autocorrection feature or not.
pageNoThe page number to return.
pagesNoNumber of pages to aggregate (max 10, default 1).
deviceNoThe device to use for the search (desktop, mobile).desktop
radiusNoRadius in meters (requires latitude and longitude).
searchYesThe search query to use.
sort_byNoShopping sort order: relevance, reviews, price_asc, price_desc.
add_htmlNoWhether to return the HTML along with the search results.
languageNoThe language to use for the search (Example: en, fr, de, etc.).en
latitudeNoLatitude in decimal degrees for geographic searches.
longitudeNoLongitude in decimal degrees for geographic searches.
max_priceNoShopping maximum price filter.
min_priceNoShopping minimum price filter.
date_rangeNoFilter by date range: past_hour, past_day, past_week, past_month, past_year. Only for classic, news, and images.
search_typeNoThe search type to use (classic: normal results, news: news results [not available if device is mobile], maps: maps results, lens: search using google lens [requires image url as search parameter], shopping: shopping related results, images: image results, ai_mode: get the result from Google's AI mode, ads: paid-ad results).classic
country_codeNoThe country code to use for the search (Example: us, fr, de, etc.).us
extra_paramsNoExtra parameters to pass to the search (Example: tbs=qdr:d&udm=7).
light_requestNoWhether to use a light request or not.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses the scraping dependency (ScrapingBee), the option to return raw HTML, and that scope is one query per call. It does not mention rate limits, auth/API-key needs, pagination behavior, or failure modes for a network-scraping tool.

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?

Fallback routing is front-loaded, then capability and scope follow, which is the right order. It is slightly verbose — the capability sentence largely restates the search_type enum — and the inline CLI example is somewhat tangential, but nothing is wasted outright.

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

Completeness5/5

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

An output schema exists, so return-value explanation is unnecessary, and the description covers the routing decision, capability envelope, and per-call scope. Combined with a 100%-documented 19-param schema, an agent has enough to invoke it correctly; only operational caveats like rate limits are absent.

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% with 19 well-described params, so the schema already explains search types, date_range, geo, and shopping filters. The description reinforces a few of these (search types, one query per call) but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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?

States a specific verb (scrape) and resource (Google search results), plus the range of result types (news, maps, lens, shopping, images, ai_mode) it can produce. It also explicitly positions itself against the sibling fast_search, so an agent can distinguish the two without opening either schema.

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

Usage Guidelines5/5

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

Front-loads the routing rule: try fast_search first, use this only for specialized search types fast_search doesn't support, and lists those types. It also names the ScrapingBee CLI as the alternative for multi-query/batch-to-disk work, covering the when-not case.

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