Skip to main content
Glama
zouyuanqing

DeepSeek Web Search MCP

by zouyuanqing
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

DeepSeek Web Search MCP

一个独立的 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_KEY：web_research

  • ANYSEARCH_API_KEY：可选，匿名模式限额更低

  • TAVILY_API_KEY：全球搜索

  • OPENROUTER_API_KEY：web_search(rerank=true) 使用的可选重排

  • SEARXNG_URL：自建实例地址

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

本地运行

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

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

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

可选重排

web_search 默认保持快速的单 provider 降级模式。传入 rerank: true 后会并行查询范围内的多个 provider，去重形成候选集，再调用 OpenRouter 的 nvidia/llama-nemotron-rerank-vl-1b-v2:free 重排。

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

OpenRouter 缺 key、限流、超时或返回异常时，web_search 会回退到多 provider 原始顺序，并在结果中设置 rerank.applied=false 和 warning，不会让整次搜索失败。 嵌入模型不参与该链路。

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
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

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

Resources

Related MCP Connectors

Related MCP Servers

  • MCP MixSearch

    geosp
    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

  • MCP Deep Search

    just-every
    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
    221 npm
    9
    MIT