Keyless-first web search for AI agents. DuckDuckGo works out of the box. No API keys.
BetterWebSearch MCP is a Model Context Protocol server that gives AI assistants genuinely better web research. It works without API keys by default (DuckDuckGo), and optionally adds Brave or Tavily for richer ranking and recency.
Built for anyone who wants their AI tools to find things on the web reliably, not just when a paid API key is configured.
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.
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.
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
- Configuration - All environment variables and options
- Contributing - Development setup and PR process
- Changelog - Release history and version notes
MIT