A
licenseB
qualityD
maintenanceAn automated research agent that leverages Google Gemini models and Google Search to perform deep, multi-step web research, generating sophisticated queries and producing citation-rich answers.
1
28
MIT
Google Researcher MCP
by zoharbabin
This server provides a comprehensive suite of web research tools combining Google-powered search, content extraction, and specialized discovery capabilities.
Web Search: Search the web via Google Custom Search API, returning URLs, titles, and snippets. Supports filtering by country, language, time range, exact phrases, site restrictions, and safe search.
Page Scraping: Extract text from any URL — including static and JavaScript-rendered pages, YouTube videos (via transcripts), and documents (PDF, DOCX, PPTX). Includes a preview mode to inspect page structure before full retrieval.
Search & Scrape Combined: Perform a Google search and automatically retrieve content from top results in a single call, returning deduplicated, combined content with source attribution — ideal for multi-source research.
Image Search: Find images with filters for size, type (photo, clipart, face, lineart, animated), color type, dominant color, and file format.
News Search: Discover recent news articles with freshness filters (hour/day/week/month/year), sorting by relevance or date, and optional restriction to a specific news source domain.
Academic Paper Search: Search peer-reviewed papers from arXiv, PubMed, IEEE, Nature, Springer, and more. Returns abstracts, authors, publication years, PDF links, and pre-formatted citations (APA, MLA, BibTeX).
Patent Search: Research patents via Google Patents with filters for assignee, inventor, CPC code, patent office (USPTO, EPO, WIPO, etc.), and date range. Supports prior art discovery and technology landscape analysis.
Sequential Research Tracking: Manage complex, multi-step research sessions across multiple API calls, supporting branching paths, knowledge gap identification, revision of earlier steps, and session persistence.
Provides academic paper search capabilities through the arXiv repository, enabling AI assistants to find research papers with citation formats (APA, MLA, BibTeX), abstracts, and PDF links.
Enables web search capabilities via Google Custom Search API, providing general web search with site, date, and language filtering for research and information gathering.
Provides news search functionality through Google News, allowing AI assistants to find current news articles with freshness controls and date sorting.
Enables academic paper search through IEEE repositories, providing access to peer-reviewed technical papers and research publications.
Provides biomedical and life sciences paper search capabilities through PubMed, enabling access to medical research articles and scientific publications.
Enables academic paper search through Springer repositories, providing access to scientific and technical research publications.
Provides automatic transcript extraction from YouTube videos, enabling AI assistants to access and analyze video content through text transcripts.
google-researcher-mcp — DEPRECATED
⚠️ This project has been superseded by
web-researcher-mcp.A complete rewrite in Go: same tools, but it cites real sources and stays honest — citation verification, retraction flagging, eight search providers behind one interface, and a single signed static binary. No Node.js, no npm.
Migrate in one line
Your API keys and tool calls don't change — only how the server is launched. Pick whichever you prefer (no Node required):
# macOS / Linux — installs the binary and registers it with Claude Code automatically:
curl -fsSL https://raw.githubusercontent.com/zoharbabin/web-researcher-mcp/main/install.sh | sh
# Windows (PowerShell):
powershell -ExecutionPolicy Bypass -c "irm https://raw.githubusercontent.com/zoharbabin/web-researcher-mcp/main/install.ps1 | iex"
# Python users (uv) — run with no install:
uvx web-researcher-mcpBefore / after (MCP client config)
The config keeps the same shape — swap the command/args, keep your env:
// BEFORE — google-researcher-mcp (npx / Node)
{
"mcpServers": {
"google-researcher": {
"command": "npx",
"args": ["-y", "google-researcher-mcp"],
"env": { "GOOGLE_CUSTOM_SEARCH_API_KEY": "…", "GOOGLE_CUSTOM_SEARCH_ID": "…" }
}
}
}
// AFTER — web-researcher-mcp (installed binary; or use "uvx" + args ["web-researcher-mcp"])
{
"mcpServers": {
"web-researcher": {
"command": "web-researcher-mcp",
"env": { "GOOGLE_CUSTOM_SEARCH_API_KEY": "…", "GOOGLE_CUSTOM_SEARCH_ID": "…" }
}
}
}Don't run both at once — they register identical tool names. Remove the
google-researcherentry before addingweb-researcher.
Your existing GOOGLE_CUSTOM_SEARCH_API_KEY and GOOGLE_CUSTOM_SEARCH_ID work unchanged.
Related MCP server: Web Research Assistant
Why the Rewrite?
Open Issue | Resolution in web-researcher-mcp |
#108 — Orphan detection fails via npx | Go binary has native process lifecycle (EOF/SIGPIPE) — no npm wrapper |
#107 — Google discontinuing 'entire web' search | Eight providers (Brave, Serper, SearXNG, SearchAPI, Tavily, Exa, DuckDuckGo + Google PSE for lenses) with automatic fallback |
#55 — Support alternative search engines | Multiple engines behind one interface, plus a zero-config DuckDuckGo default |
#72 — Add Redis caching | Hybrid cache: memory + AES-encrypted disk + optional Redis |
#40 — Split server.ts into modules | Fully modular Go architecture (one package per concern) |
Plus what's new: verify_citation and audit_bibliography (catch fabricated/retracted citations), academic / patent / SEC-filing / US-case-law / economic / clinical-trial search, and authority-weighted search lenses.
Links
New project: https://github.com/zoharbabin/web-researcher-mcp
Install (all methods): README → Get started
Docker:
docker pull zoharbabin/web-researcher-mcp:latestReleases: https://github.com/zoharbabin/web-researcher-mcp/releases
Available Tools
8 toolsacademic_searchAcademic Paper SearchARead-only
Search academic papers using Google Custom Search API.
When to use:
Finding peer-reviewed, authoritative sources
Research requiring citations and references
Technical/scientific topics and literature reviews
Features:
Paper titles, authors, abstracts
Publication years and venues
Direct PDF links (when available)
Pre-formatted citations (APA, MLA, BibTeX)
Academic sources: arXiv, PubMed, IEEE, Nature, Springer, ResearchGate, JSTOR, and more.
Caching: Results cached for 30 minutes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for academic papers | |
| num_results | No | Number of papers to return (1-10, default: 5) | |
| year_from | No | Only include papers published in or after this year | |
| year_to | No | Only include papers published in or before this year | |
| source | No | Limit search to specific academic source (default: all sources) | all |
| pdf_only | No | Only return results with PDF links | |
| sort_by | No | Sort by relevance or publication date (most recent first) | relevance |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| papers | Yes | List of academic papers |
| query | Yes | The search query that was executed |
| totalResults | Yes | Total papers matching query |
| resultCount | Yes | Number of papers returned |
| source | Yes | Data source |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds valuable context: caching for 30 minutes, list of academic sources, and features like citations and PDF links, which go beyond annotations without contradicting them.
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?
The description is well-structured with clear headings (When to use, Features, etc.) and is concise at around 80 words, covering key points without verbosity. Slightly more could be trimmed, but it's effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers use cases, features, sources, and caching; with an output schema present, it does not need to detail return values. It is complete for a search tool of moderate complexity.
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?
Since input schema provides 100% description coverage for all 7 parameters, the description adds no further parameter details. Baseline 3 is appropriate as the schema already explains each parameter well.
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 clearly states it searches academic papers using Google Custom Search API. It distinguishes itself from siblings like google_search and patent_search by specifying academic sources and use cases, making the purpose unambiguous.
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 'When to use' section explicitly lists appropriate contexts like peer-reviewed research and literature reviews. However, it does not specify when not to use this tool or suggest alternatives among siblings, so it lacks full guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_image_searchGoogle Image SearchARead-only
Search for images using Google Custom Search API. Returns image URLs, thumbnails, dimensions, and source page URLs.
When to use:
Finding visual content — photos, illustrations, graphics, diagrams
Need specific image formats, sizes, or color types
Key parameters:
size: huge, large, medium, small
type: clipart, face, lineart, photo, animated
color_type: color, gray, mono, trans (transparent)
file_type: jpg, gif, png, svg, webp
Caching: Results cached for 30 minutes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The image search query | |
| num_results | No | Number of image results to return | |
| size | No | Filter by image size | |
| type | No | Filter by image type | |
| color_type | No | Filter by color type | |
| dominant_color | No | Filter by dominant color | |
| file_type | No | Filter by file format | |
| safe | No | Safe search level |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| images | Yes | List of image results |
| query | Yes | The search query that was executed |
| resultCount | Yes | Number of images found |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds behavioral details: results are cached for 30 minutes and it uses the Google Custom Search API, which is consistent and adds value beyond annotations.
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 concise, with clear sections (purpose, when to use, key parameters, caching). Every sentence adds value, and the structure is front-loaded with essential information.
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?
Given the complexity (8 parameters, high schema coverage, output schema exists, annotations present), the description is complete. It covers API, filtering options, and caching, leaving no obvious gaps for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description goes further by summarizing key parameters (size, type, color_type, file_type) with their enum values, making it easier for an agent to understand relevant filters at a glance.
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 clearly states it searches for images using Google Custom Search API and specifies what it returns (image URLs, thumbnails, dimensions, source page URLs). It effectively distinguishes this from sibling tools like google_search (general web search) and google_news_search (news).
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 includes a 'When to use' section listing use cases like finding visual content and needing specific formats/sizes/colors. While it implies alternatives by context, it does not explicitly name sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_news_searchGoogle News SearchARead-only
Search for recent news articles with freshness filters and date sorting.
When to use:
Current events, breaking news, time-sensitive topics
Need headlines and snippets from news sources
Want to restrict by publication date
When to use scrape_page instead:
You need the full article content
Key parameters:
freshness: hour, day, week, month, year (default: week)
sort_by: relevance or date
news_source: Restrict to specific domain (e.g., 'bbc.com')
Caching: Results cached for 30 minutes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The news search query | |
| num_results | No | Number of news results to return | |
| freshness | No | How recent the news should be | week |
| sort_by | No | Sort order: by relevance or by date (most recent first) | relevance |
| news_source | No | Restrict to a specific news source domain |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| articles | Yes | List of news articles |
| query | Yes | The search query that was executed |
| resultCount | Yes | Number of articles found |
| freshness | Yes | Freshness filter that was applied |
| sortedBy | Yes | Sort order used |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds caching (30 min) and implies results are headlines/snippets, but could mention output format or rate limits.
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?
Well-structured with headings and bullet points, front-loaded with purpose, no wasted sentences.
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?
Given output schema exists, description is complete: covers purpose, usage guidelines, key parameters, and caching. No gaps for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters with descriptions (100% coverage). Description adds value by listing key params with defaults and usage hints, exceeding baseline 3.
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?
Description clearly states the tool searches for recent news articles with freshness and date sorting, distinguishing it from siblings like general web search or image search.
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?
Explicitly provides when-to-use (current events, breaking news) and when-to-use-alternative (scrape_page for full article), plus caching info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_searchGoogle SearchARead-only
Search the web using Google Custom Search API. Returns a list of URLs with titles and snippets.
When to use:
You need URLs to process yourself (e.g., selective scraping)
You only need links without full content
You want to filter/choose which URLs to scrape
When to use search_and_scrape instead:
You need actual page content for research
You want content from multiple sources combined
Caching: Results cached for 30 minutes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query string. Use natural language or specific keywords for better results. More specific queries yield better results and more relevant sources. | |
| num_results | No | Number of search results to return (1-10). Higher numbers increase processing time and API costs. Use 3-5 for quick research, 8-10 for comprehensive coverage. | |
| time_range | No | Restrict results to a recent time range. 'day' = last 24 hours, 'week' = last 7 days, 'month' = last 30 days, 'year' = last 365 days. Omit for no time restriction. | |
| site_search | No | Limit results to a specific site (e.g., 'github.com', 'stackoverflow.com'). Useful for domain-specific research. | |
| site_search_filter | No | Whether to include or exclude results from site_search. 'include' (default) shows only results from the site, 'exclude' removes results from the site. | |
| exact_terms | No | Required exact phrase that must appear in all results. Useful for finding specific quotes or technical terms. | |
| exclude_terms | No | Terms to exclude from search results. Useful for filtering out irrelevant topics. Separate multiple terms with spaces. | |
| language | No | Restrict results to a specific language. Format: 'lang_XX' where XX is ISO 639-1 code (e.g., 'lang_en' for English, 'lang_es' for Spanish, 'lang_fr' for French). | |
| country | No | Restrict results to a specific country. Format: 'countryXX' where XX is ISO 3166-1 alpha-2 code (e.g., 'countryUS' for United States, 'countryGB' for United Kingdom). | |
| safe | No | Safe search filtering level. 'off' = no filtering, 'medium' = moderate filtering, 'high' = strict filtering. Defaults to Google's account settings if omitted. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| urls | Yes | List of URLs returned by the search |
| query | Yes | The search query that was executed |
| resultCount | Yes | Number of URLs found |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true (variable results). The description adds value by specifying that results are cached for 30 minutes and that only URLs/titles/snippets are returned, not full content. This complements the annotations without contradiction.
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 concise and well-structured, starting with a clear action statement, followed by bullet-point lists for usage guidance, and a brief caching note. Every sentence serves a purpose, and the formatting is optimized for AI readability.
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?
Given the complexity (10 parameters, sibling tools, output schema present), the description covers purpose, usage guidelines, caching behavior, and explicit alternative tool identification. It leverages the output schema to avoid redundant return value explanations, making it complete for informed tool selection.
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?
The input schema covers all 10 parameters with detailed descriptions (100% coverage). The tool description does not add any additional parameter-specific information beyond what the schema provides. With full schema coverage, a baseline score of 3 is appropriate.
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 clearly states the action ('Search the web using Google Custom Search API') and return format ('list of URLs with titles and snippets'). It distinguishes the tool from its sibling 'search_and_scrape' by specifying when to use each, making the purpose unambiguous.
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?
The description includes explicit 'When to use' and 'When to use search_and_scrape instead' sections, providing clear guidance on when to select this tool over its primary alternative. Caching behavior is also noted, offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
patent_searchPatent SearchARead-only
Search patents using Google Custom Search API (site:patents.google.com).
When to use:
Prior art search before filing
Freedom to operate (FTO) analysis
Patent landscaping and competitive intelligence
Tracking innovation in specific domains
Features:
Patent titles, numbers, abstracts
Inventors and assignees
Filing and publication dates
Direct links to Google Patents and PDFs
Filter by patent office (USPTO, EPO, WIPO, JPO, CNIPA, KIPO)
Assignee search with automatic name variations
Important limitation: Google Custom Search doesn't index ALL patents. For comprehensive company patent research:
Use this tool for initial discovery with technology keywords
Use scrape_page on patents.google.com/?assignee=CompanyName for more complete results
Try multiple variations: company names without spaces, previous names, inventor names
Note that patents may be assigned to parent companies or subsidiaries
Search types:
prior_art: Find related existing patents
specific: Look up specific patent(s)
landscape: Broad overview of a technology area
Caching: Results cached for 30 minutes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Patent search query (keywords, patent number, inventor, assignee). TIP: Try company name WITHOUT spaces (e.g., "raptmedia" instead of "Rapt Media") and try previous company names. | |
| num_results | No | Number of patents to return (1-10, default: 5) | |
| search_type | No | Search type: prior_art (find related patents), specific (exact patent), landscape (broad overview) | prior_art |
| patent_office | No | Filter by patent office (US=USPTO, EP=EPO, WO=WIPO, JP=JPO, CN=CNIPA, KR=KIPO) | |
| assignee | No | Company name to search for. Automatically tries variations (with/without spaces, Inc/Corp). For better results, also try previous company names in the query. | |
| inventor | No | Inventor name to search for (exact phrase match) | |
| cpc_code | No | CPC classification code to search for (e.g., G06F, H04L) | |
| year_from | No | Filter patents from this year onwards | |
| year_to | No | Filter patents up to this year |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| patents | Yes | List of patent results |
| query | Yes | The search query that was executed |
| totalResults | Yes | Total patents matching query |
| resultCount | Yes | Number of patents returned |
| searchType | Yes | Type of patent search |
| source | Yes | Data source |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context beyond that, such as 30-minute caching, incomplete indexing of Google Custom Search, and automatic assignee name variations, which helps the agent understand the tool's behavior and limitations.
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 well-structured with clearly separated sections (When to use, Features, Limitation, Search types, Caching). It is concise yet comprehensive, with every section adding unique value. No unnecessary repetition or vague statements.
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?
Given the tool's complexity (9 parameters, 1 required), 100% schema coverage, presence of output schema, and the detailed description covering limitations and advanced usage scenarios, the definition is complete. The agent has all necessary information to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 9 parameters. The description further enriches parameter meaning with tips (e.g., company name without spaces, previous names), search type definitions, and assignee auto-variations. While the schema already documents parameters, the description adds contextual guidance that improves agent understanding.
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 clearly states it searches patents using Google Custom Search API, with specific use cases and search types. It distinguishes itself from sibling tools like google_search and scrape_page by focusing exclusively on patent data and providing patent-specific features and limitations.
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?
The description explicitly lists when to use (prior art, FTO, landscaping) and provides important limitations and alternative tools (scrape_page for comprehensive company research). It also includes caching information and tips for better results, guiding the agent on effective usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrape_pageScrape Page (+ YouTube, PDF, DOCX, PPTX)ARead-only
Extract text content from a URL. Automatically handles: web pages (static + JavaScript-rendered), YouTube videos (extracts transcript), and documents (PDF, DOCX, PPTX).
When to use:
You already have a specific URL to extract content from
Need content from YouTube videos, PDFs, or Office documents
Want to check page structure before fetching full content (preview mode)
When to use search_and_scrape instead:
Researching a topic across multiple sources
Content size control:
max_length: Limit response size (default: server max of 50KB)
mode: 'full' returns content, 'preview' returns metadata + structure only
Preview mode benefits:
Check content size before fetching full content
Get page structure (headings) to decide which sections to read
Avoid context exhaustion with very large pages
Caching: Results cached for 1 hour.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to scrape. Supports: web pages (static HTML and JavaScript-rendered SPAs), YouTube videos (extracts transcript automatically), and documents (PDF, DOCX, PPTX - extracts text content). | |
| max_length | No | Maximum content length in characters. Content exceeding this will be truncated at natural breakpoints. Default: server max (50KB). | |
| mode | No | 'full' returns content (default), 'preview' returns metadata and structure without full content. | full |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | The URL that was scraped |
| content | Yes | The extracted text content from the page |
| contentType | Yes | The type of content that was extracted |
| contentLength | Yes | Length of the extracted content in characters |
| truncated | Yes | Whether the content was truncated due to size limits |
| estimatedTokens | Yes | Estimated token count (~4 chars/token) |
| sizeCategory | Yes | Size category based on content length |
| originalLength | No | Original content length before truncation |
| metadata | No | Additional metadata for documents |
| citation | No | Citation information with metadata and formatted strings |
| preview | No | Content preview with structure (when mode=preview) |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses caching (1 hour), preview vs full mode behavior, and automatic handling of JS-rendered pages. Contradicts no annotations; adds context beyond readOnly and openWorld hints.
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?
Well-structured with clear sections, front-loaded purpose, and no fluff. Every sentence adds value.
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?
Given complexity (multiple content types, modes, caching) and presence of output schema, the description covers all needed aspects for correct tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds useful details like default max_length (50KB) and preview mode benefits, slightly exceeding the baseline.
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 clearly states the tool extracts text content from URLs and lists supported types (web pages, YouTube, PDF, DOCX, PPTX). It distinguishes from siblings like search_and_scrape by focusing on single URL extraction.
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?
Explicitly provides when to use (specific URL, YouTube/documents, preview) and when not (use search_and_scrape for multi-source research). This helps the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_and_scrapeSearch and ScrapeARead-only
Search Google AND retrieve content from top results in one call. Returns combined, deduplicated content with source attribution.
When to use:
Primary tool for answering questions that need web research
Need content from multiple sources combined
More efficient than calling google_search + scrape_page separately
When to use other tools instead:
google_search: When you only need URLs without content
scrape_page: When you already have a specific URL
Content size control:
max_length_per_source: Limit content per source (default: 50KB)
total_max_length: Limit total combined content (default: 300KB)
filter_by_query: Only include paragraphs containing query keywords
Caching: Search results cached for 30 minutes, scraped pages for 1 hour.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Your research question or topic. Be specific for better results. Example: 'Python async best practices 2024' rather than just 'Python'. | |
| num_results | No | Number of sources to fetch (1-10). Default 3 is good for most queries. Use 5-8 for comprehensive research, 1-2 for quick factual lookups. | |
| include_sources | No | Include source URLs at the end for citation. Default true - recommended for transparency. | |
| deduplicate | No | Remove duplicate content across sources. Default true - recommended to reduce noise when sources quote each other. | |
| max_length_per_source | No | Maximum content length per source in characters. Default: 50KB. | |
| total_max_length | No | Maximum total combined content length. Default: 300KB. | |
| filter_by_query | No | Filter to only include paragraphs containing query keywords. Reduces noise but may exclude relevant context. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | The search query that was executed |
| sources | Yes | List of sources that were processed |
| combinedContent | Yes | Combined and optionally deduplicated content from all sources |
| summary | Yes | Summary statistics for the operation |
| sizeMetadata | Yes | Size information for the combined content |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark readOnlyHint and openWorldHint; description adds: combined deduplicated content with attribution, caching (30min search, 1hr scraped), content size limits. No contradiction.
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?
Well-structured with markdown sections (When to use, alternatives, content control, caching). Every sentence is informative, no redundancy.
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?
Given 7 parameters, 100% schema coverage, and output schema, description covers all key aspects: purpose, usage, parameters, caching, and behavior. Complete for effective agent use.
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 100% with detailed descriptions. Description adds default values, usage examples, and behavioral context for each parameter, exceeding baseline.
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?
Clearly states it searches Google and retrieves content from top results. Distinguished from siblings: google_search (URLs only) and scrape_page (specific URL).
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?
Explicitly provides when to use (web research, multiple sources, efficiency) and when to use alternatives (only URLs, specific URL). Includes content size control and caching guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sequential_searchSequential SearchA
Track multi-step research progress across multiple API calls.
When to use:
Complex investigations requiring 3+ searches with different angles
Research you might abandon early (tracks partial progress)
Investigations where you need to show reasoning steps
Research with branching paths to explore alternatives
When to use search_and_scrape instead:
Simple queries that need content from multiple sources in one call
Key principle: You do the reasoning; this tool tracks state. It persists across API calls so you can build on previous steps.
Example flow:
Start: sequential_search(searchStep: "Starting research on X", stepNumber: 1, nextStepNeeded: true)
Search: search_and_scrape("topic")
Record: sequential_search(searchStep: "Found Y, need Z", stepNumber: 2, source: {...}, nextStepNeeded: true)
Complete: sequential_search(searchStep: "Research complete", stepNumber: 3, nextStepNeeded: false)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| searchStep | Yes | Description of what you searched or found in this step | |
| stepNumber | Yes | Current step number (starts at 1) | |
| totalStepsEstimate | No | Estimated total steps needed (can be adjusted as you go) | |
| nextStepNeeded | Yes | Set to true if more research steps are needed, false when done | |
| source | No | Source found in this step (if any) | |
| knowledgeGap | No | Knowledge gap identified - what information is still missing | |
| isRevision | No | Set to true if this step revises previous thinking | |
| revisesStep | No | Step number being revised (required if isRevision is true) | |
| branchFromStep | No | Step number to branch from (for exploring alternatives) | |
| branchId | No | Identifier for this branch of research | |
| sessionId | No | Session ID to continue (optional - uses current session if omitted) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| sessionId | Yes | Unique session identifier |
| currentStep | Yes | Current step number |
| totalStepsEstimate | Yes | Estimated total steps |
| isComplete | Yes | Whether research is marked as complete |
| sourceCount | Yes | Number of sources collected so far |
| openGapsCount | Yes | Number of unresolved knowledge gaps |
| stateSummary | Yes | Human-readable summary of research state |
| sources | No | All sources collected (included when complete) |
| gaps | No | All knowledge gaps (included when complete) |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool tracks state across API calls and provides an example flow. Annotations are minimal (readOnlyHint false), but the description adds context about persistence and step-by-step progress. It does not mention potential side effects like data retention limits, but overall it is sufficiently 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 well-structured with sections (When to use, When not to use, Key principle, Example flow). Every sentence provides value and it is front-loaded with the main purpose. No unnecessary words.
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?
Given the tool's complexity (11 parameters, nested objects, output schema), the description covers all necessary aspects: workflow, usage rules, parameter roles via example, and persistence. The output schema exists, so return values are documented elsewhere. The description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already explains parameters. The description adds value through the example flow and key principle, showing how parameters like searchStep and stepNumber are used in sequence, which helps the agent understand the tool's usage pattern.
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 starts with 'Track multi-step research progress across multiple API calls' which clearly states the tool's verb and resource. It differentiates from sibling tools like search_and_scrape by specifying when to use each.
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?
The description explicitly lists when to use (complex investigations, 3+ searches, early abandonment, branching) and when to use an alternative (search_and_scrape for simple queries). This provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
8 tool updates
v6.3.1- First observed
academic_search - First observed
google_image_search - First observed
google_news_search - First observed
google_search - First observed
patent_search - First observed
scrape_page - First observed
search_and_scrape - First observed
sequential_search
TDQS
A4.6/5.0
Disambiguation5/5
Each tool targets a distinct type of content or action: academic papers, images, news, general web, patents, page scraping, combined search+scrape, and progress tracking. Their purposes are clearly differentiated by name and description, leaving little ambiguity.
Naming Consistency4/5
Most tools follow a descriptive pattern (e.g., academic_search, google_news_search, patent_search), but there are minor inconsistencies: scrape_page and search_and_scrape break the 'type_search' pattern, and sequential_search uses an adjective. Overall, names are clear and mostly consistent.
Tool Count5/5
With 8 tools, the server is well-scoped for a research assistant. It covers essential search types and content extraction without being overwhelming. Each tool adds distinct value, and the count feels appropriate for the domain.
Completeness5/5
The tool set covers the major facets of web research: various search verticals (web, academic, news, images, patents), page scraping, combined search+scrape, and even a research progress tracker. There are no obvious gaps; it provides a comprehensive workflow.
Maintenance
ActivityInactive
ResponsivenessSyncing
Related MCP Connectors
Web research for agents: quality-scored Google search, webpage extraction, and deep research.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
8-tool AI web intelligence suite: search, scrape, screenshot, SEO, docs, crypto, code.
- VibeSEOOAuthdev.vibeseo
SEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
Related MCP Servers
- AlicenseAqualityBmaintenanceComprehensive web research toolkit with 13 tools for searching (via SearXNG), crawling, package discovery, GitHub metrics, error translation, API documentation lookup, data extraction, technology comparison, and service status checking.149MIT
- FlicenseAqualityNot gradedmaintenanceEnables AI assistants to perform comprehensive research by searching Google, mining Reddit discussions, scraping web content with JS rendering, and synthesizing findings with citations into structured context.51653-
- AlicenseAqualityCmaintenanceEnables AI assistants to perform comprehensive web research through tiered search, secure URL fetching with markdown conversion, and automated multi-source synthesis pipelines. Provides read-only tools with configurable caching, SSRF protection, and optional LLM-powered summarization for search results and content analysis.81MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/zoharbabin/google-researcher-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server