A
licenseA
qualityA
maintenanceA Model Context Protocol (MCP) server that provides web search capabilities through DuckDuckGo, with additional features for content fetching and parsing.
3
20,256 PyPI
1,460
MIT
duck-poacher-mcp
by lars-dreier
Provides web and image search capabilities using DuckDuckGo's search engine.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@duck-poacher-mcpsearch the web for recipes for gluten-free pasta"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
duck-poacher-mcp
A Model Context Protocol server that exposes
DuckDuckGo web and image search to MCP clients (Claude Desktop, Claude Code, and
others). It wraps the duck-poacher
scraper.
Tools
Tool | Arguments | Returns |
|
| JSON array of |
|
| JSON array of |
Both tools return their results as a JSON string. A failed
scrape (token/URL could not be read, upstream HTTP error) comes back as a tool
result with isError: true and the message.
Related MCP server: DuckDuckGo MCP Server
Use with an MCP client
Run the published binary over stdio. With Claude Code:
claude mcp add duck-poacher -- npx -y duck-poacher-mcpOr configure it directly (e.g. Claude Desktop's claude_desktop_config.json):
{
"mcpServers": {
"duck-poacher": {
"command": "npx",
"args": ["-y", "duck-poacher-mcp"]
}
}
}LM Studio
Edit LM Studio's mcp.json (Program tab → Edit mcp.json) and add the same entry:
{
"mcpServers": {
"duck-poacher": {
"command": "npx",
"args": ["-y", "duck-poacher-mcp"]
}
}
}Develop
npm install
npm test # live integration specs — hit DuckDuckGo, need network
npm run build # bundle to dist/ (ESM), bin → dist/cli.mjsInspect the tools interactively with the MCP Inspector:
npm run build
npx @modelcontextprotocol/inspector node dist/cli.mjsSee .claude/documentation/ for the code-style
and testing conventions this project follows.
License
ISC © Lars Dreier
Available Tools
2 toolsimage_searchDuckDuckGo image searchA
Search for images via DuckDuckGo. Returns a page of results, each with an image URL and a thumbnail URL, plus pagination metadata. Supports optional filters for time, size, color, type, layout, and license. Results are cached for an hour; request later pages of the same query and filters with page to read more without re-searching.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number; 10 results per page. | |
| size | No | Filter by image size. | |
| time | No | Restrict results to the last day, week, or month. | |
| type | No | Filter by image type. | |
| color | No | Filter by color or monochrome images. | |
| query | Yes | The search terms to look up on DuckDuckGo. | |
| layout | No | Filter by image orientation. | |
| license | No | Filter by license. | |
| safeSearch | No | Enable or disable safe search. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, but description discloses caching (1 hour), pagination metadata, and output structure (image URL, thumbnail URL). Lacks details on rate limits or error handling, which would raise the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information: purpose, output, filters, and caching behavior. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately describes return value (image URL, thumbnail, pagination metadata). Covers input, behavior, and output sufficiently for an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds value by summarizing filter options and explaining pagination usage ('request later pages with page without re-searching'), going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for images via DuckDuckGo, uses specific verb 'Search' and resource 'images', and is distinct from sibling 'web_search' which handles web results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on pagination and caching (use 'page' to get subsequent pages without re-searching), but does not explicitly compare with sibling 'web_search' or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchDuckDuckGo web searchA
Search the web via DuckDuckGo. Returns a page of results, each with a title, URL, and description, plus pagination metadata. Results are cached for an hour; request later pages of the same query with page to read more without re-searching.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number; 10 results per page. | |
| query | Yes | The search terms to look up on DuckDuckGo. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses caching behavior and pagination structure, though no mention of rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return format and pagination metadata; no output schema, but description covers key outputs. Could mention source or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with descriptions; the description adds behavioral context (caching, pagination) but not new parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Search the web via DuckDuckGo' with a specific verb and resource, and sibling 'image_search' clarifies scope difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit pagination usage with caching hint, but doesn't explicitly state when to use web_search vs image_search beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
image_search - First observed
web_search
TDQS
A4.2/5.0
Scored across 2 tools
Disambiguation5/5
The two tools are clearly distinct: one returns text results, the other returns image results. There is no overlap in purpose or output.
Naming Consistency5/5
Both tools follow a consistent verb_noun pattern (web_search, image_search), making their actions and targets immediately clear.
Tool Count3/5
With only two tools covering web and image search, the count is minimal but not unreasonable for a focused search server. It feels slightly thin but not extreme.
Completeness3/5
The tool set covers basic text and image search, but lacks common search types like news or video. The absence of these creates notable gaps for a general-purpose search server.
Maintenance
ActivityStale
ResponsivenessNo issues
Related MCP Connectors
MCP server for Google search results via SERP API
Agentic search over your Dewey document collections from any MCP-compatible client.
Serper MCP — wraps the Serper Google Search API (serper.dev)
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI applications like Claude Desktop and Cursor IDE to perform web searches via DuckDuckGo's search engine.-
- AlicenseNot gradedqualityDmaintenanceSmall Python MCP server that provides web search and page fetching tools via DuckDuckGo, requiring no API key.Apache 2.0
- AlicenseAqualityCmaintenanceMCP server that enables web search, image search, and image download using DuckDuckGo.3MIT