DuckDuckGo MCP Servers in Claude Code: 8 Tested, 3 Actually Work
Free web search for an agent sounds like a solved problem. There are dozens of DuckDuckGo MCP servers, none of them wants an API key, and every catalog lists them with the same three-line description lifted from the README. So I installed eight of them and gave each one the same job: twelve research questions, one after another, no pause between them. That is roughly what a coding agent does when it starts digging into an unfamiliar library.
Three servers answered all twelve. One of them was not talking to DuckDuckGo at all.
I work at HasData and we run one of the eight. It came third on speed in the first pass and fourth in the two after, behind free servers. Every config below is copy-paste ready, and the harness is public if you want to rerun any of it.
The setup
Twelve queries, from rust async runtime comparison to solar inverter efficiency, sent back to back through the official MCP TypeScript SDK. Then the whole thing twice more, about an hour apart, to see what was stable.
One machine, one IP, 2026-09-15.
A call counted as a failure if the server errored, if the body was an error dressed as a result, or if it came back with nothing in it. That third rule did most of the work.
Here is the whole test on one screen, ordered by how often each server finished and then by speed.
| Server | Install | Finished, 3 passes | Median | Payload | Returns |
|---|---|---|---|---|---|
| free-search-mcp |
uvx free-search-mcp
|
12, 12, 12 | 1.39 s | 4.2 KB | markdown, JSON on request |
| HasData (ours) | hosted, no install | 12, 12, 12 | 1.96 s | 10.0 KB | JSON |
| nickclyde |
uvx duckduckgo-mcp-server
|
12, 12, 12 | 2.37 s | 3.6 KB | text |
| open-webSearch |
npx open-websearch
|
10, 12, 12 | 1.12 s | 5.4 KB | JSON |
| one-search-mcp |
npx one-search-mcp
|
12, 12, 12 | 7.27 s | 4.9 KB | text, Bing results |
| OEvortex |
npx @oevortex/ddg_search
|
3, 6, 2 | 1.53 s | 1.2 KB | text |
| web-scout |
npx @pinkpixel/web-scout-mcp
|
1, 0, 1 | 1.51 s | 4.0 KB | text |
| zhsama |
npx duckduckgo-mcp-server
|
0, 0, 0 | n/a | n/a | n/a |
The medians only count calls that returned something, so the bottom three look faster than they are. OEvortex failing in 1.53 s is still a failure.
Start here if you just want one that works
{
"mcpServers": {
"duckduckgo": {
"command": "uvx",
"args": ["free-search-mcp"]
}
}
}
free-search-mcp answered twelve of twelve in every pass at a 1.39 s median, the fastest of the servers that finished. It is a 69-star project, MIT, last pushed in August 2026, so it is young. It returns markdown by default. If your agent would rather have JSON, ask for it per call:
{
"query": "rust async runtime comparison",
"engines": ["duckduckgo"],
"format": "json",
"use_cache": false
}
Three arguments is more config than the others need, and use_cache defaults to true, which will quietly hand you an old answer if you leave it alone. That is the trade for the best numbers in the test.
The one everybody installs
{
"mcpServers": {
"duckduckgo": {
"command": "uvx",
"args": ["duckduckgo-mcp-server"]
}
}
}
nickclyde's server is the default choice for good reason: 1,460 stars, pushed this month, MIT, and it is what the mcp/duckduckgo Docker image is built from, with over half a million pulls. It finished twelve of twelve in all three passes at 2.37 s, then came apart on a fourth run from a fresh clone, answering seven and refusing five with a note about DuckDuckGo's bot detection and a suggestion to install its optional browser backend for Chrome TLS impersonation.
It answers in prose - "Found N search results:" followed by a numbered list - so your model does the parsing. Its search tool takes a query, a result count and a region, and there is no pagination.
Watch the command. This is duckduckgo-mcp-server on PyPI, hence uvx. There is an unrelated duckduckgo-mcp-server on npm, and this config gets you a completely different server:
{
"mcpServers": {
"duckduckgo": {
"command": "npx",
"args": ["-y", "duckduckgo-mcp-server"]
}
}
}
That one is zhsama's, and it scored zero of twelve in all three passes. Google's AI Overview for the package name currently recommends the npm version.
The hosted one, which is ours
{
"mcpServers": {
"duckduckgo": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=duckduckgo",
"headers": {
"x-api-key": "YOUR-KEY"
}
}
}
}
Twelve of twelve in all three passes at a 1.96 s median, which put it third on speed in the first pass and fourth in the two after, behind free servers. That is the honest placement and it is the least interesting number here.
What it does differently is the payload. Ten results carrying position, title, link, displayedLink, source, snippet and snippetHighlightedWords, plus DuckDuckGo's own assist answer with its sources and a pagination token. Nothing else in the test paginates, and only open-webSearch and free-search return JSON at all.
The cost of that is weight: 10.0 KB per call against nickclyde's 3.6, which your agent pays for in context.
The other difference is the one I did not expect to matter. Time from cold config to first answer was 2.3 s, against 8.3 s for free-search, 8.8 s for nickclyde and 37 to 48 s for `open
Comments
No comments yet. Start the discussion.