Skip to main content
Glama
enesjakozh
kouui

DuckDuckGo Web Search MCP Server

by kouui
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

DuckDuckGo 웹 검색 MCP 서버

이 프로젝트는 DuckDuckGo 검색 엔진을 사용하여 웹을 검색하고, 선택적으로 발견된 URL의 내용을 가져와 요약할 수 있는 MCP(Model Context Protocol) 서버를 제공합니다.

특징

  • 웹 검색: DuckDuckGo를 사용하여 웹을 검색하세요.

  • 결과 추출: 검색 결과에서 제목, URL, 스니펫을 추출합니다.

  • 콘텐츠 가져오기(선택 사항): 검색 결과에서 찾은 URL의 콘텐츠를 가져와서 Jina API를 사용하여 마크다운 형식으로 변환합니다.

  • 병렬 가져오기: 더 빠른 처리를 위해 여러 URL을 동시에 가져옵니다.

  • 오류 처리: 검색 및 페칭 중에 발생하는 시간 초과 및 기타 잠재적 오류를 우아하게 처리합니다.

  • 구성 가능: 반환되는 검색 결과의 최대 수를 설정할 수 있습니다.

  • Jina API : Jina API를 사용하여 HTML을 마크다운으로 변환합니다.

  • MCP 호환 : 이 서버는 모든 MCP 호환 클라이언트와 함께 사용하도록 설계되었습니다.

Related MCP server: DuckDuckGo MCP Server

용법

  1. 필수 조건:

    • uvx 패키지 관리자

  2. 클로드 데스크톱 구성

    • Claude Desktop을 사용하는 경우 claude_desktop_config.json 파일에 서버를 추가할 수 있습니다.

    지엑스피1

    위의 구성이 작동하지 않으면 로컬 PC에 저장소를 복제하고 다음 구성을 사용해야 할 수 있습니다.

    {
    "mcpServers": {
        "web-search-duckduckgo": {
            "command": "uv",
            "args": [
                "--directory",
                "/path/to/web-search-duckduckgo",
                "run",
                "main.py"
            ]
        }
    }
}

  3. 도구

    • MCP 클라이언트(예: Claude)에서 이제 다음 도구를 사용할 수 있습니다.

    • search_and_fetch : 웹을 검색하고 URL의 내용을 가져옵니다.

      • query : 검색 쿼리 문자열.

      • limit : 반환할 결과의 최대 개수(기본값: 3, 최대값: 10).

    • fetch : 특정 URL의 콘텐츠를 가져옵니다.

      • url : 가져올 URL입니다.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여됩니다. (라이선스를 지정하려면 라이선스 파일을 추가하세요.)

Available Tools

2 tools
fetchC
scrape the html content and return the markdown format using jina api.

Args:
    url: The search query string

Returns:
    text : html in markdown format
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions using the Jina API and the transformation to markdown format, but doesn't disclose important behavioral traits: rate limits, authentication requirements, error handling, whether this makes external network calls, or what happens with invalid URLs. For a tool that performs web scraping with an external API, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief but has structural issues. The first sentence is clear, but the 'Args:' and 'Returns:' sections use inconsistent formatting and terminology ('search query string' for a URL parameter). While concise, it could be more effectively structured with clearer separation of concerns.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and a tool that performs web scraping via an external API, the description is incomplete. It doesn't address important contextual aspects: error conditions, rate limits, authentication, what types of URLs are supported, or the structure/limitations of the returned markdown. For a tool with external dependencies and potential complexity, this is inadequate.

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?

The description adds minimal parameter semantics beyond the schema. With 0% schema description coverage, the description states 'url: The search query string' which is somewhat confusing (calling it a 'search query string' when it's clearly a URL parameter). It doesn't explain URL format requirements, validation, or provide examples. The baseline would be lower given the coverage gap, but it does at least identify the parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'scrape the html content and return the markdown format using jina api.' It specifies the verb (scrape/return), resource (html content), and transformation (to markdown format). However, it doesn't explicitly differentiate from its sibling tool 'search_and_fetch' - we can infer it's a direct fetch while the sibling might search first, but this isn't stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention the sibling tool 'search_and_fetch' or explain when direct fetching is appropriate versus searching and fetching. There's no context about prerequisites, limitations, or appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_and_fetchA
Search the web using DuckDuckGo and return results.

Args:
    query: The search query string
    limit: Maximum number of results to return (default: 3, maximum 10)

Returns:
    List of dictionaries containing 
    - title
    - url
    - snippet 
    - summary markdown (empty if not available)
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
limitNo

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the search engine (DuckDuckGo) and return format, but doesn't mention rate limits, authentication needs, error conditions, or whether this is a read-only operation. The behavioral disclosure is adequate but incomplete.

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?

The description is well-structured with clear sections (Args, Returns) and front-loaded purpose. Every sentence earns its place - no redundant information. The formatting with bullet points enhances readability without unnecessary verbosity.

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?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description provides good coverage of purpose, parameters, and return format. It could benefit from more behavioral context (like rate limits or error handling) but is largely complete for a search 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?

The description adds significant value beyond the 0% schema coverage by explaining both parameters: 'query' as the search string and 'limit' with its default (3) and maximum (10) values. This compensates well for the lack of schema descriptions, though it doesn't cover all potential edge cases.

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's purpose with specific verb ('Search the web using DuckDuckGo') and resource ('return results'). It distinguishes from the sibling 'fetch' tool by specifying it's a search operation rather than a direct fetch operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (searching the web) but doesn't explicitly state when to use this tool versus the 'fetch' sibling. It provides basic parameter guidance but lacks explicit alternatives or exclusion criteria.

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.

  1. 2 tool updates
    • First observedfetch
    • First observedsearch_and_fetch
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

B3.3/5.0

Scored across 2 tools

Disambiguation4/5

The two tools have distinct primary purposes: 'search_and_fetch' performs web searches and returns results, while 'fetch' scrapes HTML content from a given URL. However, there is some potential for confusion because 'fetch' accepts a 'url' argument but its description mentions 'search query string' (likely a documentation error), which could blur the boundary between searching and fetching.

Naming Consistency4/5

The tool names follow a consistent verb-based pattern ('fetch' and 'search_and_fetch'), with clear action-oriented naming. The minor deviation is that 'search_and_fetch' uses an 'and' conjunction, but overall the naming is readable and predictable.

Tool Count3/5

With only 2 tools, the server feels thin for a web search and scraping domain. While it covers basic search and fetch operations, more tools (e.g., for advanced search filtering, caching, or handling different content types) would provide better scope. It's borderline but not severely lacking.

Completeness3/5

The server covers core web search and content fetching workflows, but there are notable gaps. For example, it lacks tools for managing search history, refining queries, handling pagination, or supporting different output formats beyond markdown. Agents can work around these, but the surface is not fully comprehensive.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • DuckDuckGo MCP Server

    988664li-star
    A
    license
    B
    quality
    D
    maintenance
    Enables web search through DuckDuckGo and webpage content fetching with intelligent text extraction. Features built-in rate limiting and LLM-optimized result formatting for seamless integration with language models.
    2
    MIT

  • Web Search MCP

    pranavms13
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables web searching through Google, DuckDuckGo, and Bing using a headless Chrome browser, returning structured results with titles, URLs, and snippets. Also supports fetching and extracting text content from any webpage.
    16
    MIT

Appeared in Searches