Gemini Research MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool has a distinct purpose: quick research vs deep research, resuming interrupted sessions, exporting results, and searching/calling tools. The descriptions clearly differentiate them, though research_web and research_deep could cause minor confusion if not carefully read.
Naming Consistency4/5
Tool names follow a mostly consistent verb_noun pattern in snake_case (research_web, research_deep, resume_research, export_research_session, search_tools, call_tool). The pattern is clear, though research_web and research_deep use qualifiers instead of straightforward nouns.
Tool Count5/5
6 tools is well-scoped for a research server. It covers quick research, deep research, session recovery, export, and tool discovery/execution without being overwhelming or sparse.
Completeness4/5
The tool surface covers the main research workflow: quick and deep research, resuming interrupted sessions, exporting results, and meta-tools for discovering and calling tools. Minor gaps like lack of a dedicated cancel or list historical sessions tool, but the set feels complete for most use cases.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on June 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare 'readOnlyHint: true' and 'openWorldHint: true', so the agent knows the tool is safe and accesses external data. The description adds that optional 'File Search and MCP tools' can be used, but does not disclose other behavioral traits (e.g., response format, length limits, result structure).
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 extremely concise—one sentence with no fluff. However, it lacks structure (e.g., bullet points or sections) that could improve readability for an agent scanning quickly.
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 complex tool with 4 parameters, an output schema, and sibling tools, the description is too minimal. It does not explain what the Deep Research agent does, how it operates, or what the output contains, leaving many agent questions unanswered.
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%, so param meaning is already clear from the schema. The description adds modest context by linking 'File Search' and 'MCP tools' to the respective parameters, but does not significantly enhance understanding beyond the schema.
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 verb 'Run' and the resource 'default Deep Research agent', and mentions optional capabilities (File Search and MCP tools). However, it does not explicitly differentiate this tool from sibling tools like 'research_web', which likely targets a narrower scope.
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 guidance is provided on when to use this tool versus alternatives (e.g., 'research_web' or 'resume_research'). There are no instructions on prerequisites or implied context.
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 must disclose behavioral traits. It only states the basic action without mentioning error handling, side effects, or permissions. For a tool that dynamically executes other tools, significant behavioral context is missing, such as what happens if the tool fails or is unavailable.
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 very concise at two sentences, with the key action front-loaded. It wastes no words, but could be slightly more structured for clarity. Overall, it efficiently conveys the essential 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?
Given the complexity (dynamic tool execution) and the absence of an output schema, the description is minimal. It covers the basic purpose and usage context but lacks details about return values, errors, or expected behavior. For a generic call tool, it barely meets the minimum viable level.
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 has 100% description coverage, so the schema already explains the parameters. The description adds no extra meaning beyond restating 'with the given arguments.' Baseline 3 is appropriate as the description does not detract but adds no value.
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 purpose: 'Call a tool by name with the given arguments.' It identifies the core action (calling a tool) and the resource (the named tool). While not overly specific, it distinguishes from sibling tools like research_web or search_tools, which are different operations.
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 provides context: 'Use this to execute tools discovered via search_tools.' This tells the agent when to use it (after discovery) and implies a sequence. It does not explicitly state when not to use it, but the usage is straightforward enough that alternatives are not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the disk-writing behavior and path handling, but it contradicts the readOnlyHint annotation (true), which implies no side effects. According to rules, a contradiction scores 1. The description is transparent but incompatible with the annotation.
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 clear sections (purpose, disk-first contract, supported formats, typical flow). Each sentence adds unique value without 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 no output schema, the description explains the return format (path on first line, EmbeddedResource). It covers all parameters and typical use cases, making the tool's behavior fully understandable.
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 description coverage is 100%, so baseline is 3. The description adds value by explaining default behavior for format, path resolution, and interaction_id selection (e.g., 'exports the most recent' if omitted). This justifies a slight above-baseline score.
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 ('Save (export, download, archive)'), the resource ('completed research session'), and the output formats (docx, md, json). It also ties the tool to the research_deep workflow, distinguishing it from siblings like research_web and resume_research.
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 explicitly states when to use this tool: 'after a research_deep run completes or is interrupted' and provides a typical recovery flow. It does not explicitly mention when not to use it, but the context is clear and no alternative export tool exists among 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?
Discloses a fixed high thinking level for quality, fast response time, and returns citations. Beyond annotations (readOnly, openWorld), it adds behavioral context about the reasoning cost and output format. No contradiction with 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 very concise: three sentences plus a bullet list of use cases. Every sentence adds value, no fluff. Well-structured for easy scanning.
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?
Given the presence of an output schema (so return values are documented), the description covers purpose, usage guidelines, and behavioral traits adequately. Could improve by noting the difference from 'research_deep', but overall sufficient.
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 explain parameters much. Description adds no extra semantic detail beyond the schema descriptions for 'query' and 'include_thoughts'. Baseline score of 3 is appropriate.
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 it performs fast web research with Gemini grounding and returns citations. It specifies the verb and resource (research web). However, it does not explicitly distinguish itself from the sibling tool 'research_deep', which might be for deeper research.
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?
Detailed list of use cases provided (quick lookups, fact-checking, current events, etc.), giving clear context for when to use. Lacks explicit guidance on when not to use or comparisons to alternatives like 'research_deep'.
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?
Without annotations, the description carries full behavioral disclosure. It states returns are ranked by relevance and in same format as list_tools, which is transparent for a read-only search.
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 sentences with front-loaded purpose, every word earns its place. No wasted text.
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 search tool with an output schema, the description adequately covers return format (matching list_tools) and relevance ranking. Minor gap: no mention of error conditions or scope of tools searched.
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% for the single parameter, which already describes 'Natural language query'. The tool description adds no extra parameter info, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for tools using natural language' with a specific verb ('search') and resource ('tools'), and distinguishes from sibling research tools by specifying it returns tool definitions rather than web content.
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 you need to find a tool) but provides no explicit guidance on when to use vs alternatives or any 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 declare readOnlyHint and openWorldHint. Description adds context: research continues on Gemini's side even if client disconnects, and result is returned once ready. No contradictions with annotations.
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?
Description is well-structured with clear paragraphs. Each sentence adds value. Slightly verbose but efficiently conveys all necessary information without 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 the presence of an output schema, the description covers behavioral aspects, error scenarios (disconnect, cancellation), and usage flow (hand off to export). No gaps for this tool's complexity.
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 already describes parameter well (100% coverage). Description adds value by explaining the two modes of operation: no argument lists sessions, with interaction_id checks status. Goes beyond schema's description.
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 resumes an interrupted 'research_deep' session. It uses specific verb 'resume' and resource 'research_deep session', and distinguishes from siblings like 'research_web' and 'research_deep' by targeting interrupted sessions only.
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?
Explicitly describes when to use: when a 'research_deep' call was cut short or to check session completion. Provides behavior for no arguments (list sessions) and with interaction_id (check status). Mentions alternative export tool. Missing explicit when-not-use, but context and sibling names cover that.
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:

[![gemini-research-mcp MCP server](https://glama.ai/mcp/servers/machinemates-ai/gemini-research-mcp/badges/card.svg)](https://glama.ai/mcp/servers/machinemates-ai/gemini-research-mcp)

Score Badge

Copy to your README.md:

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

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