Skip to main content
Glama
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".

Inputs: search_terms (required), news, region, recency, +8 more. Returns: object

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.

Inputs: query (required), news, top_k, region, +6 more. Returns: object

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).

Inputs: url (required), query, keywords, max_passages. Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.2/5.0

    Scored 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

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      D
      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.
      1
      107 npm
      12
      Apache 2.0
    • 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.
      2
      1
      MIT
    • 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.
      96 npm
      1
      MIT