Provides access to Google's web search index for real-time, cited web search results through Gemini CLI.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gemini-search search for recent breakthroughs in nuclear fusion"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives any AI agent rigorous, cited web search through Gemini CLI's Google Search grounding.
┌──────────────┐ STDIO ┌──────────────────┐ child process ┌─────────────┐
│ AI Agent │◄──────────────►│ gemini-search │──────────────────►│ Gemini CLI │
│ (any MCP │ JSON-RPC │ MCP server │ gemini-3-flash │ Google Web │
│ client) │ └──────────────────┘ -preview │ Search │
└──────────────┘ └─────────────┘AI coding assistants (Claude, Kilo Code, Cursor, etc.) are powerful but blind to the live web. This MCP server fixes that by piping queries through Gemini CLI, which has built-in Google Search grounding — meaning every response is backed by real, current web results with citations.
Why use this over other paid search MCPs?
100% Free & Unlimited (relies on your local Google Cloud SDK / Gemini CLI auth)
High Quality (uses Google's live search index and gemini-3-flash-preview model)
No API keys to configure. If Gemini CLI works on your machine, this server works.
Related MCP server: gemini-search-mcp
Tool | Description | Timeout |
| Quick factual lookups with source triangulation and confidence scoring | 90s |
| 7-step research protocol with evidence grading [A/B/C/D] and opposing-view analysis | 180s |
| Forensic 5-phase verification pipeline with claim decomposition and precision audit | 90s |
Node.js ≥ 18
Gemini CLI installed and authenticated (npm install -g @google/gemini-cli)
Works on Windows, macOS, and Linux
git clone https://github.com/leacvikas0/free-search-mcp-geminicli.git
cd free-search-mcp-geminicli
npm installAdd to your MCP client config:
{
"mcpServers": {
"gemini-search": {
"command": "node",
"args": ["/absolute/path/to/free-search-mcp-geminicli/server.js"],
"env": {}
}
}
}Settings → MCP Configuration → Edit Global MCP File:
{
"mcpServers": {
"gemini-search": {
"command": "node",
"args": ["/absolute/path/to/free-search-mcp-geminicli/server.js"],
"env": {},
"trust": true
}
}
}Add to .cursor/mcp.json in your project:
{
"mcpServers": {
"gemini-search": {
"command": "node",
"args": ["/absolute/path/to/free-search-mcp-geminicli/server.js"]
}
}
}Your AI agent calls an MCP tool (e.g., web_search)
The server writes the query to a temp file and pipes it into gemini -m gemini-3-flash-preview --output-format json
Gemini CLI uses its built-in google_web_search grounding to search the live web
The server parses the JSON response and returns clean, cited results
Your AI agent gets grounded, accurate web research
Each tool has a carefully crafted system prompt that enforces:
Source triangulation — verify claims from 2+ independent sources
Anti-hallucination rules — never fabricate URLs, stats, or quotes
Evidence grading — [A] through [D] ratings on claim confidence
Conflict detection — surface disagreements between sources instead of hiding them
The model is set to gemini-3-flash-preview by default. To change it, edit the MODEL constant at the top of server.js:
const MODEL = "gemini-3-flash-preview"; // Change to any Gemini modelMIT
Conduct deep, multi-angle research on a topic using Google Search grounding. Synthesizes information from multiple sources into a comprehensive analysis. Use for complex topics, technical deep-dives, comparisons, or when thoroughness matters more than speed.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | Optional focus area to emphasize (e.g. 'performance benchmarks', 'security implications', 'recent developments') | |
| topic | Yes | The research topic — the more specific, the better |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It reveals the grounding method (Google Search), that it synthesizes multiple sources, and that it prioritizes thoroughness over speed. It does not detail output structure, citations, or failure behavior, but the core behavioral expectations are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: core behavior, method, and usage context are all front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema or annotations, it explains what the tool does, how it works, when to use it, and what it returns at a high level. It could add more on expected output details (e.g., citations or format), but nothing essential to selecting and invoking it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no extra parameter meaning beyond confirming the topic should be specific, which is already in the schema; this matches the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('conduct deep, multi-angle research on a topic using Google Search grounding') and differentiates itself from web_search and fact_check by emphasizing multi-source synthesis and comprehensive analysis. An agent can tell it is the heavier research tool rather than a quick lookup or verification tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger conditions: complex topics, technical deep-dives, comparisons, and when thoroughness outweighs speed. It does not name sibling tools as alternatives or state 'for quick lookups use web_search', so it stops short of a full when/when-not matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a specific claim or statement against current web sources. Returns a verdict with supporting evidence. Use when you need to check if something is true, outdated, or misleading.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The specific claim or statement to verify | |
| context | No | Optional context about where this claim came from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It discloses that the tool checks against current web sources and returns 'a verdict with supporting evidence', which conveys the main behavior. It does not mention potential limitations such as source reliability or how the verdict is formatted, but it gives enough context for a low-risk read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each with a distinct job: define the operation, describe the output, and state when to use it. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the core invocation: what input to provide, what it does, and what kind of result to expect. It falls short of full completeness only by not specifying the possible verdict categories or how to handle ambiguous claims, but these are minor for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already describes 'claim' and 'context'. The description adds only the 'specific claim or statement' framing, which mildly reinforces the claim parameter, but does not add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Verify'), a specific resource ('a specific claim or statement'), and the method ('against current web sources'). This clearly distinguishes it from sibling tools web_search and deep_research, which are for broader search and deeper investigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit condition for use: 'Use when you need to check if something is true, outdated, or misleading.' It does not explicitly name alternatives or when-not-to-use, but the 'specific claim' phrasing implicitly steers away from broad web_search or deep_research tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web for current information using Google Search grounding. Returns cited results with sources. Use for quick factual lookups, current events, recent news, or verifying specific data points.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query — be specific and detailed for best results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful information by stating that results are grounded in Google Search and include citations and sources, but it omits other behavioral details such as result count, freshness guarantees, latency, or any access limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states what the tool does and what output to expect, and the second supplies concrete use cases. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with no output schema, the description is reasonably complete: it covers purpose, output shape, and typical use cases. It could be more explicit about limitations or how it differs from sibling tools, but the given context is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single query parameter, so description-level explanation is less critical. The description reinforces that queries should be specific and detailed, which adds marginal guidance, but it does not provide additional syntax, formatting, or example-based semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a web search using Google Search grounding and returns cited results with sources, so the core purpose is specific and understandable. It does not explicitly name sibling tools to differentiate itself, but the 'quick factual lookups' phrasing hints at a lighter-weight alternative to deep_research.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: quick factual lookups, current events, recent news, and verifying specific data points. It does not provide exclusions or directly mention deep_research or fact_check as alternatives, so it stops short of full when-to-use versus when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0deep_researchfact_checkweb_searchScored across 3 tools
The three tools have clearly distinct primary purposes: quick search, deep research, and claim verification. web_search and deep_research could overlap for borderline topics, but the descriptions provide sufficient guidance on when to use each.
All names use lowercase snake_case and are descriptive, but they do not follow a strict verb_noun pattern. web_search and fact_check resemble verb_noun while deep_research is adjective_noun, creating a minor inconsistency.
Three tools is a well-scoped set for a search-focused server. Each tool addresses a distinct mode of information retrieval without unnecessary redundancy or bloat.
The server covers the core search domain completely: quick lookups, comprehensive research, and fact verification. No obvious dead ends or missing operations are apparent for the stated purpose.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
MCP server for Google search results via SERP API
Scrape, crawl and search the web for AI agents via MCP.
