What can you do with this server?

This server provides local, keyless web search and page reading for LLMs over MCP, with on-device ranking and token-efficient passage extraction. * Search the web and return only the most relevant passages for a query, with optional keywords, domains, recency, region, and news filters. * Fetch full pages as clean text with rag_search_ddgs when whole-page context is needed. * Read a specific URL and optionally extract only passages that answer a query; supports HTML and PDFs. * Run multi-term deep research across several search backends, merging results, de-duplicating pages, and fetching the best content. * Use keyless search backends including auto, Brave, DuckDuckGo, Google, Wikipedia, Yahoo, and others. * Get locally re-ranked results, duplicate removal, skipped-result reasons, warnings, titles, and publish dates when available. * Use built-in caching, domain include/exclude controls, news search, and a provided skill/research prompt for guided use.

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 mcpsurfr?

1. Click on "Deploy 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., "@mcpsurfr 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

mcpsurfr

by nkapila6

Overview Schema Source Related Servers Discussions Admin

Python

Local

flowchart LR
    Q["query + keywords"] --> S["ddgs<br>several engines, no keys"]
    S --> R["re-rank<br>on device"]
    R --> F["fetch top pages<br>main text, PDFs"]
    F -->|search| P["best passages<br>~1k tokens"]
    F -->|rag_search_ddgs<br>deep_research| W["full pages<br>shared budget"]

What's in it:

No API keys. Searches go through ddgs. Its auto mode asks several engines at once and skips blocked ones.
Ranked locally. A small MobileBERT model on plain numpy re-ranks results, so only the best pages get fetched.
Clean text. Pages are fetched with browser impersonation, and only the main content is kept: no menus, cookie banners or footers. Code blocks and tables keep their lines. PDFs are read too (text layer, first 50 pages), and docs sites that publish markdown copies of their pages (llms.txt) are read from those. The same page under two URLs comes back once.
Passages instead of pages. search returns just the paragraphs that answer the question, about a tenth of the tokens, and deep_research can do the same per search term. When nothing matches well, search can ask you whether you want the full pages instead.
Reads the sites that block scrapers. Stack Overflow and the other Stack Exchange sites, Wikipedia, GitHub, Hacker News, PyPI, npm and crates.io go through their free APIs: questions with the accepted answer first, articles by section, READMEs and raw files, HN threads with their comments, and packages with their latest version, release date and README.
Titles and dates. Every page and passage carries its title, and its publish date when the page or news result has one.
Says what it left out. Results list skipped pages with a reason (blocked, JavaScript-only, duplicate...) and the search snippet for each, so a Reddit thread or an msn.com article still says something. Cut pages are marked truncated, and fallbacks and engine failures show up as warnings. Google blocks often, so it falls back to auto on its own.
Quick on repeats. Searches and pages are kept for five minutes, so a follow-up call on the same pages doesn't fetch them again.
Brings its own guide. It serves a skill and a research prompt, so clients pick up how to use it without setup.

Tool	Use it for
`search`	Start here: returns only the relevant passages. Pass `keywords` for better hits
`rag_search_ddgs`	Full pages as text (the original mode). Takes a `backend`
`deep_research`	Several search terms across backends, merged and de-duplicated. `passages: true` returns only the relevant passages per term
`read_url`	One page you already have the link for. Pass a `query` to get only the passages that answer it

The search tools also take recency (day, week, month, year), region (uk-en, de-de...), include_domains / exclude_domains, and news: true for dated news articles.

The old rag_search_google, deep_research_ddgs and deep_research_google presets are hidden by default. Options says why and how to turn them back on.

Backends: auto (default), brave, duckduckgo, google, grokipedia, mojeek, startpage, wikipedia, yahoo. auto and brave are the dependable ones. With news: true: auto, bing, duckduckgo, yahoo.

How it compares

Other keyless MCP servers (mcp-searxng, duckduckgo-mcp-server, open-webSearch, the official fetch server) hand the model snippets or whole pages. Hosted APIs like Tavily, Exa and Brave do cut pages down to the useful parts, but they need a key and do it on their servers. mcpsurfr does that part on your machine:

picks passages with BM25 on the query plus keywords the model supplies, and an on-device embedder for ties and paraphrases
drops near-duplicate pages and shares one text budget across the rest
tells the model what it skipped and why, and can ask you before falling back to full pages

What it doesn't do: JavaScript-only pages, OCR for scanned PDFs, image search.

Related MCP server: tavily-firecrawl-mcp

Install

From PyPI with uv:

{
  "mcpServers": {
    "mcpsurfr": {
      "command": "uvx",
      "args": ["mcpsurfr"]
    }
  }
}

uvx keeps using the version it cached first. Use "mcpsurfr@latest" to pick up new releases on every start (about a second slower), or "mcpsurfr@<version>" to pin one. uv tool install mcpsurfr works too, with "command": "mcpsurfr".

Or with Docker (amd64 and arm64):

{
  "mcpServers": {
    "mcpsurfr": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "--init", "ghcr.io/nkapila6/mcpsurfr:latest"]
    }
  }
}

Options

All settings are optional. These configs set each one to its default, so change only what you need. With uvx they go in env:

{
  "mcpServers": {
    "mcpsurfr": {
      "command": "uvx",
      "args": ["mcpsurfr"],
      "env": {
        "MCPSURFR_MAX_CHARS": "40000",
        "MCPSURFR_DEEP_RESEARCH_MODE": "pages",
        "MCPSURFR_CACHE_TTL": "300",
        "MCPSURFR_LEGACY_TOOLS": "0"
      }
    }
  }
}

Variable	Default	What it does
`MCPSURFR_MAX_CHARS`	`40000`	Text budget per call when returning full pages (`rag_search_ddgs`, `deep_research`, `read_url` without a query), shared across pages. ~4 chars per token
`MCPSURFR_DEEP_RESEARCH_MODE`	`pages`	What `deep_research` returns when a call doesn't say: `pages` (full text) or `passages` (only what answers each term, about a tenth of the tokens)
`MCPSURFR_CACHE_TTL`	`300`	Seconds searches and fetched pages are reused. `0` turns the cache off. News searches are never cached
`MCPSURFR_LEGACY_TOOLS`	`0`	`1` brings back `rag_search_google`, `deep_research_ddgs` and `deep_research_google`, for prompts or workflows that still call them by name

Why the legacy tools are off: they're just rag_search_ddgs and deep_research with a fixed backend, which the search tools now take themselves. Each tool's name, description and parameters get sent to the model in every chat whether it's used or not, so three duplicates cost context for nothing and give the model more ways to pick the wrong one.

With Docker, env only reaches the docker command, not the container, so the settings go in args with -e, before the image name. The same defaults:

{
  "mcpServers": {
    "mcpsurfr": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i", "--init",
        "-e", "MCPSURFR_MAX_CHARS=40000",
        "-e", "MCPSURFR_DEEP_RESEARCH_MODE=pages",
        "-e", "MCPSURFR_CACHE_TTL=300",
        "-e", "MCPSURFR_LEGACY_TOOLS=0",
        "ghcr.io/nkapila6/mcpsurfr:latest"
      ]
    }
  }
}

Not sure where your config lives? See the MCP quickstart. Tested with Claude Desktop, Claude Code, Cursor and Goose.

Coming from mcp-local-rag? Your old config keeps working, since the old URL redirects and the mcp-local-rag command still exists. Switching to the config above gets you the new name and drops the --python=3.10 pin (3.10 is end of life as of October 2026). If your prompts call rag_search_google or deep_research_google by name, set MCPSURFR_LEGACY_TOOLS to 1 (see Options).

Skill and prompt

The mcpsurfr-search skill tells the model which tool and backend to pick and how to cite. The server serves it as skill://mcpsurfr-search/SKILL.md, so most clients need nothing extra. To add it to Claude Desktop by hand: Settings → Skills → Add from folder, then pick src/mcpsurfr/skills/mcpsurfr-search/.

The research(topic) prompt plans a few search terms, runs deep_research and writes a cited summary.

Example

Asking Claude Desktop about something newer than its training data:

Security audit by MseeP · Issues and PRs welcome · MIT licensed · Buy me a coffee if it helps you

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

Webcrawl Anything
io.github.brainfish-ai
Scrape, map, crawl, search and monitor the web. Runs locally with no API key, cites every source.
Browser Automation Web Scraping Search
1
https://webcrawl.app/mcp
fastCRW
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,219
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
SearchPipe A
tech.searchpipe
Web search API and MCP server for developers building AI agents.
Search Browser Automation Agent Orchestration
31
https://searchpipe.tech/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
72 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

How it compares

Install

Options

Skill and prompt

Example

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches