de en es ja ko ru zh

mcpsurfr

Name: mcpsurfr
Author: nkapila6

by nkapila6

Overview Schema Source Related Servers Discussions Admin

Python

Local

mcp-local-rag

„primitiver“ RAG-ähnlicher Web Search Model Context Protocol (MCP)-Server, der lokal ausgeführt wird. ✨ keine APIs ✨

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

Installation

Suchen Sie hier Ihren MCP-Konfigurationspfad oder überprüfen Sie Ihre MCP-Clienteinstellungen.

Direkt über `uvx` ausführen

Dies ist die einfachste und schnellste Methode. Sie müssen uv installieren, damit dies funktioniert. Fügen Sie Folgendes zu Ihrer MCP-Serverkonfiguration hinzu:

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

Verwendung von Docker (empfohlen)

Stellen Sie sicher, dass Docker installiert ist. Fügen Sie Folgendes zu Ihrer MCP-Serverkonfiguration hinzu:

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

Sicherheitsüberprüfungen

MseeP führt Sicherheitsprüfungen auf jedem MCP-Server durch. Sie können die Sicherheitsprüfung dieses MCP-Servers anzeigen, indem Sie hier klicken.

MCP-Kunden

Der MCP-Server sollte mit jedem MCP-Client funktionieren, der Tool-Aufrufe unterstützt. Wurde auf den folgenden Clients getestet.

Claude Desktop
Cursor
Gans
Andere? Versuchs doch!

Beispiele auf Claude Desktop

Wenn einem LLM (wie Claude) eine Frage gestellt wird, die aktuelle Webinformationen erfordert, wird mcp-local-rag ausgelöst.

Wenn Sie aufgefordert werden, das Web abzurufen/nachzuschlagen/zu durchsuchen, fordert das Modell Sie auf, den MCP-Server für den Chat zu verwenden.

Im Beispiel habe ich nach den gestern veröffentlichten neuesten Gemma-Modellen von Google gefragt. Dies sind neue Informationen, die Claude nicht kennt.

Ergebnis

mcp-local-rag führt eine Live-Websuche durch, extrahiert den Kontext und sendet ihn an das Modell zurück, um ihm neues Wissen zu vermitteln:

Beitragen

Haben Sie Ideen oder möchten Sie dieses Projekt verbessern? Probleme und Pull Requests sind willkommen!

Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert.

Available Tools

4 tools

deep_researchDeep researchA

Read-only

Research a topic across several search terms and engines. Each term is searched on each backend, results are re-ranked locally by relevance, duplicates are removed, and the best pages are fetched as text.

Backends: auto, brave, duckduckgo, google, grokipedia, mojeek, startpage, wikipedia, yahoo.

"auto" (default): ddgs metasearch over several engines, skipping blocked ones. Most reliable.
"brave": fast and usually available.
"wikipedia": exact article lookups, best with title-like terms.
"google", "startpage", "yahoo", "mojeek": often blocked. Empty engines are reported as warnings, and if every chosen engine is empty the terms are retried with "auto".

Name	Required	Description
`news`	No	Search news articles instead of the web. Results then carry their published "date". News backends: auto, bing, duckduckgo, yahoo. Pair with recency for current events.
`region`	No	Region-language code like "us-en", "uk-en" or "de-de". Default: ddgs's own (us-en).
`recency`	No	Applied to every term. Only results from the past "day", "week", "month" or "year".
`backends`	No	Backends to use. Defaults to ["auto"]. Unknown names are skipped with a warning.
`passages`	No	True returns only the passages that answer each term, about a tenth of the text of full pages: prefer it unless whole pages are needed. False returns full pages. Left out, the server's MCPSURFR_DEEP_RESEARCH_MODE decides (pages by default).
`include_urls`	No	Whether to include each page's source URL.
`max_passages`	No	Passages to return in passages mode, shared across terms. Default 12.
`search_terms`	Yes	2-5 specific, related search queries covering different angles. Example: ["postgres query planner", "postgres index types", "EXPLAIN ANALYZE tutorial"]
`top_k_per_term`	No	Number of top-ranked results to keep per search term per backend.
`exclude_domains`	No	Never results from these sites. Example: ["pinterest.com"]
`include_domains`	No	Only results from these sites, subdomains included. Example: ["python.org", "stackoverflow.com"]
`num_results_per_term`	No	Number of results to rank per search term per backend.

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly and openWorld annotations, the description discloses the full pipeline: each term is searched on each backend, results are locally re-ranked by relevance, duplicates are removed, and best pages are fetched as text. It also explains blocked-engine behavior, warnings for empty engines, and automatic retry with auto when all chosen engines are empty.

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 front-loaded with the core research workflow and then uses a compact backend list to convey selection guidance. Every section earns its place, and the structure makes the default and fallback behavior easy to scan.

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 12-parameter schema, full parameter descriptions, output schema, and read-only/open-world annotations, the description supplies the missing operational context: the multi-backend search pipeline, ranking, deduplication, page fetching, and engine fallback behavior. An agent has enough information to invoke this complex tool correctly.

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 the schema already documents most parameters in detail. The description still adds meaningful semantics for the backends parameter by explaining the practical behavior of auto, brave, wikipedia, and commonly blocked engines, which goes beyond the schema's brief default/unknown-name note.

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 states a specific verb and resource: research a topic across multiple search terms and engines, then rank, deduplicate, and fetch pages. This is clearly distinguishable from a simple search or URL reader because it describes a multi-query, multi-backend research pipeline.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear contextual guidance for backend selection: auto is most reliable, brave is fast, wikipedia suits exact article lookups, and several engines are often blocked with fallback to auto. It does not explicitly compare against sibling tools like search or rag_search_ddgs, so it lacks named alternatives or 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.

rag_search_ddgsWeb searchA

Read-only

Search the web and return the most relevant pages as text, for when whole pages are wanted (search returns only the relevant passages). Results are re-ranked locally by semantic similarity to the query before the top pages are fetched.

Name	Required	Description	Default
`news`	No	Search news articles instead of the web. Results then carry their published "date". News backends: auto, bing, duckduckgo, yahoo. Pair with recency for current events.
`query`	Yes	The search query. Use natural language questions or keywords. Example: "latest developments in quantum computing"
`top_k`	No	Number of top-ranked pages to fetch and return. Default: 5
`region`	No	Region-language code like "us-en", "uk-en" or "de-de". Default: ddgs's own (us-en).
`backend`	No	Search backend, same names as deep_research. Default "auto" (ddgs metasearch over several engines, skipping blocked ones). Non-auto backends that return nothing are retried with "auto".	auto
`recency`	No	Only results from the past "day", "week", "month" or "year".
`num_results`	No	Number of initial search results to rank. More results provide better coverage but increase processing time. Default: 10
`include_urls`	No	Whether to include each page's source URL for citation. Default: True
`exclude_domains`	No	Never results from these sites. Example: ["pinterest.com"]
`include_domains`	No	Only results from these sites, subdomains included. Example: ["python.org", "stackoverflow.com"]

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Goes beyond the readOnly/openWorld annotations by disclosing the internal pipeline — results are re-ranked locally by semantic similarity before the top pages are fetched. This explains why the tool is heavier than a plain search and clarifies the two-stage cost (num_results ranked, top_k fetched). It says nothing about fetch failures or latency, which keeps it from a 5.

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?

Two sentences, front-loaded with the action and output form, with the differentiator in a tight parenthetical. Slightly dense phrasing ('for when whole pages are wanted') costs it the top mark, but nothing is redundant.

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?

Output schema exists, so return values need no explanation, and the description covers the key behavioral fact an agent needs: results are fetched pages, ranked locally. It omits guidance on backend/recency interaction, though the schema descriptions carry that.

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, and the description adds real value by explaining the two-stage relationship between ranking many results and fetching the top ones, which the schema documents only per-parameter. Numeric/format detail is left to the schema, which 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?

States a specific verb and resource ('Search the web and return the most relevant pages as text') and immediately contrasts the output with the sibling 'search', which returns only passages. An agent can distinguish the two without opening either schema.

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?

Gives a clear selection condition: use this when whole pages are wanted rather than relevant passages. It does not position the tool against the other siblings (deep_research, read_url), so the when-to-use story is incomplete but the core routing decision is explicit.

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

read_urlRead a pageA

Read-only

Read one page whose URL you already have: a link the user pasted, or one from earlier results. HTML or PDF. With a query, returns only the passages that answer it, the same way search does; without one, the page's main text (cut to the shared budget).

Name	Required	Description
`url`	Yes	A public http(s) URL. Localhost and private network addresses are refused.
`query`	No	What you want from the page. Leave out to get the whole text.
`keywords`	No	Terms a good answer would contain, as for search.
`max_passages`	No	Passages to return when there's a query. Default 8.

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint) and world reach (openWorldHint), and the description adds real behavior beyond them: two output modes depending on whether a query is supplied, and truncation to a shared budget in the no-query case. It doesn't discuss failure modes or rate limits, but the URL restriction is already carried by the schema.

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?

Three short sentences, front-loaded with the precondition, then formats, then the two-mode behavior. No filler and nothing repeated from the schema verbatim.

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?

With an output schema present, return values needn't be described, and the description covers formats, the two extraction modes, and the budget cap. The only thin spot is what happens on refused or unreachable URLs, which is left entirely to the schema's url field.

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 the baseline is 3; the description earns an extra point by explaining the conditional semantics of `query` — that supplying one yields answer-bearing passages "the same way search does" — and that omitting it returns main text clipped to a budget. That connects `query` and `max_passages` behaviorally in a way the per-field descriptions do not.

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?

States a specific verb and resource ("Read one page") and immediately scopes it to URLs the agent already possesses, which cleanly separates it from the search siblings. It also names the supported content types (HTML or PDF), so an agent knows what it can point this at without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase "whose URL you already have: a link the user pasted, or one from earlier results" tells the agent the precondition for use and implicitly rules out discovery (that's what search/deep_research are for). It stops short of naming a sibling as the alternative for the discovery case, so it's clear context rather than an explicit when/when-not pair.

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

searchSearch (passages)A

Read-only

Search the web and return only the passages that answer the query, not whole pages: usually about a tenth of the text of rag_search_ddgs. Use this first.

Tiers, cheapest first:

Search, then keep the top_pages results whose title/snippet match best.
Fetch those pages, split them into ~600-char passages, keyword-match them (BM25) against the query plus keywords.
Only if that leaves too many candidates, or matches nothing (a paraphrase), the local embedder ranks them by meaning. If nothing matched the keywords and the client can show questions, the user is asked whether they want the full pages instead.

Name	Required	Description	Default
`news`	No	Search news articles instead of the web. Results then carry their published "date". News backends: auto, bing, duckduckgo, yahoo. Pair with recency for current events.
`query`	Yes	The question or topic, in natural language.
`region`	No	Region-language code like "us-en", "uk-en" or "de-de". Default: ddgs's own (us-en).
`backend`	No	Search backend, same names as deep_research. Default "auto".	auto
`recency`	No	Only results from the past "day", "week", "month" or "year".
`keywords`	No	Terms a good answer would contain, including synonyms and exact phrases. Example for "how do I make postgres faster": ["index", "EXPLAIN ANALYZE", "query planner", "vacuum"]. Strongly improves results.
`top_pages`	No	Pages to fetch and split. Default 5.
`num_results`	No	Search results to consider. Default 10.
`max_passages`	No	Passages to return. Default 8.
`exclude_domains`	No	Never results from these sites. Example: ["pinterest.com"]
`include_domains`	No	Only results from these sites, subdomains included. Example: ["python.org", "stackoverflow.com"]

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the internal pipeline — fetch top pages, split into ~600-char passages, BM25 keyword matching, local embedder as a meaning-based fallback. The "cheapest first" framing also signals relative cost, which annotations never convey.

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?

Front-loaded with purpose and the routing cue, then a compact numbered pipeline. The tiered list is the right structure for a staged algorithm, and no sentence is filler — even the parenthetical about a tenth the text of rag_search_ddgs carries decision value.

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?

An output schema exists so return values need not be explained, and the description still covers cost, fallback behavior, and failure handling for an 11-parameter tool. Nothing an agent needs in order to call it correctly or decide against a sibling is missing.

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?

With 100% schema coverage the baseline is 3, but the description earns more by explaining roles: `keywords` is described as the BM25 matching vocabulary in tier 2, and `top_pages` as the set of pages fetched and split. It does not clarify the interplay between num_results, top_pages, and max_passages, which is the one remaining ambiguity.

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?

States a specific verb and resource (search the web) plus the defining scope constraint: it returns passages, not whole pages. It explicitly contrasts with sibling rag_search_ddgs ("about a tenth of the text"), so an agent can choose between them without opening either schema.

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?

"Use this first" gives explicit precedence over siblings, and the numbered tiers state the conditions under which the cheap path is kept versus when the embedder fallback is invoked ("only if that leaves too many candidates, or matches nothing"). It even covers the escalation path to the user when nothing matches.

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.

1 tool updatev1.2.3Oct 30, 2026

Changeddeep_research2 fields changed

addedInput schema / properties / max_passages

Added value: +{
+  "default": 12,
+  "description": "Passages to return in passages mode, shared across terms. Default 12.",
+  "type": "integer"
+}

addedInput schema / properties / passages

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "True returns only the passages that answer each term, about a\ntenth of the text of full pages: prefer it unless whole pages are needed. False returns\nfull pages. Left out, the server's MCPSURFR_DEEP_RESEARCH_MODE decides (pages by default)."
+}

7 tool updatesv1.2.0Oct 29, 2026

Changeddeep_research5 fields changed

addedInput schema / properties / exclude_domains

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Never results from these sites. Example: [\"pinterest.com\"]"
+}

addedInput schema / properties / include_domains

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only results from these sites, subdomains included.\nExample: [\"python.org\", \"stackoverflow.com\"]"
+}

addedInput schema / properties / news

Added value: +{
+  "default": false,
+  "description": "Search news articles instead of the web. Results then carry their published\n\"date\". News backends: auto, bing, duckduckgo, yahoo. Pair with recency for current events.",
+  "type": "boolean"
+}

addedInput schema / properties / recency

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "day",
+        "week",
+        "month",
+        "year"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Applied to every term. Only results from the past \"day\", \"week\", \"month\" or \"year\"."
+}

addedInput schema / properties / region

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Region-language code like \"us-en\", \"uk-en\" or \"de-de\". Default: ddgs's own (us-en)."
+}

Removeddeep_research_ddgs
Removeddeep_research_google

Changedrag_search_ddgs6 fields changed

addedInput schema / properties / backend

Added value: +{
+  "default": "auto",
+  "description": "Search backend, same names as deep_research. Default \"auto\" (ddgs\n           metasearch over several engines, skipping blocked ones). Non-auto\n           backends that return nothing are retried with \"auto\".",
+  "type": "string"
+}

addedInput schema / properties / exclude_domains

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Never results from these sites. Example: [\"pinterest.com\"]"
+}

addedInput schema / properties / include_domains

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only results from these sites, subdomains included.\nExample: [\"python.org\", \"stackoverflow.com\"]"
+}

addedInput schema / properties / news

Added value: +{
+  "default": false,
+  "description": "Search news articles instead of the web. Results then carry their published\n\"date\". News backends: auto, bing, duckduckgo, yahoo. Pair with recency for current events.",
+  "type": "boolean"
+}

addedInput schema / properties / recency

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "day",
+        "week",
+        "month",
+        "year"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only results from the past \"day\", \"week\", \"month\" or \"year\"."
+}

addedInput schema / properties / region

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Region-language code like \"us-en\", \"uk-en\" or \"de-de\". Default: ddgs's own (us-en)."
+}

Removedrag_search_google
Addedread_url

Changedsearch5 fields changed

addedInput schema / properties / exclude_domains

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Never results from these sites. Example: [\"pinterest.com\"]"
+}

addedInput schema / properties / include_domains

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only results from these sites, subdomains included.\nExample: [\"python.org\", \"stackoverflow.com\"]"
+}

addedInput schema / properties / news

Added value: +{
+  "default": false,
+  "description": "Search news articles instead of the web. Results then carry their published\n\"date\". News backends: auto, bing, duckduckgo, yahoo. Pair with recency for current events.",
+  "type": "boolean"
+}

addedInput schema / properties / recency

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "day",
+        "week",
+        "month",
+        "year"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only results from the past \"day\", \"week\", \"month\" or \"year\"."
+}

addedInput schema / properties / region

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Region-language code like \"us-en\", \"uk-en\" or \"de-de\". Default: ddgs's own (us-en)."
+}

6 tool updatesv1.1.1Oct 23, 2026

Changeddeep_research5 fields changed

changedInput schema / properties / backends / description

Previous 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."New value: +"Backends to use. Defaults to [\"auto\"]. Unknown names are skipped with a warning."

changedInput schema / properties / include_urls / description

Previous value: -"Whether to include URLs in the results."New value: +"Whether to include each page's source URL."

changedInput schema / properties / num_results_per_term / description

Previous value: -"Number of results to fetch per search term per backend."New value: +"Number of results to rank per search term per backend."

changedInput schema / properties / search_terms / description

Previous 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\"]"New value: +"2-5 specific, related search queries covering different angles.\n                      Example: [\"postgres query planner\", \"postgres index types\", \"EXPLAIN ANALYZE tutorial\"]"

changedInput schema / properties / top_k_per_term / description

Previous value: -"Number of top scored results to keep per search term per backend."New value: +"Number of top-ranked results to keep per search term per backend."

Changeddeep_research_ddgs4 fields changed

changedInput schema / properties / include_urls / description

Previous value: -"Whether to include URLs in the results."New value: +"Whether to include each page's source URL."

changedInput schema / properties / num_results_per_term / description

Previous value: -"Number of results to fetch per search term."New value: +"Number of results to rank per search term."

changedInput schema / properties / search_terms / description

Previous value: -"List of search terms to research. The LLM should provide \n                      multiple related search queries for comprehensive coverage."New value: +"2-5 specific, related search queries."

changedInput schema / properties / top_k_per_term / description

Previous value: -"Number of top scored results to keep per search term."New value: +"Number of top-ranked results to keep per search term."

Changeddeep_research_google4 fields changed

changedInput schema / properties / include_urls / description

Previous value: -"Whether to include URLs in the results."New value: +"Whether to include each page's source URL."

changedInput schema / properties / num_results_per_term / description

Previous value: -"Number of results to fetch per search term."New value: +"Number of results to rank per search term."

changedInput schema / properties / search_terms / description

Previous value: -"List of search terms to research. The LLM should provide \n                      multiple related search queries for comprehensive coverage."New value: +"2-5 specific, related search queries."

changedInput schema / properties / top_k_per_term / description

Previous value: -"Number of top scored results to keep per search term."New value: +"Number of top-ranked results to keep per search term."

Changedrag_search_ddgs3 fields changed

changedInput schema / properties / include_urls / description

Previous value: -"Whether to include source URLs in the results.\n                If True, each result includes its URL for citation.\n                Default: True"New value: +"Whether to include each page's source URL for citation.\n                Default: True"

changedInput schema / properties / num_results / description

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

changedInput schema / properties / top_k / description

Previous 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"New value: +"Number of top-ranked pages to fetch and return.\n        Default: 5"

Changedrag_search_google3 fields changed

changedInput schema / properties / include_urls / description

Previous value: -"Whether to include URLs in the results."New value: +"Whether to include each page's source URL."

changedInput schema / properties / num_results / description

Previous value: -"Number of results to return."New value: +"Number of initial search results to rank."

changedInput schema / properties / top_k / description

Previous value: -"Use top \"k\" results for content."New value: +"Number of top-ranked pages to fetch and return."

Addedsearch

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

A4.2/5.0

Scored 2026-10-30 20:25 across 4 tools

Disambiguation3/5

read_url is clearly distinct, but search, rag_search_ddgs, and deep_research all perform web search with overlapping engines and ranking logic. The descriptions do distinguish them (passages vs. whole pages vs. multi-term multi-engine), but the boundary between search and rag_search_ddgs hinges on a subtle output-format difference that an agent could easily misselect.

Naming Consistency3/5

All names use snake_case, but the conventions are mixed: bare verb (search), verb_noun (read_url, deep_research), and verb_noun with backend baked in (rag_search_ddgs). The backend name embedded in one tool name makes the set less predictable than a uniform pattern.

Tool Count4/5

Four tools is slightly thin but reasonable for a focused web-research server; each tool covers a distinct retrieval mode. A fifth tool (e.g., a crawl/sitemap or batch URL reader) would round it out without bloat.

Completeness4/5

The surface covers the core research lifecycle: passage search, full-page search, multi-engine deep research, and direct URL reading (HTML and PDF). Minor gaps remain around batch reading, following links from a fetched page, or structured extraction, but the main workflows are covered.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

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,197
https://fastcrw.com/mcp
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
https://agentsearch-mcp.vercel.app/mcp
Gyaansetu Web Search
io.github.rahul05ranjan
Search the open web and Extract Raw Content for AI agents.
Browser Automation Web Scraping Search
1
https://web-search.gyaansetu.com/mcp
SSearch B
cc.ssearch
Free web search for AI agents. No API key required. Hosted MCP in active development.
Search Browser Automation
82
https://api.ssearch.cc/mcp

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
20 npm
12
Apache 2.0
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 4 months ago (2026-07-14 12:51 UTC)
1
MIT
Lookout
Browser Automation Web Scraping Search
SylphxAI
A
license
Not graded
quality
F
maintenance
MCP server enabling local-first web search, fetch, extract, and caching with citeable excerpts, no API key required. Supports research workflows for agents and apps.
Updated a month ago (2026-09-25 08:10 UTC)
65 npm
1
MIT

mcp-local-rag

Installation

Direkt über uvx ausführen

Verwendung von Docker (empfohlen)

Sicherheitsüberprüfungen

MCP-Kunden

Beispiele auf Claude Desktop

Ergebnis

Beitragen

Lizenz

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Direkt über `uvx` ausführen