de en es ja ko ru zh

mcp-local-rag

Name: mcp-local-rag
Author: nkapila6

by nkapila6

Overview Schema Source Related Servers Discussions Admin

Python

Local

mcp-local-rag

ローカルで実行される「原始的な」RAG のような Web 検索モデルコンテキストプロトコル (MCP) サーバー。✨ API なし ✨

%%{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;

インストール

ここでMCP 構成パスを見つけるか、MCP クライアント設定を確認してください。

`uvx`経由で直接実行

これは最も簡単で素早い方法です。この方法を使用するには、 uvをインストールする必要があります。MCP サーバーの設定に以下を追加してください。

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

Dockerの使用（推奨）

Dockerがインストールされていることを確認してください。MCPサーバーの設定に以下を追加してください。

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

セキュリティ監査

MseeP はすべての MCP サーバーに対してセキュリティ監査を実施します。ここをクリックすると、この MCP サーバーのセキュリティ監査を確認できます。

MCPクライアント

MCPサーバーは、ツール呼び出しをサポートするあらゆるMCPクライアントで動作します。以下のクライアントでテスト済みです。

クロードデスクトップ
カーソル
ガチョウ
他にも？試してみて！

Claude Desktopの例

LLM (Claude など) に最近の Web 情報を必要とする質問が行われると、 mcp-local-ragトリガーされます。

Web を取得/検索/検索するように要求されると、モデルはチャットに MCP サーバーを使用するように要求します。

この例では、昨日リリースされたGoogleの最新Gemmaモデルについて質問しました。これはクロードが知らない新しい情報です。

結果

mcp-local-ragライブ Web 検索を実行し、コンテキストを抽出してモデルに送り返し、最新の知識を提供します。

貢献

このプロジェクトにアイデアや改善点がありますか? 問題提起やプルリクエストをお待ちしています!

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています。

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.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
21,105
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
SSearch B
cc.ssearch
Free web search for AI agents. No API key required. Hosted MCP in active development.
Search Browser Automation
81
Firecrawl MCP Server A
io.github.firecrawl
MCP server for Firecrawl — web search, scraping, and biomedical/arXiv paper search.
Browser Automation Web Scraping Search
317,575

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
138 npm
12
Apache 2.0
free-search-mcp
Browser Automation Search Web Scraping
sweetcornna
A
license
A
quality
B
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 6 days ago (2026-10-04 15:41 UTC)
11
113
MIT
tavily-firecrawl-mcp
Web Scraping Search
bpzx
A
license
A
quality
C
maintenance
A Model Context Protocol server for web scraping and searching, with automatic fallback from Tavily to Firecrawl for fetching web content.
Updated 4 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 3 months ago (2026-07-14 12:51 UTC)
1
MIT

mcp-local-rag

インストール

uvx経由で直接実行

Dockerの使用（推奨）

セキュリティ監査

MCPクライアント

Claude Desktopの例

結果

貢献

ライセンス

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

`uvx`経由で直接実行