cd /news/ai-agents/i-built-a-better-web-search-mcp-for-… · home › topics › ai-agents › article
[ARTICLE · art-140409] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

I Built a Better Web Search MCP for AI Agents — No API Key Required

A developer released BetterWebSearch MCP, an open-source Model Context Protocol server for web search, extraction and deep research that runs locally with no API key, account or cloud service, defaulting to DuckDuckGo. The server uses a three-tier extraction pipeline (HTTP fetch, structured/hydration data such as JSON-LD and __NEXT_DATA__, then Playwright) that escalates only when needed, and exposes tools including web_search, web_research, web_extract, web_find and web_news. In a 12-question live-web benchmark, its web_research tool cut returned payload from 820,229 to 110,973 characters (about 205,000 to 28,000 estimated tokens) and wall-clock time from 137.3s to 49.6s, with 97.1% answer retention across 34 factual-marker questions.

by read5 min views1 publishedSep 27, 2026

Web search for AI agents sounds simple:

In reality, it gets messy pretty quickly.

Some websites work with a simple HTTP request. Others render almost everything through JavaScript. Search APIs often require accounts, API keys or paid plans, and dumping entire webpages into an LLM context wastes a huge amount of tokens.

That's why I built BetterWebSearch MCP.

👉 https://www.npmjs.com/package/better-web-search-mcp

👉 https://github.com/PhantomPixelDev/BetterWebSearch-MCP

It's a local, open-source Model Context Protocol server for web search, extraction and deep research.

And the default setup requires no API key, no account and no cloud service.

BetterWebSearch uses DuckDuckGo by default, so you can get started immediately.

Optional providers are also supported:

The easiest way to run it is:

npx -y better-web-search-mcp

Or add it directly to your MCP configuration:

{
  "mcpServers": {
    "better-web-search-mcp": {
      "command": "npx",
      "args": ["-y", "better-web-search-mcp"]
    }
  }
}

That's it.

No .env file is required for the default setup.

Getting ten URLs isn't particularly useful if your agent can't actually read them.

Modern websites can require very different extraction strategies.

BetterWebSearch uses a three-tier extraction pipeline:

Tier 1: Fast HTTP fetch
       ↓
Tier 2: Structured / hydration data
       JSON-LD, __NEXT_DATA__, __NUXT__
       ↓
Tier 3: Playwright browser
       full rendering + API interception

The important part is that it only escalates when necessary.

If normal HTTP extraction works, there's no reason to launch Chromium.

If the page is JavaScript-heavy, BetterWebSearch can progressively fall back to structured application data and finally Playwright.

This keeps simple pages fast while still supporting modern web apps.

The MCP server currently exposes tools including:

Tool Purpose
web_search Search across providers, deduplicate and rerank results
web_research Search, extract and return cited research passages
deep_search Alias for web_research
web_extract Extract clean content from a URL
web_find Search inside a specific website
web_news Search recent news with diversity filtering

The tool I find especially useful is web_research.

Instead of making the agent manually do:

web_search
↓
web_extract result 1
↓
web_extract result 2
↓
web_extract result 3
↓
web_extract result 4
↓
web_extract result 5

it can perform the search, extraction and passage selection inside the MCP server and return a much smaller research payload.

This was one of the main things I wanted to improve.

I ran a benchmark comparing two workflows.

The agent:

The agent makes one web_research call and receives selected passages with citations.

Across 12 live-web research questions, the results were:

Traditional web_research
Payload 820,229 chars 110,973 chars
Estimated tokens ~205,000 ~28,000
Wall clock 137.3s 49.6s

That's an 86.5% reduction in returned text overall.

The median per-question reduction was 83.8%.

Of course, returning less text isn't useful if the important answer disappears.

So I added a second benchmark for answer retention.

Across 34 questions with known factual markers:

Numbers             8 / 8
HTTP status codes   6 / 6
Acronym expansions 12 / 12
Facts               7 / 8

Overall: 33 / 34
Retention: 97.1%

The benchmark source is included in the repository, so you can reproduce it yourself:

npm run build
npm run bench

Another useful feature is automatic query expansion.

Instead of searching only the exact sentence given by the model, BetterWebSearch can rewrite it into several related searches.

For example:

Unlimited mobile internet Germany

might also produce queries around:

unbegrenztes Datenvolumen Deutschland
unlimited data SIM Germany
German unlimited mobile plans

Those queries can run in parallel before the results are deduplicated and reranked.

This helps especially with searches where terminology differs between websites or languages.

Search result count can also be misleading.

If the same wire story is republished by five websites, that isn't really five independent sources.

BetterWebSearch clusters similar content before citation so duplicated stories are less likely to be treated as separate evidence.

Different domains require different extraction techniques.

BetterWebSearch remembers which extraction strategy worked for a domain.

So if the first visit discovers that a site only works properly through a particular structured-data path or browser fallback, later requests can skip unnecessary stages.

Web content is untrusted input, especially when it's being consumed automatically by AI agents.

BetterWebSearch includes several protections.

URLs are validated and requests to things like:

localhost
private IP ranges
link-local addresses
reserved addresses

are rejected.

Redirects are checked again at every hop.

Extracted content is treated as untrusted.

web_extract can flag text that appears to contain instructions attempting to manipulate an agent.

The original content isn't rewritten, but the result carries security information so the calling model can treat it appropriately.

Another design goal was avoiding unnecessary infrastructure.

BetterWebSearch runs locally over MCP stdio.

There is:

Your queries go to the search provider and target websites, not through another hosted intermediary.

It should work with any MCP client supporting stdio, including:

I personally built it primarily around coding-agent and AI research workflows, but there's nothing client-specific about the server.

The fastest way:

npx -y better-web-search-mcp

NPM:

GitHub:

Documentation:

https://phantompixeldev.github.io/BetterWebSearch-MCP/

It's MIT licensed, so feel free to use it, fork it or contribute.

If you're using MCP agents heavily, I'd especially be interested in hearing about:

Issues and PRs are welcome.

BetterWebSearch MCP gives AI agents:

🔍 Keyless web search with DuckDuckGo

🧠 Deep research with citations

⚡ HTTP-first extraction

💧 Structured-data extraction

🎭 Playwright fallback when required

📉 Up to ~86% smaller research payloads in my benchmark

🔐 SSRF and prompt-injection protections

🔌 Support for popular MCP clients

🏠 Local execution

💸 No mandatory paid API

🛠️ Open source / MIT

npx -y better-web-search-mcp
── more in #ai-agents 4 stories · sorted by recency
── more on @betterwebsearch mcp 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/i-built-a-better-web…] indexed:0 read:5min 2026-09-27 · —