DuckDuckGo MCP Server
Provides web search, image search, and image download capabilities using the DuckDuckGo search engine.
Click on "Install 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., "@DuckDuckGo MCP Serversearch for best restaurants in Tokyo"
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.
DuckDuckGo MCP Server
A simple Model Context Protocol (MCP) server that provides web search, image search, and image download capabilities using the duckduckgo_search library.
Features
Web Search: Search the web using DuckDuckGo with customizable region and result limits
Image Search: Search for images with filters for size and type
Image Download: Download images from URLs to your local machine
Related MCP server: EZ Web Search MCP Server
Installation
Using uv (Recommended)
Install uv if you haven't already:
curl -LsSf https://astral.sh/uv/install.sh | shClone this repository or download the files
Create a virtual environment and install dependencies:
uv venv
uv pip install -r requirements.txtUsing pip
Clone this repository or download the files
Install dependencies:
pip install -r requirements.txtUsage
Running the Server
With uv (from the project directory):
uv run python server.pyOr activate the virtual environment first:
source .venv/bin/activate # On Windows: .venv\Scripts\activate
python server.pyWith standard Python:
python server.pyConfiguring in Claude Desktop
Add this configuration to your Claude Desktop config file:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Using uv (recommended):
{
"mcpServers": {
"duckduckgo-search": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/websearch_mcp",
"run",
"python",
"server.py"
]
}
}
}Using Python directly with virtual environment:
{
"mcpServers": {
"duckduckgo-search": {
"command": "/absolute/path/to/websearch_mcp/.venv/bin/python",
"args": ["/absolute/path/to/websearch_mcp/server.py"]
}
}
}Available Tools
web_search
Search the web using DuckDuckGo.
Parameters:
query(required): The search querymax_results(optional): Maximum number of results (default: 10)region(optional): Region code (default: "wt-wt" for worldwide)Examples: "us-en", "uk-en", "de-de", "fr-fr"
Example:
Search the web for "Python MCP servers" with max 5 resultsimage_search
Search for images using DuckDuckGo.
Parameters:
query(required): The image search querymax_results(optional): Maximum number of results (default: 10)size(optional): Image size filterOptions: "small", "medium", "large", "wallpaper"
type(optional): Image type filterOptions: "photo", "clipart", "gif", "transparent", "line"
Example:
Search for "cute puppies" images, large size, photo type, max 5 resultsdownload_image
Download an image from a URL to your local machine.
Parameters:
url(required): The URL of the image to downloadfilename(optional): Custom filename for the downloaded imagedownload_dir(optional): Directory to save the image (default: "./downloads")
Example:
Download image from https://example.com/image.jpg to ./my-images/Dependencies
duckduckgo_search - DuckDuckGo search library
mcp - Model Context Protocol SDK
httpx - HTTP client for downloading images
License
See LICENSE file for details.
Notes
Images are downloaded to
./downloadsby defaultThe download directory will be created automatically if it doesn't exist
Web search respects DuckDuckGo's rate limits
All searches are anonymous (no tracking)
Available Tools
3 toolsdownload_imageA
Download an image from a URL to the local machine. Returns the local file path.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the image to download | |
| filename | No | Optional filename for the downloaded image. If not provided, will use the original filename from the URL. | |
| download_dir | No | Directory to save the image (default: ./downloads) | ./downloads |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return value (local file path) but does not disclose overwrite behavior, directory creation, authentication requirements, error handling for invalid URLs, or whether the operation is synchronous. These gaps are significant for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with a secondary sentence about the return value. No wasted words; essential information is front-loaded. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 simple parameters, no nested objects, no output schema), the description covers the core purpose and return value. However, it omits important details like default behavior for filename conflicts, directory creation, error outcomes, and supported file formats. It is adequate but could be more thorough to avoid ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation coverage is 100% (all parameters have descriptions). The tool description adds no further explanation beyond stating the overall purpose. Baseline 3 is appropriate since the schema already explains each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Download'), the resource ('an image from a URL'), and the result ('Returns the local file path'). It effectively distinguishes from sibling tools (image_search, web_search) which are search-oriented, not download-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to save an image locally from a given URL. However, it does not explicitly state when not to use it or mention alternatives. The context of siblings being distinct search tools provides indirect guidance, but explicit usage conditions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image_searchA
Search for images using DuckDuckGo. Returns a list of image results with URLs, titles, and sources.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Image size filter (small, medium, large, wallpaper) | |
| type | No | Image type filter (photo, clipart, gif, transparent, line) | |
| query | Yes | The image search query | |
| max_results | No | Maximum number of results to return (default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses the return format but lacks details on behavior: no info on rate limits, safety (likely read-only), pagination, or authentication. It relies on the service name (DuckDuckGo) for implicit trust, but more explicit transparency would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the primary action and return value. No unnecessary words, but it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (including enums) and no output schema, the description is minimal. It doesn't mention filters like size or type, though the schema covers them. The agent may need to inspect the schema to understand filtering capabilities, making the description incomplete for quick decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 100%, so baseline 3. The description adds no parameter-specific meaning beyond what the schema provides, merely confirming the tool's purpose. No additional context for the enums or the max_results default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Search' and the resource 'images using DuckDuckGo', clearly differentiating from sibling tools (e.g., web_search for general web, download_image for downloading). It also specifies the return type: a list with URLs, titles, and sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. alternatives (e.g., web_search). While the name and description imply image-specific search, it doesn't exclude cases where general web search might be better, nor does it mention limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchA
Search the web using DuckDuckGo. Returns a list of search results with titles, URLs, and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query | |
| region | No | Region for search results (e.g., 'us-en', 'uk-en', 'de-de'). Default: 'wt-wt' (worldwide) | wt-wt |
| max_results | No | Maximum number of results to return (default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool uses DuckDuckGo and returns a list of results, but does not mention rate limits, read-only nature, or other limitations. The behavioral information is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action and result, and contains no unnecessary words. It effectively conveys the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, high schema coverage, and lack of output schema, the description sufficiently covers the tool's functionality and return value. It could mention that it's a web search (not image-specific) for extra clarity, but it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds minimal extra meaning beyond the schema, such as the search engine used (DuckDuckGo) and return format, but does not elaborate on parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'the web using DuckDuckGo', and specifies the return type (list with titles, URLs, descriptions). It is clearly distinguishable from sibling tools like image_search and download_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general web search but does not explicitly state when to use this tool over siblings (e.g., for image searches, use image_search instead). No when-not or alternatives are provided.
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. Dates show when Glama detected each change.
3 tool updates
v0.1.0- First observed
download_image - First observed
image_search - First observed
web_search
TDQS
Each tool has a distinct purpose: web_search for web results, image_search for image results, and download_image for saving images locally. No overlap.
All tools follow the same verb_noun snake_case pattern: download_image, image_search, web_search.
Three tools are well-scoped for a search server covering web search, image search, and image downloading. Not too few or too many.
Core search and download functionality is covered. Minor gaps exist (e.g., no video or news search), but the surface is sufficient for basic DuckDuckGo tasks.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Serper MCP — wraps the Serper Google Search API (serper.dev)
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server for deep research or task groups
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceMCP server that enables web search via DuckDuckGo and readable content extraction from HTML pages using FastMCP.-
- FlicenseAqualityDmaintenanceA simple MCP server that provides web search functionality via DuckDuckGo, returning titles, URLs, and descriptions for results. Configurable result limit.1-
- FlicenseNot gradedqualityDmaintenanceMCP server that provides web search scraping from DuckDuckGo (with Mojeek fallback) and URL content fetching as markdown/text or raw HTML.1-
- AlicenseNot gradedqualityBmaintenanceA lightweight MCP server providing web search via DuckDuckGo and page content extraction in multiple formats.2MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zopalz/websearch_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server