DEV Community: Sergey Ermakovich

DuckDuckGo MCP Servers in Claude Code: 8 Tested, 3 Actually Work

Sergey Ermakovich — Wed, 23 Sep 2026 07:09:55 +0000

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-webSearch and OEvortex, which spend it resolving and building packages. There is nothing on your machine to install or keep current, and nothing that breaks when a transitive dependency moves.

It is the only server in the test that costs money past a free tier of 100 searches a month, with paid plans running from $2.95 down to $0.83 per thousand. Details and the free key are on the server page.

What went wrong, server by server

zhsama, zero of twelve, three times

Ten of its twelve calls came back in two to five milliseconds with a 26-byte error. Nothing reaches the network that fast. Its own stderr names the culprit:

[DEBUG] Rate limit check - Current counts: { second: 1, month: 2, lastReset: ... }
[ERROR] Rate limit exceeded
    at checkRateLimit (.../duckduckgo-mcp-server/build/index.js:80:23)

The shipped build sets rateLimit: { perSecond: 1, perMonth: 15000 }. So { second: 1, month: 2 } is a counter, not a budget, and what stopped the run is one request per second. The server throws instead of queueing, which is the part that matters for an agent: a burst of twelve gets ten hard errors rather than twelve slow answers.

Pace your calls a second apart and you clear its limiter. The two that did get through reached DuckDuckGo and were turned away there anyway.

web-scout, one of twelve

{ "mcpServers": { "duckduckgo": { "command": "npx", "args": ["-y", "@pinkpixel/web-scout-mcp"] } } }

It answered the first query in 1.5 s and then returned this eleven times, each in under 310 ms:

No results were found for your search query. Please try rephrasing your search or try again in a few minutes.

No error flag, no status code, just a sentence. Your agent sees a successful tool call with a polite message and concludes the web has nothing on Postgres index bloat.

OEvortex, three then six then two

Nine of twelve failed with HTTP 202: Failed to fetch search results, and the successes landed on calls eight, nine and twelve. Rerun an hour later it scored six, then two. That spread is not a rate limit being hit. A limit cuts in and stays cut in. This is a wrapper that works sometimes.

open-webSearch, the fastest thing here and the quietest failure

{
  "mcpServers": {
    "duckduckgo": {
      "command": "npx",
      "args": ["-y", "open-websearch"],
      "env": { "MODE": "stdio", "DEFAULT_SEARCH_ENGINE": "duckduckgo" }
    }
  }
}

1.12 s median, JSON with direct links, five fields per result including which engine produced it. It lost two of twelve in the first pass and none in the two after.

Those two look like this:

{
  "query": "bird migration patterns europe",
  "engines": ["duckduckgo"],
  "totalResults": 0,
  "results": [],
  "partialFailures": []
}

Note the last field. The server has somewhere to report that an engine failed and left it empty while returning nothing. Its stderr for those exact two calls says it could not find the preloaded d.js URL it scrapes out of DuckDuckGo's HTML, so the diagnosis exists, it just never reaches the caller.

The MODE: stdio in that config is not optional if you run it more than once. By default it also binds an HTTP server on port 3000, and a leftover instance from an earlier session makes the next one die with MCP error -32000: Connection closed, which tells you nothing about ports.

one-search-mcp, which was searching Bing

This is the one worth ten minutes of your attention. Its tool schema has no engine parameter, so I ran it as shipped, and it looked fine: twelve of twelve, 7.27 s each, well-formed results. Then I looked at the URLs. Every one was a bing.com/ck/a redirect. Not a single duckduckgo.com address in any response.

The server reads SEARCH_PROVIDER from the environment. The default is local, which launches your real Chrome profile and scrapes Bing. Set it properly:

{
  "mcpServers": {
    "search": {
      "command": "npx",
      "args": ["-y", "one-search-mcp"],
      "env": { "SEARCH_PROVIDER": "duckduckgo" }
    }
  }
}

and it returns zero of twelve, each call failing after ten to sixteen seconds with DuckDuckGo's anomaly message and Failed to get the VQD in its log. So its DuckDuckGo path does not work from here, and its working path is not DuckDuckGo.

The Bing redirect is not automatically a problem, since DuckDuckGo's organic index is largely Bing-sourced anyway. The problem is a URL that hides its destination in a base64 parameter, which quietly breaks deduplication and domain filters in whatever you build on top.

The rule that would have caught half of this

Three of the eight fail inside a successful tool call. Two return an empty array, one returns a prose sentence. If your agent checks for errors and then reads results, all three look like a search that found nothing.

const failed =
  res.isError ||
  !Array.isArray(items) || items.length === 0 ||
  /no results|bot detection|rate limit|anomaly/i.test(text.slice(0, 400));

Two details from the run. The array check alone misses web-scout, which returns no array at all. And an immediate retry does not help, because open-webSearch returned empty twice in a row, so back off with a cap and fail over to a second server instead.

What I kept

For hand-driven searching, free-search-mcp with the engine pinned and the cache off. It never missed a call in three passes and it is the fastest of the ones that finished.

For an agent that runs unattended, the requirement is JSON with real links plus the check above, and that is a format question rather than a reliability one. nickclyde and free-search were just as reliable as anything else and both answer in prose. open-webSearch gives you JSON out of the box and is the one that silently empties. Ours gives you JSON with pagination, did not miss a call in forty-eight, starts answering in a couple of seconds with nothing installed, returns the heaviest payload here at 10 KB against nickclyde's 3.6, and costs money past a hundred searches a month.

On these numbers I would start with the free one and add the check.

The harness, the fixture and the twelve queries are at github.com/HasData/mcp-bench. Results move by IP and by day, so if yours disagree with mine I would rather know.

Zillow MCP Server Comparison: 6 Tested, 3 Actually Work

Sergey Ermakovich — Tue, 15 Sep 2026 07:57:55 +0000

The task was small. An agent in Claude Code that, given "two-bedroom rentals in Denver under $2,500", lists what is on Zillow right now and pulls the full record for anything we like. Zillow has no API for that and no MCP server of its own, so the work is choosing a third-party MCP server. We wired up six of them on 2026-09-09, ran the same rental search through each three times, and kept notes. The setup for each, what came back, and what broke.

The test

One search, rentals in Denver, CO, three calls per server, from the official MCP TypeScript SDK as a client with a 240 second timeout. We counted a call as failed when the tool returned an error, when it returned an error dressed as a normal result, or when it returned an empty list. Latency is the median of the successful calls.

| Server                  | Setup            | Denver rentals, 3 calls                      | p50    |
|-------------------------|------------------|----------------------------------------------|--------|
| HasData Zillow MCP      | hosted, API key  | 3/3, 41 rentals x 21 fields, 159 KB JSON     | 5.4 s  |
| Apify, afanasenko actor | hosted, token    | 3/3, 15 rentals x 77 fields, 42 KB JSON      | 7.2 s  |
| Apify, maxcopell actor  | hosted, token    | 3/3 in two calls, 40 rentals x 17 fields, 168 KB | 13.0 s |
| APIllow                 | local, uvx, key  | 3/3 answered, 5 results with sale prices     | 16.5 s |
| @striderlabs/mcp-zillow | local, from src  | 3/3 answered, total_found: 0                 | 4.2 s  |
| chrischall/zillow-mcp   | local, npx       | 0/6, needs your logged-in browser            | n/a    |

1. HasData

HasData's Zillow server is hosted, streamable HTTP, two tools. Add it to Claude Code with the key in a header:

claude mcp add --transport http zillow "https://mcp.hasdata.com/api/mcp?apis=zillow" \
  --header "x-api-key: $HASDATA_API_KEY"

The search tool takes a place name and a type, so the benchmark call was {"keyword": "Denver, CO", "type": "forRent"} with no translation step, the same broad query every server got. It came back in 3.5 to 8.7 seconds with 41 rentals and 21 fields each, price, beds, baths, area, address, days on Zillow, home type, the listing URL, and a total-results count. The tool also has the filters the agent needs, so the real task is one call with beds_min_ and price_max_ set, and Zillow does the narrowing:

// request
{"keyword": "Denver, CO", "type": "forRent", "beds_min_": 2, "price_max_": 2500}

// response, first listing of 41 (3,647 total)
{"id": "465129302", "price": 1595, "beds": 2, "baths": 1, "area": 805,
 "addressRaw": "975-979 S Lowell Blvd #977, Denver, CO 80219", "daysOnZillow": 0, "homeType": "APARTMENT"}

Every listing that carried a price was two bedrooms or more and $2,500 or less. Some rows are apartment buildings rather than units, with price, beds and baths as null and only an address, so the agent has to skip those or open them. The three calls returned byte-identical payloads within a minute, which reads like a short server-side cache. The property tool takes the listing URL from the search result, so the "pull the full record" half of the task is one more call, 33 fields.

The payload is the largest of the working servers, 159 KB for the page. That is the whole listing object per rental. If the agent only needs price and address it is reading more than it uses, and there is no field selector on the search tool.

Billing is one call per page whatever the page returns, 200 calls a month free and renewing, then $59 a month for 40,000 calls. For this agent that is one call per search plus one per record you open.

2. Apify, the afanasenko Zillow actor

Apify exposes any actor in its store as an MCP tool through one hosted endpoint. You pick the actors in the URL:

claude mcp add --transport http apify-zillow "https://mcp.apify.com/?tools=afanasenko/zillow-mcp-server" \
  --header "Authorization: Bearer $APIFY_TOKEN"

This actor has three tools, search by ZIP or place, search by any Zillow URL, and lookup by zpid. Denver rentals went in as a Zillow rentals URL. It returned 15 rentals with 77 fields each, the richest per-listing record of the set, 42 KB, in 6.7 to 13.4 seconds. The first fields on a Denver result were price, status, home type, coordinates, a description with the floor plans and the listing URL, and the tool's own description promises agent contact, Zestimates, HOA, tax and price history further down the record. Each call is a fresh actor run on Apify's side, so the latency floor is the run spin-up. On a ZIP search the same actor took 25 and 45 seconds for two calls and the third ran into a 120 second wall and errored.

Cost is Apify platform usage per run, and it differs a lot between actors. Six afanasenko searches across two scenarios consumed $5.25 of a $5 free month, about 87 cents a search, while three maxcopell two-step searches cost 28 cents together, about 9 cents each. The free tier is a demo for the first actor and a month of light use for the second. The afanasenko actor caps at 15 results per call in this configuration, so a 41-listing page is three calls.

3. Apify, the maxcopell Zillow scraper

Same endpoint, different actor, and a different shape. maxcopell/zillow-scraper takes a Zillow search URL that must contain searchQueryState, plus an extraction method, and returns run metadata, not listings. The listings land in a dataset that you fetch with the get-dataset-items tool in a second call, and the id for that call sits at storages.datasets.default.id in the first response. Our first attempt read the wrong field and the second call failed three times. With the right path the pair of calls completed three out of three in 12.4 to 14.5 seconds and returned 40 rentals with 17 fields each, 168 KB, the most listings per search of any server here. An agent using this actor has to know the two-step protocol, and the first response gives it nothing to reason about except a status line that says "scraped 40 items".

4. APIllow

A Zillow-only vendor with a PyPI package. The README's uvx apillow-mcp crashes on a current Python MCP SDK because the package imports FastMCP from a location that SDK 2.x renamed. Pin the SDK and it starts:

claude mcp add apillow -e APILLOW_API_KEY=$APILLOW_API_KEY -- uvx --with "mcp<2" apillow-mcp

Ten tools, seven for data (search by city, ZIP, zpid, URL, address, batch, address check). The Denver call was search_properties with type: for_rent. It answered three out of three in 7 to 17 seconds with status: complete and five properties. The prices were $525,000 and $975,000, which are sale prices, and the records had last_sold_price fields, so the rental filter did not apply and the agent got five houses for sale. The server submits a job and polls, which is where the time goes, and one earlier search hit the vendor's own 120 second job timeout.

Fifty properties a month are free, then $9.99 for 3,333. It bills per property returned, including the five wrong ones. After the allowance it keeps answering 200 with {"error": "Rate limit or quota exceeded"} in the body.

5. @striderlabs/mcp-zillow

An open-source server with Playwright and a stealth plugin, no key. npx -y @striderlabs/mcp-zillow fails because the npm package ships src/index.ts and no dist. Cloned and built it starts in under a second with five tools, search_homes, search_rentals, get_listing, get_estimates, save_home. search_rentals for Denver returned in 3 to 5 seconds with total_found: 0 all three times, and the same for sales in Phoenix and a Miami Beach ZIP. Zillow is serving its headless Chromium an empty results page, so the server is free and so is its output.

6. chrischall/zillow-mcp

The most downloaded Zillow MCP package on npm, about 1,400 a month, with 20 tools including mortgage math and saved searches. It is in the table as six failures because it cannot run where Claude Code runs. Every tool goes through a WebSocket bridge to a browser extension that uses your logged-in zillow.com session, and without a signed-in Chrome next to the client every call fails with "no confirmed browser session". Six of six here. If you only ever run Claude Desktop on the laptop where you browse Zillow, it may be the most capable free option. For anything headless it is not an option.

The build-it-yourself path

HomeHarvest is a 739-star Python library that scrapes Zillow, Realtor.com and Redfin into a DataFrame, and it is the usual answer when someone asks how to get Zillow data without a vendor. It is not an MCP server. Wrapping it in one is an afternoon with the Python SDK, and then the anti-bot problem the striderlabs server hit is yours. That is the trade, and it is the same trade every hosted server above is charging for.

What we kept

For the rental agent, HasData. Place name in, 41 rentals out, one call, every time, and the property record is the same key and one more call. The Apify actor is the one to keep around for the record depth, 77 fields per listing, when the agent already knows what it wants and can afford seven seconds and a metered run per lookup. APIllow needs a fix to its rental filter before it belongs in a rental agent. The two open-source servers that show up next to these in the catalogs are, today, a package that does not install and a package that installs and returns nothing.

All of it is one afternoon's measurement from one machine, three calls per server, and vendors change. Rerun before you commit.