Keyless-first web search and page extraction for AI agents. DuckDuckGo works out of the box. No API keys, no account, no cloud.
BetterWebSearch MCP is a local Model Context Protocol server that gives AI assistants genuinely better web search, web scraping and page extraction, and deep research with citations.
It works without API keys by default (DuckDuckGo), and optionally adds Brave or Tavily for richer ranking and publication dates. Everything runs locally over stdio, next to your client — no proxy, no hosted service, no telemetry.
Built for anyone who wants their AI tools to find things on the web reliably, not just when a paid search API key is configured.
Live counters — downloads, stars and the current release — are on the docs site.
Any MCP client that speaks stdio:
| Client | Config location |
|---|---|
| Claude Desktop | claude_desktop_config.json |
| Claude Code | .mcp.json or claude mcp add |
| Cursor | .cursor/mcp.json |
| VS Code Copilot | .vscode/mcp.json (shipped in the package) |
| Windsurf, Cline, Zed, OpenCode | their own mcpServers block |
The same four-line JSON block below works in all of them.
Add this to your MCP client config (Claude Desktop, Cursor, VS Code Copilot, OpenCode, or any MCP client):
{
"mcpServers": {
"better-web-search-mcp": {
"command": "npx",
"args": ["-y", "better-web-search-mcp"]
}
}
}That's it. Every search tool works immediately. No .env, no API keys, no setup.
Or run it directly:
npx -y better-web-search-mcp --help| Tool | What it does |
|---|---|
web_search |
Aggregated search across providers, deduplicated and reranked |
web_research |
Deep research. Rewrites your question, searches in parallel, extracts top results with citations |
deep_search |
Alias for web_research |
web_extract |
Extracts clean content from any URL, using the best method available |
web_find |
Search scoped to a single website |
web_news |
Recent news with timeline and diversity filtering |
Standard MCP search tools hit one API and return raw results. BetterWebSearch takes a different approach.
Query expansion. Your single question gets rewritten into 4 to 6 variants, searched in parallel. "Unlimited mobile internet Germany" also searches for "unbegrenztes Datenvolumen Deutschland" and similar phrasings. More coverage without you doing extra work.
Three-tier extraction. When it fetches a page, it doesn't just grab the HTML and hope for the best:
Tier 1: Fast HTTP fetch (< 1s)
↓ if not enough content
Tier 2: Structured data (JSON-LD, __NEXT_DATA__, __NUXT__) (1-3s)
↓ if still not enough
Tier 3: Playwright browser (full render + API interception) (3-10s)
Only escalates when needed. Results carry confidence scores so you know what you're getting.
Self-learning cache. The first visit to a domain takes the full path. The second visit skips straight to what worked. Domain profiles and API patterns are remembered.
Source independence. Results are clustered by content before they are cited, so a wire story republished by five outlets counts as one account rather than five corroborating sources.
Doing the web work inside the server, rather than handing pages to the model, is the point. The repository ships the benchmark that checks it.
Same questions, same pages, two workflows:
- baseline — the agent drives the tools: one
web_search, thenweb_extracton each of the top 5 results. Every page lands in its context. - research — one
web_researchcall, returning cited passages.
12 questions across definition, technical, comparison, troubleshooting and research categories, run 2026-09-02 against the live web with the browser tier disabled:
| Baseline | web_research |
|
|---|---|---|
| Payload | 820,229 chars | 110,973 chars |
| Tokens (est. at 4 chars) | ~205,000 | ~28,000 |
| Wall clock | 137.3s | 49.6s |
86.5% less text overall, 83.8% median, per-question range 56.8% to 93.4%.
Re-running with the browser tier enabled gives 86.2% overall and 83.9% median — the same within run-to-run noise — while taking 24% longer (61.3s vs 49.6s). Tier 3 earns its place on JavaScript-rendered pages that would otherwise extract nothing, not as a way to return less text.
Reproduce it yourself:
npm run build && npm run benchHonest caveats, because these are the ones that matter:
- Payload is counted in characters — exact and tokenizer-independent. The token column is an estimate at 4 chars/token for orientation; the ratio is the real result and barely moves between tokenizers.
- This measures payload, not answer quality. Deciding whether the retained
passages still support a correct answer needs a judge model, which this
harness does not have. A smaller payload is only a win if the right text
survived;
query_term_coverageis reported per question as a weak proxy and is deliberately not folded into the headline number. - Reduction tracks how much page text there was. The 56.8% case had a small baseline (~20k chars), where the fixed cost of the response's source list dominates.
- Live-web runs are not bit-reproducible: pages change and DuckDuckGo rate-limits scrapers.
- No comparison against Exa, Tavily's answer endpoint, or hosted web search — they cannot be run under identical conditions on the same pages.
Reduction only counts if the answer survives it. npm run bench:quality checks
that on 34 questions with an unambiguous marker (a port number, a status code, a
license name), conditioned on the baseline so retrieval misses are never counted
as compression losses:
| Category | Retained | Retention |
|---|---|---|
| Numbers (ports, limits) | 8 / 8 | 100% |
| HTTP status codes | 6 / 6 | 100% |
| Acronym expansions | 12 / 12 | 100% |
| Facts (licenses, defaults) | 7 / 8 | 87.5% |
| Overall | 33 / 34 | 97.1% |
Acronym questions used to retain only 58.3%: the sentence spelling out "transport layer security" states it once while surrounding pages repeat the acronym, so BM25 ranked the answer below the noise. Passage selection now recognises acronym-definition questions and surfaces the expansion. Verified by replaying one frozen page corpus so the only variable is the code — acronyms went 6/12 to 12/12, overall 27/34 to 33/34 — and confirmed by a live run at the same figures.
The remaining loss is not an acronym question: "Which HTTP request header is
used to make a conditional request with an ETag?", where the answer
(If-None-Match) appears in reference tables that the passage splitter does
not keep intact.
Method and raw per-question results: benchmarks/.
Page content is attacker-controlled and URLs arrive from the calling agent, so both are treated as untrusted.
- SSRF guard. Non-HTTP schemes are refused; hostnames are resolved and
private, loopback, link-local, CGNAT, multicast and reserved addresses
rejected — including IPv4-mapped IPv6 forms like
::ffff:127.0.0.1. Redirects are followed manually so every hop is re-checked, capped at 5. - Prompt-injection screening. Every
web_extractresult carries asecurityblock marking content untrusted and flagging text that tries to issue instructions to an agent, with the matched pattern and its offset. Content is never rewritten, so extraction stays faithful to the source. - Source independence. Pages are clustered by content before citing, so a wire story republished by five outlets counts as one account rather than five corroborating sources.
See SECURITY.md for the full threat model.
src/
providers/ Search backends (DuckDuckGo, Brave, Tavily; SerpApi stubbed)
extraction/ 3-tier content pipeline (fetch, structured, browser)
ranking/ Deduplication, domain scoring, reranking, passage selection,
source-independence clustering
tools/ MCP tool definitions (search, research, extract, find, news)
utils/ Config, caching, retry, query rewriting, SSRF guard
benchmarks/ Token-efficiency harness and results
All configuration is optional. DuckDuckGo works with zero setup.
# Optional: add more providers
BRAVE_API_KEY=your_key # Better ranking and recency
TAVILY_API_KEY=your_key # Alternative providerSee the full configuration reference for all options including cache paths, browser settings, and environment variable names.
Full guides, API reference, and architecture details live on the docs site:
phantompixeldev.github.io/BetterWebSearch-MCP
- Installation — npx, npm, or from source
- Quick Start — Get running in your first AI client
- Tools Reference — All six tools with their input schemas
- Configuration — All environment variables and options
- Providers — DuckDuckGo, Brave, Tavily
- Extraction — The three-tier pipeline in detail
- Benchmarks — Token efficiency and answer retention
- Architecture — System design overview
- Contributing — Development setup and PR process
- Changelog — Release history and version notes
No. DuckDuckGo is the default provider and needs no key, no account and no
billing. BRAVE_API_KEY and TAVILY_API_KEY are optional; they add publication
dates and stronger ranking.
Yes. MIT licensed, and the default provider costs nothing to query.
Any client that speaks MCP over stdio — Claude Desktop, Claude Code, Cursor, VS Code Copilot, Windsurf, Cline, Zed, OpenCode. See Works with.
Most wrap a single search API and hand raw results back. This one aggregates providers, expands the query into variants, escalates extraction only as far as a page demands, clusters near-duplicate sources, and returns cited passages instead of whole pages — which is where the 86.5% payload reduction comes from.
No. The server runs locally over stdio. There is no analytics, no telemetry and no intermediary service.
DuckDuckGo's HTML endpoint carries no publication dates, so on the keyless path
the results match the topic but their age is unknown. Set BRAVE_API_KEY or
TAVILY_API_KEY for date-filtered news.
Only for tier 3. Tiers 1 and 2 handle most pages; the browser is launched
lazily and can be disabled with BETTER_WEB_SEARCH_DISABLE_BROWSER=true.
MIT