Skip to main content
Glama
zouyuanqing

DeepSeek Web Search MCP

by zouyuanqing

DeepSeek Web Search MCP

M8ven Verified

一个独立的 stdio MCP 服务器,向 Codex 等客户端暴露两个工具:

  • web_search:AnySearch、SearXNG、Tavily 的统一原始检索接口。

  • web_research:通过 DeepSeek 官方 Anthropic 兼容 Messages API 调用 web_search_20250305,返回回答、结构化来源和引用摘要。

DeepSeek 协议

DeepSeek Responses API 当前会静默忽略 web_search。正确入口是:

https://api.deepseek.com/anthropic/v1/messages

请求使用 web_search_20250305 服务端工具。只有响应中存在 web_search_tool_result 才视为搜索成功;DSML、模型自述或普通文本都不能作为 搜索成功证据。

实现契约参考 DeepSeek 官方 Harness 的 @deepseek-ai/dsh-web-search-deepseek 包。

仓库不包含 API Key、服务器地址、用户名或私钥。所有凭据均从进程环境读取。

Related MCP server: MCP MixSearch

构建

npm install
npm run build
npm test

配置

复制 .env.example 中的变量到进程环境或 Windows 用户环境。至少需要:

  • DEEPSEEK_API_KEYweb_research

  • ANYSEARCH_API_KEY:可选,匿名模式限额更低

  • TAVILY_API_KEY:全球搜索

  • OPENROUTER_API_KEYweb_search(rerank=true) 使用的可选重排

  • SEARXNG_URL:自建实例地址

DEEPSEEK_SEARCH_BASE_URL 是 Anthropic SDK 的 base URL,SDK 会自动追加 /v1/messages。默认值是 https://api.deepseek.com/anthropic

隐私

本项目不收集也不上传任何遥测数据。查询只会发送给你自己配置的检索/重排提供商, 凭据仅从进程环境读取,缓存只存在于内存。详见 PRIVACY.md

本地运行

npm run doctor -- --json
node dist/index.js

--doctor 只在终端输出各 provider 的健康状态,不会把健康检查注册成第三个 MCP 工具。

搜索查询会发送给用户配置的搜索提供商;启用重排后,候选结果摘要还会发送给 OpenRouter。项目本身不包含遥测。

质量控制与融合重排

web_search 默认使用 quality: "fast",保持快速的单 provider 降级模式,不把 查询或来源发送给 OpenRouter。

quality

provider 候选

候选目标

行为

fast

每路 10

10

按 provider 顺序降级,不重排

balanced

每路 10

20

并行检索、重排并做 50/50 rank fusion

deep

每路 15

30

更大候选集、重排并做 50/50 rank fusion

重排使用 OpenRouter 的 nvidia/llama-nemotron-rerank-vl-1b-v2:free。融合同时保留原始排名和重排排名, 对官方域名给予有限先验,并保护原本可靠的第一名不被轻易降级。

{
  "query": "DeepSeek Responses API web_search 是否已经失效",
  "scope": "global",
  "max_results": 8,
  "quality": "balanced"
}

OpenRouter 缺 key、限流、超时或返回异常时,web_search 会回退到多 provider 原始顺序,并在结果中设置 rerank.applied=false 和 warning,不会让整次搜索失败。 旧的 rerank: true 仍作为兼容别名映射到 balanced;显式 quality 优先。

provider 搜索结果在进程内缓存 10 分钟,重排结果缓存 30 分钟,均采用有上限的 TTL/LRU,不写入磁盘。MCP 进程重启后缓存清空。嵌入模型不参与该链路。

Available Tools

2 tools
web_researchWeb ResearchC

Use DeepSeek native web search to research a question and return citeable sources.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
freshnessNoany
max_sourcesNo

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'native web search' and 'citeable sources' but does not disclose whether the tool performs live web access, how sources are selected, whether results are cached, or any rate limits or failure modes. For a research tool, 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.

Conciseness4/5

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

The description is a single, front-loaded sentence that conveys the core purpose and outcome without waste. It earns its place, though it could add a brief usage note without becoming bloated.

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 0% parameter coverage, the description is too thin. An agent cannot tell how to interpret the response, what 'citeable sources' means structurally, or how freshness and max_sources affect behavior. The sibling web_search also creates a routing ambiguity that is not resolved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the three parameters. It does not explain the meaning of 'freshness' or 'max_sources', nor how they affect the research output. The query parameter is obvious from the description, but the other two are left entirely to the schema's enum and default values.

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 states a specific verb ('research'), a resource ('DeepSeek native web search'), and an outcome ('return citeable sources'). It is clear enough to distinguish from a generic search tool, though it does not explicitly name the sibling web_search or explain how it differs.

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 for research questions requiring citeable sources, but it does not explicitly state when to use this tool versus web_search, nor does it mention any exclusions or alternatives. The context signal of a sibling tool named web_search makes this gap noticeable.

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 updatesv1.0.0
    • First observedweb_research
    • First observedweb_search

TDQS

C2.8/5.0

Scored across 2 tools

Disambiguation2/5

Both `web_search` and `web_research` say they search the live web and return citeable sources, so an agent has little basis to choose between them. The descriptions overlap heavily and do not clearly define a simple-search versus deep-research boundary.

Naming Consistency5/5

Both tool names follow the same lowercase `web_<verb>` pattern, which is predictable and consistent. Although `search` and `research` are semantically close, the naming convention itself is uniform.

Tool Count3/5

Two tools is on the thin side for a web search server, and the second tool appears to be a near-duplicate of the first. Still, two tools is a defensible minimal set for a simple query-and-results workflow.

Completeness3/5

The server covers basic live-web searching and question-style research, but there are no tools for fetching specific URLs, filtering results, or managing research sessions. Deeper research workflows would likely need workarounds.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Enables advanced web search across multiple search engines (Brave, DuckDuckGo, Google, Bing, Yandex) with intelligent backend selection, full content extraction, and advanced filtering by time, language, geography, and content type.
    3
    MIT
  • A
    license
    B
    quality
    B
    maintenance
    Enables deep web search across multiple providers including Google, Bing, Brave, DuckDuckGo, and Perplexity, with support for comprehensive AI-powered research using intelligent multi-engine queries.
    2
    47 npm
    9
    MIT