Google Researcher MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v6.3.3
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.
Average 4.7/5 across 8 of 8 tools scored. Lowest: 4.1/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![google-researcher-mcp MCP server](https://glama.ai/mcp/servers/zoharbabin/google-researcher-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zoharbabin/google-researcher-mcp)

Score Badge

Copy to your README.md:

[![google-researcher-mcp MCP server](https://glama.ai/mcp/servers/zoharbabin/google-researcher-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zoharbabin/google-researcher-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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