What can you do with this server?

This server enables local, privacy-focused web search and research using RAG (Retrieval-Augmented Generation) techniques without requiring API keys, providing LLMs with current web context. Core Capabilities: * Multi-engine web search: Query across 9+ search backends including DuckDuckGo, Google, Bing, Brave, Wikipedia, Yahoo, Yandex, Mojeek, and Grokipedia * Semantic similarity ranking: Uses Google's MediaPipe Text Embedder to rank search results by relevance to your query * Deep research tools: Perform comprehensive investigations with deep_research (multi-engine), deep_research_google (Google-focused), and deep_research_ddgs (privacy-first) * Quick searches: Use rag_search_ddgs and rag_search_google for fast, focused single queries when immediate answers are needed * Content extraction: Fetches and converts web content from top-ranked URLs into markdown format for LLM consumption * Privacy-first operation: Runs entirely locally with no external API keys required * Customizable parameters: Adjust num_results, top_k, and backend selection to control search scope and depth * Agent Skills integration: Teaches Claude how to effectively use tools for intelligent query formulation, privacy-aware searching, and multi-perspective analysis * Fresh information access: Enables LLMs to retrieve current web information beyond their training data, including recent news and updates * Broad MCP client support: Works with Claude Desktop, Cursor, Goose, and other MCP clients supporting tool calling

Which integrations are available for this server?

Enables web search functionality using Google to retrieve up-to-date information that can be incorporated into Claude's responses

How do I use mcp-local-rag?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-local-rag search for the latest developments in quantum computing" 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.

de en es ja ko ru zh

mcp-local-rag

by nkapila6

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

mcp-local-rag

"primitive" RAG-like web search model context protocol (MCP) server that runs locally. ✨ no APIs ✨

A RAG-based web search and deep research model context protocol (MCP) server that runs entirely locally. Features multi-engine research across 9+ search backends with semantic similarity ranking, and requires no API keys.

Open in GitHub Codespaces

Add MCP Server mcp-local-rag to LM Studio

Ask DeepWiki

%%{init: {'theme': 'base'}}%%
flowchart TD
    A[User] -->|1.Submits LLM Query| B[Language Model]
    B -->|2.Sends Query| C[mcp-local-rag Tool]
    
    subgraph mcp-local-rag Processing
    C -->|Search DuckDuckGo| D[Fetch 10 search results]
    D -->|Fetch Embeddings| E[Embeddings from Google's MediaPipe Text Embedder]
    E -->|Compute Similarity| F[Rank Entries Against Query]
    F -->|Select top k results| G[Context Extraction from URL]
    end
    
    G -->|Returns Markdown from HTML content| B
    B -->|3.Generated response with context| H[Final LLM Output]
    H -->|5.Present result to user| A

    classDef default stroke:#333,stroke-width:2px;
    classDef process stroke:#333,stroke-width:2px;
    classDef input stroke:#333,stroke-width:2px;
    classDef output stroke:#333,stroke-width:2px;

    class A input;
    class B,C process;
    class G output;

Features

Multi-Engine Deep Research

The server supports comprehensive multi-engine research capabilities that go beyond simple single-query searches:

9+ Search Backends: DuckDuckGo, Google, Bing, Brave, Wikipedia, Yahoo, Yandex, Mojeek, Grokipedia
Multi-Topic Research: Search multiple related queries simultaneously
Semantic Ranking: RAG-like similarity scoring ranks the most relevant results
Privacy Options: Choose privacy-focused engines (DuckDuckGo, Brave) or comprehensive ones (Google)
No API Keys Required: All processing runs locally with embedded models

Deep Research Tools

deep_research - Comprehensive multi-engine research
- Search across multiple engines simultaneously
- Ideal for complex topics requiring diverse perspectives
- Customizable backends and result limits
deep_research_google - Google-focused deep dive
- Leverage Google's comprehensive index
- Best for technical/scientific queries
deep_research_ddgs - Privacy-first deep research
- Use DuckDuckGo for private, extensive research
- Great for general topics without tracking
rag_search_ddgs & rag_search_google - Quick single searches
- Fast, focused searches when you need quick answers

Installation

Locate your MCP config path here or check your MCP client settings.

Run Directly via `uvx`

This is the easiest and quickest method. You need to install uv for this to work. Add this to your MCP server configuration:

{
  "mcpServers": {
    "mcp-local-rag":{
      "command": "uvx",
        "args": [
          "--python=3.10",
          "--from",
          "git+https://github.com/nkapila6/mcp-local-rag",
          "mcp-local-rag"
        ]
      }
  }
}

Using Docker (recommended)

Ensure you have Docker installed. Add this to your MCP server configuration:

{
  "mcpServers": {
    "mcp-local-rag": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "--init",
        "-e",
        "DOCKER_CONTAINER=true",
        "ghcr.io/nkapila6/mcp-local-rag:v1.0.2"
      ]
    }
  }
}

Agent Skills

This repository includes Agent Skills that teach Claude how to effectively use the mcp-local-rag tools for intelligent web searches and deep research. Skills are folders of instructions that Claude loads dynamically to improve performance on specialized tasks.

Available Skills

local-rag-search - Teaches Claude best practices for:

Smart tool selection: Choosing between quick searches or comprehensive deep research
Multi-engine research: Using multiple search backends for diverse perspectives
Effective query formulation: Writing natural language queries that yield better results
Parameter tuning: Adjusting num_results, top_k, and backend selection for different use cases
Privacy-aware searching: Defaulting to privacy-focused engines while allowing comprehensive searches when needed

Deep Research Use Cases

The skill enables comprehensive topic research using multiple search terms and engines. It's particularly useful for technical deep dives that leverage Google's documentation coverage, multi-perspective analysis that compares information across different search engines, privacy-focused research using DuckDuckGo or Brave, and factual verification by cross-referencing Wikipedia and other authoritative sources.

Using the Skills

In Claude Desktop:

Go to Settings → Skills
Click Add Skill → Add from folder
Select skills/local-rag-search/

In conversations: Once loaded, simply ask Claude to search for information and it will automatically apply the skill's best practices. Try queries like:

"Do deep research on recent quantum computing developments"
"Search multiple sources for sustainable energy solutions"
"Find comprehensive technical documentation about Kubernetes optimization"

Learn more about Agent Skills at the Anthropic Skills Repository.

See the skills/README.md for detailed usage instructions and skill development guidelines.

Security audits

MseeP does security audits on every MCP server, you can see the security audit of this MCP server by clicking here.

MCP Clients

The MCP server should work with any MCP client that supports tool calling. Has been tested on the below clients.

Claude Desktop
Cursor
Goose
Others? You try!

Examples on Claude Desktop

When an LLM (like Claude) is asked a question requiring recent web information, it will trigger mcp-local-rag.

When asked to fetch/lookup/search the web, the model prompts you to use MCP server for the chat.

In the example, have asked it about Google's latest Gemma models released yesterday. This is new info that Claude is not aware about.

Related MCP server: free-search-mcp

Result

mcp-local-rag performs a live web search, extracts context, and sends it back to the model—giving it fresh knowledge:

Buy Me A Coffee

If the software I've built has been helpful to you. Please do buy me a coffee, would really appreciate it! 😄

ko-fi

Contributing

Have ideas or want to improve this project? Issues and pull requests are welcome!

License

This project is licensed under the MIT License.

Available Tools

5 tools

deep_researchA

Perform deep research across multiple search terms using specified search backends. This tool aggregates results from multiple searches across chosen engines, scores them by relevance, and returns the most relevant content with duplicates removed. Perfect for comprehensive research on a topic.

Available backends: bing, brave, duckduckgo, google, grokipedia, mojeek, yandex, yahoo, wikipedia

USAGE GUIDANCE FOR LLM:

Ask the user which backend(s) they prefer, OR
Choose appropriate backend(s) based on context:
- ["duckduckgo"] - Privacy-focused, general search
- ["google"] - Comprehensive results, best for technical queries
- ["duckduckgo", "google"] - Maximum coverage (default)
- ["wikipedia"] - Factual/encyclopedia content
- ["bing", "google"] - Balanced commercial engines
- Multiple backends for broader research coverage
For specific use cases, consider:
- deep_research_google() - shortcut for Google-only
- deep_research_ddgs() - shortcut for DuckDuckGo-only

ParametersJSON Schema

Name	Required	Description
`search_terms`	Yes	List of search terms to research. Provide multiple related search queries for comprehensive coverage. Example: ["machine learning fundamentals", "neural networks", "deep learning best practices"]
`backends`	No	List of search backends to use. Defaults to ["duckduckgo", "google"]. Can include: bing, brave, duckduckgo, google, grokipedia, mojeek, yandex, yahoo, wikipedia. If None, uses default.
`num_results_per_term`	No	Number of results to fetch per search term per backend.
`top_k_per_term`	No	Number of top scored results to keep per search term per backend.
`include_urls`	No	Whether to include URLs in the results.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

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 explains that the tool aggregates results, scores by relevance, and removes duplicates. It does not mention any destructive actions or side effects, but as a read-only research tool, this is sufficient. The output schema further clarifies return values.

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 sections (main purpose, available backends, usage guidance). It is informative without being overly verbose. Some redundancy exists (backends listed twice), but overall efficient.

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 of 5 parameters, 1 required, and the presence of an output schema and sibling tools, the description is thorough. It covers what the tool does, how to use it, backend selection guidance, and references to alternative tools. No gaps in essential information.

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 value by explaining the purpose of search_terms (multiple related queries), listing available backends, and providing usage recommendations for backends. This goes beyond the schema's descriptions.

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 that the tool performs deep research across multiple search terms using specified backends, aggregates results, scores by relevance, and returns the most relevant content with duplicates removed. It distinguishes itself from sibling tools like deep_research_google and deep_research_ddgs by mentioning them as shortcuts.

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 a dedicated 'USAGE GUIDANCE FOR LLM' section detailing when to use different backends, how to ask users for preferences, and specific recommendations for various use cases. It also mentions sibling tools as alternatives for single-backend scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deep_research_ddgsA

Perform deep research across multiple search terms using ONLY DuckDuckGo. Aggregates results from multiple DuckDuckGo searches, scores them by relevance, and returns the most relevant content with duplicates removed.

ParametersJSON Schema

Name	Required	Description
`search_terms`	Yes	List of search terms to research. The LLM should provide multiple related search queries for comprehensive coverage.
`num_results_per_term`	No	Number of results to fetch per search term.
`top_k_per_term`	No	Number of top scored results to keep per search term.
`include_urls`	No	Whether to include URLs in the results.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It explains that results are aggregated, scored, and deduplicated, but does not mention read-only nature, rate limits, auth requirements, or the scoring algorithm. The description gives moderate insight but lacks important operational details.

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: two sentences that front-load the core purpose and key behaviors. Every sentence adds value without any fluff or repetition. It 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?

Given the complexity (4 parameters, output schema exists), the description covers the essential purpose and behaviors. It doesn't detail the output structure, but the presence of an output schema mitigates that need. It provides sufficient context for an agent to understand the tool's role and how it differs from siblings.

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 the schema already documents all parameters clearly. The tool description does not add any additional meaning beyond what the schema provides; it only restates the overall process. 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 tool's purpose: 'Perform deep research across multiple search terms using ONLY DuckDuckGo.' It specifies the resource (DuckDuckGo) and the actions (aggregates, scores, removes duplicates). It distinguishes itself from sibling tools like deep_research_google by explicitly limiting to DuckDuckGo.

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?

The description lacks guidance on when to use this tool versus alternatives (e.g., deep_research, deep_research_google). It does not provide explicit when-to-use or when-not-to-use criteria, nor does it mention any prerequisites or contraindications.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deep_research_googleA

Perform deep research across multiple search terms using ONLY Google. Aggregates results from multiple Google searches, scores them by relevance, and returns the most relevant content with duplicates removed.

ParametersJSON Schema

Name	Required	Description
`search_terms`	Yes	List of search terms to research. The LLM should provide multiple related search queries for comprehensive coverage.
`num_results_per_term`	No	Number of results to fetch per search term.
`top_k_per_term`	No	Number of top scored results to keep per search term.
`include_urls`	No	Whether to include URLs in the results.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions aggregation, scoring by relevance, and duplicate removal, but does not address authentication, rate limits, error handling, or the format of returned content. More detail is needed for a research 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 two sentences, front-loaded with the core purpose, and no extraneous information. Every sentence 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?

Given the presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers the aggregation and scoring logic. However, it could mention the type of content returned (e.g., snippets, URLs) to be fully complete.

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 parameters with descriptions (100% coverage). The tool description does not add meaning beyond the schema; it only explains the overall process. Baseline 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 tool's function: 'Perform deep research across multiple search terms using ONLY Google.' It specifies the verb (perform deep research) and resource (Google), and distinguishes from siblings like deep_research_ddgs by emphasizing 'ONLY Google'.

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 context by specifying 'using ONLY Google', but does not explicitly state when to use this tool versus siblings or when not to use it. The sibling names provide some context, but the description lacks direct guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rag_search_ddgsA

Search the web for a given query using DuckDuckGo. Returns context to the LLM with RAG-like similarity scoring to prioritize the most relevant results.

This tool fetches web search results, scores them by semantic similarity to the query using text embeddings, and returns the top-ranked content as markdown text.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	The search query. Use natural language questions or keywords. Example: "latest developments in quantum computing"
`num_results`	No	Number of initial search results to fetch from DuckDuckGo. More results provide better coverage but increase processing time. Default: 10
`top_k`	No	Number of top-scored results to include in the final output. These are the most semantically relevant results after scoring. Default: 5
`include_urls`	No	Whether to include source URLs in the results. If True, each result includes its URL for citation. Default: True

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behaviors: fetching results, scoring by similarity, returning top-k as markdown, and mentions increased processing time for more results.

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, front-loaded with purpose, and contains no unnecessary information.

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 tool's moderate complexity (search + scoring) and the presence of an output schema, the description adequately covers usage but could mention the output format (markdown) more explicitly.

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% with detailed parameter descriptions. The description adds overall process context but does not enhance individual parameter meaning 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 it searches the web using DuckDuckGo and returns results with RAG-like similarity scoring, distinguishing it from sibling tools like rag_search_google.

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 implies when to use the tool (web search with semantic relevance), but does not explicitly state when not to use it or mention alternatives besides the sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rag_search_googleB

Search on Google for a given query using ddgs. Give back context to the LLM with a RAG-like similarity sort.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	The query to search for.
`num_results`	No	Number of results to return.
`top_k`	No	Use top "k" results for content.
`include_urls`	No	Whether to include URLs in the results.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It mentions 'ddgs' (likely a DuckDuckGo search library) but does not explain that it uses DuckDuckGo instead of Google directly, nor does it discuss rate limits, authentication, or potential blocking. The 'RAG-like similarity sort' is vague.

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: the first declares the action and resource, the second adds the key differentiating feature. No unnecessary words, well front-loaded.

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 description covers the tool's basic purpose and a key feature (similarity sort), but lacks details about the source (DuckDuckGo vs Google), failure modes, and how to choose between siblings. The presence of an output schema partially compensates for missing return value descriptions.

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% with clear parameter descriptions. The description adds value by introducing 'RAG-like similarity sort', which implicitly relates to the 'top_k' parameter and distinguishes this tool from plain search. This provides context 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 'Search on Google' with a specific verb and resource, and adds 'RAG-like similarity sort' which differentiates it from sibling tools like 'rag_search_ddgs' and 'deep_research_google'. However, the phrase 'using ddgs' could be more explicit about the underlying source.

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?

The description provides no explicit guidance on when to use this tool versus its siblings (e.g., deep_research_google, rag_search_ddgs). There is no mention of prerequisites, limitations, or alternative tools for different scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.0.4Jun 10, 2026

Changeddeep_research5 fields changed

addedInput schema / properties / backends / description

Added value: +"List of search backends to use. Defaults to [\"duckduckgo\", \"google\"].\n                 Can include: bing, brave, duckduckgo, google, grokipedia, \n                 mojeek, yandex, yahoo, wikipedia. If None, uses default."

addedInput schema / properties / include_urls / description
```
Added value: +"Whether to include URLs in the results."
```

addedInput schema / properties / num_results_per_term / description

Added value: +"Number of results to fetch per search term per backend."

addedInput schema / properties / search_terms / description

Added value: +"List of search terms to research. Provide multiple \n                      related search queries for comprehensive coverage.\n                      Example: [\"machine learning fundamentals\", \"neural networks\", \"deep learning best practices\"]"

addedInput schema / properties / top_k_per_term / description

Added value: +"Number of top scored results to keep per search term per backend."

Changeddeep_research_ddgs4 fields changed

addedInput schema / properties / include_urls / description
```
Added value: +"Whether to include URLs in the results."
```
addedInput schema / properties / num_results_per_term / description
```
Added value: +"Number of results to fetch per search term."
```

addedInput schema / properties / search_terms / description

Added value: +"List of search terms to research. The LLM should provide \n                      multiple related search queries for comprehensive coverage."

addedInput schema / properties / top_k_per_term / description

Added value: +"Number of top scored results to keep per search term."

Changeddeep_research_google4 fields changed

addedInput schema / properties / include_urls / description
```
Added value: +"Whether to include URLs in the results."
```
addedInput schema / properties / num_results_per_term / description
```
Added value: +"Number of results to fetch per search term."
```

addedInput schema / properties / search_terms / description

Added value: +"List of search terms to research. The LLM should provide \n                      multiple related search queries for comprehensive coverage."

addedInput schema / properties / top_k_per_term / description

Added value: +"Number of top scored results to keep per search term."

Changedrag_search_ddgs4 fields changed

addedInput schema / properties / include_urls / description

Added value: +"Whether to include source URLs in the results.\n                If True, each result includes its URL for citation.\n                Default: True"

addedInput schema / properties / num_results / description

Added value: +"Number of initial search results to fetch from DuckDuckGo.\n              More results provide better coverage but increase processing time.\n              Default: 10"

addedInput schema / properties / query / description

Added value: +"The search query. Use natural language questions or keywords.\n        Example: \"latest developments in quantum computing\""

addedInput schema / properties / top_k / description

Added value: +"Number of top-scored results to include in the final output.\n        These are the most semantically relevant results after scoring.\n        Default: 5"

Changedrag_search_google4 fields changed
- addedInput schema / properties / include_urls / description
```
Added value: +"Whether to include URLs in the results."
```
- addedInput schema / properties / num_results / description
```
Added value: +"Number of results to return."
```
- addedInput schema / properties / query / description
```
Added value: +"The query to search for."
```
- addedInput schema / properties / top_k / description
```
Added value: +"Use top \"k\" results for content."
```

6 tool updatesv1.0.1May 3, 2026
- Addeddeep_research
- Addeddeep_research_ddgs
- Addeddeep_research_google
- Removedrag_search
- Addedrag_search_ddgs
- Addedrag_search_google
1 tool updatev1.0.0Jan 4, 2026
- Changedrag_search1 field changed
  - addedInput schema / properties / include_urls
```
Added value: +{
+  "default": true,
+  "type": "boolean"
+}
```
1 tool updateDec 8, 2025
- First observedrag_search

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored 2026-06-10 18:50 across 5 tools

Disambiguation3/5

The generic deep_research tool already supports DuckDuckGo and Google as backends, making the dedicated deep_research_ddgs and deep_research_google tools redundant. Similarly, rag_search_ddgs and rag_search_google overlap with each other and partially with deep_research. This overlap can cause an agent to choose the wrong tool.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern (deep_research, rag_search) with backend suffixes (_ddgs, _google). The generic deep_research lacks a suffix, which is a minor inconsistency, but overall the pattern is predictable.

Tool Count4/5

With 5 tools, the count is reasonable for a search-and-research server. However, the shortcuts for specific backends could be eliminated by making the generic tools accept a backend parameter, so the count is slightly higher than necessary.

Completeness3/5

The deep_research tool supports many backends, but rag_search only supports DuckDuckGo and Google. Missing rag_search for other backends (e.g., Bing, Brave) is a notable gap. Additionally, there is no plain search tool without RAG scoring, which may be needed for some use cases.

Maintenance

ActivityInactive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

fastCRWOAuth
io.github.us
Scrape, crawl, map & search the web. Open-source, self-hostable Rust crawler & search for AI agents.
Web Scraping Browser Automation Search
2964
agentsearch-mcp A
io.github.IsaiahDupree
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Search RAG Systems Browser Automation
31
Jina Reader A
io.github.pipeworx-io
Jina AI Reader/Search MCP — turn any URL into clean LLM-ready markdown, plus web search.
Web Scraping Search
332
Ninelayer
in.ninelayer
Agent-native search engine with live web research optimized for AI agents.
Search Agent Orchestration
2

Related MCP Servers

Google PSE MCP Server
Search Browser Automation
rendyfebry
A
license
B
quality
C
maintenance
A Model Context Protocol server that enables LLM clients like VSCode, Copilot, and Claude Desktop to search the web using Google Programmable Search Engine API.
Updated a year ago (2025-09-28 10:16 UTC)
1
1,185
11
Apache 2.0
free-search-mcp
Browser Automation Search Web Scraping
sweetcornna
A
license
A
quality
A
maintenance
A local-first, no-API-key MCP server that enables LLMs to search the web, fetch pages, and read documents using multiple engines and smart fallbacks.
Updated 10 days ago (2026-08-30 06:15 UTC)
10
70
MIT
tavily-firecrawl-mcp
Web Scraping Search
bpzx
A
license
A
quality
A
maintenance
A Model Context Protocol server for web scraping and searching, with automatic fallback from Tavily to Firecrawl for fetching web content.
Updated 3 months ago (2026-06-21 10:36 UTC)
2
1
MIT
googlesearch-mcp
Search Web Scraping
SkillfulElectro
A
license
A
quality
F
maintenance
A Model Context Protocol server that exposes Google Search as a tool via scraping, requiring no API key.
Updated 2 months ago (2026-07-14 12:51 UTC)
1
MIT

Appeared in Searches

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/nkapila6/mcp-local-rag'

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

mcp-local-rag

Features

Multi-Engine Deep Research

Deep Research Tools

Installation

Run Directly via uvx

Using Docker (recommended)

Agent Skills

Available Skills

Deep Research Use Cases

Using the Skills

Security audits

MCP Clients

Examples on Claude Desktop

Result

Buy Me A Coffee

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

Run Directly via `uvx`