Skip to main content
Glama
esinecan

google-search-mcp

by esinecan

google_search

Search Google and get ad-free structured results with filters for site, filetype, date, exact phrase, and more; optionally fetch page content as markdown.

Instructions

Search Google. Ads stripped; results are {rank, title, url, host, snippet, date}.

Use the structured arguments rather than typing operators into query -- they assemble the correct syntax for you:

site='arxiv.org' restrict to one domain filetype='pdf' only PDFs exact='model context protocol' quoted phrase, must appear verbatim exclude=['tutorial'] drop results containing a term after='2026-01-01' published after a date (before= for the other bound) freshness='week' hour | day | week | month | year verbatim=True no synonyms or stemming; the words as typed strict_dates=True apply before/after as Tools > Custom range instead of as query operators (index date rather than document date) country='de', lang='de' region and language bias personalized=False the neutral view, no account history applied

vertical selects which Google tab to read:

web the default SERP, including rich blocks web_only the "Web" tab -- plain links, no rich blocks. Cleanest for research; measured 17 external anchors against 56 on the default SERP. news news, with dates videos video results short_videos the shorts feed books Google Books (results are google-hosted by nature) images the image grid; single page, title comes from alt text

date is populated where Google shows one ("2 days ago", "28 Jul 2026") and is null otherwise. total_matches is Google's own estimate for the whole query, not the number returned.

with_content=True also READS the top content_top_n results and attaches each as markdown on result.content, saving a fetch round trip per link. It goes through the same logged-in browser, so it reads JS-rendered pages and soft paywalls that a plain HTTP fetch cannot. Costs a real page load each -- budget a few seconds per result, and raise content_chars (default 2000) only when you actually need the whole article. A page that could not be read sets content: null and content_error.

pages is 10 results each, max 5, and each page is a separate round trip -- ask for depth only when you actually need it. Ignored for images.

On failure the result carries a kind field: auth_expired (sign in), schema_drift (the extractor is stale, do not retry), rate_limited (back off). An empty result set is NOT an error -- it returns count=0 with no kind, and means Google matched nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNo
siteNo
afterNo
exactNo
pagesNo
queryYes
beforeNo
countryNo
excludeNo
filetypeNo
verbatimNo
verticalNoweb
freshnessNo
personalizedNo
strict_datesNo
with_contentNo
content_charsNo
content_top_nNo
Behavior5/5

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

With no annotations, the description bears the full burden and excels. It discloses failure kinds (auth_expired, schema_drift, rate_limited), cost of with_content (page loads), behavior of strict_dates vs query operators, empty result sets not being errors, and the neutral view for personalized=False. This is exceptionally transparent.

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

Conciseness5/5

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

The description is long but deliberately organized: opening summary, argument examples with syntax hints, vertical list, and performance/failure notes. Each paragraph and bullet earns its place; nothing is redundant. The most important facts (what it does, return shape) are front-loaded.

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?

For a tool with 18 parameters, no output schema, and no annotations, this description is remarkably complete. It covers output fields, pagination, date behavior, error kinds, cost/performance trade-offs, and even distinguishes total_matches from returned count. There is no significant missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain all 18 parameters—and it does. It provides examples for site, filetype, exact, exclude, before/after, freshness, verbatim, strict_dates, country, lang, personalized, and details each vertical value. It also explains pages, content_chars, and content_top_n with caveats. This fully compensates for the bare schema.

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?

The description opens with a specific verb ('Search Google'), names the resource, and states the output format ('results are {rank, title, url, host, snippet, date}'). It also notes ads are stripped, clearly distinguishing it from sibling tools like google_multi_search or google_fetch. This is a model of purpose clarity.

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

Usage Guidelines4/5

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

The description gives abundant usage context: structured arguments instead of operators, recommended 'web_only' for research, 'ask for depth only when you actually need it', and budget warnings for with_content. However, it never explicitly contrasts with sibling tools (e.g., when to use google_multi_search instead), so it stops short of full exclusion guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/esinecan/google-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server