google-research-mcp

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation3/5
Most tools are distinct, but google_search and web_search both provide simple search with subtle differences, and deep_search vs google_research overlap as deep research options. Descriptions help, but an agent might struggle to choose between them.
Naming Consistency3/5
All names are snake_case, but the pattern mixes noun-first names (google_search, web_search, research_session, deep_search) with verb-first names (fetch_page, add_source, get_citations, run_subagent, evaluate_coverage). This is readable but not fully consistent.
Tool Count5/5
With 11 tools covering search, full-content extraction, multi-agent research, session management, citations, and subagent coordination, the count is well-scoped for the server's purpose and each tool generally has a place.
Completeness5/5
The tool set covers the entire research workflow: simple search, deep search, news search, URL fetching, session lifecycle, source addition, citation generation, subagent execution, and coverage evaluation. No critical gaps are apparent.
Average 3.8/5 across 11 of 11 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but does not. It fails to mention side effects (e.g., whether the source is permanently added), prerequisites (e.g., session must exist), or failure behavior if content cannot be fetched. The word 'Add' implies mutation, but no further detail is provided.
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 a single concise sentence that is front-loaded with the core purpose. It is appropriately sized for the information it conveys, though it could be slightly more detailed without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It does not explain return values, error conditions, or the expected workflow, leaving the agent without enough context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries full responsibility for explaining parameters. It mentions none of the four parameters (sessionId, url, title, fetchContent) and adds no semantic meaning beyond what the schema fields already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Add a source to a research session') and specifies the resource ('source', 'research session'). It is obvious from the name and description that this is distinct from sibling search/fetch tools, though it does not explicitly name alternatives.
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?
The phrase 'after fetching its content' implies a workflow sequence, suggesting the tool should be used after fetching a page. However, there is no explicit guidance on when to use this tool over alternatives like fetch_page or research_session, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing side effects, read-only nature, or output. It only restates the purpose without mentioning whether it modifies session state or what it returns, leaving significant behavioral ambiguity.
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?
Two concise sentences, each earning its place. The first states the core purpose, the second provides architectural context, with no extraneous information.
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 a single-parameter tool, the description is minimally adequate, but it lacks clarity on expected output (e.g., a decision, gap list) and does not explain how it relates to steps like research_session or deep_search. Given no output schema, more detail would improve completeness.
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 coverage is 100% and the only parameter (sessionId) is described as 'Research session ID'. The description adds no additional parameter context, so it falls at the baseline of 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?
The description clearly states the tool evaluates current research coverage and identifies gaps, with a specific verb and resource. The reference to the 'More research needed?' decision point further clarifies its purpose and distinguishes it from search/fetch siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The reference to the decision point is the only implicit hint, but there is no mention of prerequisites, exclusions, or alternative tools to consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions supported formats but fails to describe what happens if the session is invalid, whether it's a read-only operation, or the output structure. The lack of side-effect or error information leaves significant gaps.
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 two concise sentences. The first states the purpose, the second lists supported formats. No unnecessary words or repetition, and it is front-loaded with the core function.
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?
The tool is relatively simple, but the description omits details about the dependency on an existing research session and the exact behavior of the output (beyond 'citations'). With no output schema, more return-value context would be helpful. However, the core function is covered.
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 0%, so the description must compensate. It does help by listing the three formats, which map exactly to the enum values for the 'format' parameter. It also provides context for 'sessionId' by referencing 'research session', but does not elaborate on what constitutes a valid session or the required nature of the ID.
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's function: getting formatted citations from a research session, with specific format options. This is a specific verb+resource+context that distinguishes it from sibling search tools.
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?
The phrase 'from a research session' implies it should be used when you have an existing session, but there is no explicit guidance on when to use it versus alternatives like add_source or research_session. No when-not-to-use or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the burden of disclosing behavior. It explains that it uses Readability-style extraction and removes navigation/ads, which is helpful. However, it does not disclose the return format, failure modes (e.g., invalid URL, non-accessible pages), or any rate limiting.
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 two sentences, front-loaded with the core purpose, and the second sentence adds valuable detail about extraction behavior without unnecessary fluff.
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 a simple fetch tool, the description covers the main behavior but leaves gaps. There is no output schema, so the agent is left unsure whether the response is plain text, structured, or includes metadata. It also does not mention pagination or handling of very long pages beyond the max_length parameter.
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% since both parameters (url and max_length) have clear schema descriptions. The description adds context about extraction semantics but does not go beyond the schema for parameter meaning or usage details.
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 uses a specific verb and resource: 'Fetch and extract the full readable content from a single URL.' It clearly distinguishes itself from sibling search and research tools by focusing on a provided URL rather than discovery or aggregation.
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?
The description implies usage for a known single URL, but it does not explicitly state when to prefer this over alternatives like web_search or deep_search, nor does it mention any prerequisites or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It explains the purpose of each action (create/status/complete) and mentions outputs like session progress, coverage, and final reports. However, it does not disclose side effects, reversibility, or prerequisites beyond the schema, leaving gaps in what happens when each action is invoked.
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 with a one-line overview and a bulleted action list. Every sentence and bullet earns its place, with no redundancy or fluff.
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 a multi-action session management tool with no annotations or output schema, the description covers the three core actions but omits workflow sequencing (e.g., must create before status/complete), depth semantics, and session lifecycle behavior. It provides a basic understanding but is incomplete for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters (topic and sessionId have descriptions), but the description does not add meaning for the 'depth' parameter at all and only implicitly uses 'sessionId' via the action descriptions. It fails to compensate for the missing schema coverage and adds minimal value beyond parameter names.
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 uses a specific verb+resource ('Create or manage a research session') and lists three actions, clearly distinguishing this session management tool from sibling search and fetch tools. It is specific about the resource and its purpose.
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 phrase 'for multi-step research workflows' provides clear context for when to use the tool, implying it is intended for complex research tasks rather than simple searches. However, it does not explicitly state when not to use it or mention alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool fetches full article content and returns consolidated results, which is useful. However, it does not mention potential limitations such as rate limits, freshness of results, failure modes, or how content is sourced, leaving some behavioral ambiguity.
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 a concise two-sentence statement that front-loads the action and key differentiators. Every sentence earns its place, with no redundant or filler text.
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?
Given the tool's complexity (3 params, no output schema, no annotations), the description is adequate but leaves room for detail. It explains the core behavior but does not specify the return format of the 'consolidated results', the time window for 'recent', or any edge-case behavior, making it only partially complete for an agent to fully anticipate the tool's output.
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 schema already provides 100% coverage for all three parameters with clear descriptions. The description adds no parameter-specific details beyond mentioning 'recent news' and 'full article content', which indirectly map to 'query' and 'max_content_per_page'. Since the schema is comprehensive, 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 specifies a verb ('searches') and a resource ('news articles'), and further details that it fetches full article content and returns consolidated results. It explicitly distinguishes itself from siblings like google_search and deep_search by focusing on 'recent news' and 'current events', making its 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 phrase 'Optimized for news and current events' provides clear context for when to use this tool, implying it is preferred over generic search tools for news queries. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of the full 'when/when-not' guidance.
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?
With no annotations, the description bears the full burden of behavioral disclosure. It enumerates the five-step subagent workflow (query generation, web searches, content fetching, evaluation, returning results), which meaningfully explains the tool's internal behavior beyond simple 'runs a subagent.' However, it omits side effects, authorization needs, 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?
The description is succinct and well-structured: an opening statement of purpose, a clarifying benefit, and a numbered list of steps. Every sentence/carry contributes value, with no redundancy or filler.
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?
For a tool with no output schema and no annotations, the description covers the tool's operation thoroughly enough for an agent to understand when and how to invoke it. It explains the subagent's process, but does not specify the format of the returned results or whether the tool has side effects on the session, leaving some uncertainty for a complex orchestration tool.
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 schema already provides descriptions for sessionId and aspect (67% coverage), and the description adds no additional parameter semantics. The undocumented max_content_per_page parameter is left unexplained in the description, but its default, min, and max constraints in the schema provide partial meaning. No compensation for that gap is offered.
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 uses a specific verb–resource pair: 'spawn and run a subagent' for 'a specific research aspect,' clearly stating the tool's function. This distinguishes it from sibling tools like google_search or fetch_page, which directly perform searches/fetches rather than orchestrating a multi-step research subagent.
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?
The description implies usage when fine-grained manual control over the multi-agent research process is needed, but it does not explicitly state when not to use it or identify alternative tools. It offers context but no concrete exclusions or comparisons to siblings.
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?
With no annotations, the description carries the transparency burden. It discloses the source quality scoring feature and explicitly notes that full page content is not provided, which sets accurate expectations for the agent.
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 two sentences long and front-loads the primary function. Every word serves a purpose, making it highly concise and well-structured.
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 a tool with no output schema and no annotations, the description provides the core capability but does not detail the expected return structure or result format. It covers the main use and a follow-up, but additional detail on what the results contain would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameters. It does not mention 'query' or 'maxResults' or any parameter-specific guidance. The parameter names are self-explanatory, but the description adds no additional meaning.
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 searches the web and adds the distinguishing feature of source quality scoring. This separates it from siblings like google_search and deep_search. The follow-up note also reinforces that this is for search results, not full content.
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 explicit guidance for a follow-up scenario: when full page content is needed, use fetch_page or deep_search. This establishes the tool's scope, though it doesn't mention when not to use google_search or other alternatives.
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?
With no annotations, the description carries the load and discloses key behaviors: queries Google, uses Readability, includes retry logic, supports multiple search types, and returns full content. It lacks details on rate limits or auth but is still strongly transparent for a read-oriented tool.
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 compact and front-loaded: two sentences cover the core mechanic and key differentiator with no filler. Every clause earns its place.
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?
Considering six parameters and no output schema, the description explains the main behavior and consolidated result, but does not detail the return structure or cite behavior. Still, it is reasonably complete for a search tool with rich schema descriptions.
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 coverage is 100%, so the description does not need to compensate. It adds minimal extra semantics beyond what the schema already provides, though it does reinforce the search_type meaning by mentioning web/news/images support.
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 performs a comprehensive web search by querying Google, fetching full content via Readability extraction, and returning consolidated content. It distinguishes itself from siblings with 'TRUE deep research' and explicitly contrasts with 'not just snippets.'
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 conveys when to use the tool (when deep, full-page research is needed) but does not explicitly name alternative tools or state when not to use this tool. It relies on the implied contrast with snippet-based searches.
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?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: the tool returns snippets only, which is a limitation. It also implies a read-only search operation. However, it does not mention rate limits, authentication, or error behavior, leaving some gaps for a complete behavioral picture.
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 two sentences, front-loaded with the tool's purpose, and every word contributes value. It is efficiently structured with clear guidance and alternatives.
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?
For a simple tool with two parameters and no output schema, the description covers the essential behaviors: it is a search, returns snippets, and identifies alternatives for deep research. It is reasonably complete, though it could mention result count limits, but the schema already handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes the 'query' parameter, while 'numResults' has no description. The tool description adds no parameter-specific guidance, such as how to use numResults or what values are appropriate. With only 50% schema coverage, the description fails to compensate for the missing semantics.
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 performs a 'Simple Google search for quick lookups' and explicitly notes it 'Returns snippets only,' which distinguishes it from sibling tools like google_research and deep_search. The verb and resource are specific, and the scope is well-defined.
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 provides explicit guidance on when to use this tool ('quick lookups') and when not to, directing users to 'google_research or deep_search instead' for deep research with full page content. This clearly differentiates it from alternatives.
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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It extensively details the multi-agent process (Lead Researcher, Search Subagents, Citation Agent, Memory Module), the iterative workflow, and adaptive stopping criteria. This provides transparency about the tool's internal operations and potential for extensive parallel searches, beyond what any annotation could offer.
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?
Although long, the description is well-structured with clear headings, bullet points, and a step-by-step process flow. It front-loads the core purpose and then provides detailed but purposeful elaboration. Every section (Process Flow, Depth Levels) adds significant value without redundancy.
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 thoroughly covers the tool's behavior and process, but does not specify the structure or format of the final report beyond mentioning that citations are inserted and results are synthesized. Since there is no output schema, this gap is notable but not critical given the extensive process description.
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 describes 'topic' and 'max_content_per_page' but only provides an enum for 'depth' without explanation. The description adds meaningful semantics by explaining each depth level's iteration count, number of aspects, and coverage thresholds, thereby enriching the depth parameter beyond the 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 clearly states the tool's purpose: 'Perform extensive DEEP research on a topic using Anthropic's Multi-Agent Research Architecture.' It specifies the action (perform research), resource (topic), and the multi-agent nature, distinguishing it from simpler search tools like google_search or web_search.
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 conveys that this tool is for extensive, deep research, and outlines depth levels (basic, moderate, comprehensive) with iteration and coverage thresholds. It implies usage for complex, multi-faceted research needs, but does not explicitly exclude alternatives such as quick searches or single-aspect deep dives.
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-research-mcp MCP server](https://glama.ai/mcp/servers/thejusdutt/google-research-mcp/badges/card.svg)](https://glama.ai/mcp/servers/thejusdutt/google-research-mcp)

Score Badge

Copy to your README.md:

[![google-research-mcp MCP server](https://glama.ai/mcp/servers/thejusdutt/google-research-mcp/badges/score.svg)](https://glama.ai/mcp/servers/thejusdutt/google-research-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/thejusdutt/google-research-mcp'

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