This server provides multi-backend web search and URL content fetching via MCP, powered by DeepSeek V4-Flash and Xiaomi MiMo.
web_search: Standard DeepSeek search with automatic query planning, source verification, and cited results.
web_search_fast: Fast search for time-sensitive queries; concise answers after 1–2 searches.
web_search_deep: Deep search that breaks queries into sub-queries, cross-verifies, and synthesizes comprehensive cited answers.
fetch_page: Fetches and extracts content from URLs, converting HTML/JSON to text with SSRF protection.
mimo_search / raw retrieval: Raw web retrieval similar to Tavily, returning structured source lists and summaries without further orchestration.
health: Checks API keys and search/fetch functionality.
Also supports location-aware searching, automatic fallback from DeepSeek to MiMo, and configuration of API keys, models, timeouts, and output lengths.
Provides web search integration with Xiaomi's MiMo API, enabling raw search results with structured sources, summaries, location-based customization, and fallback search support.
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., "@deepseek-search-mcp What are the latest developments in quantum computing?"
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.
多后端联网搜索 MCP 服务器：DeepSeek V4-Flash 全自动搜索 + 小米 MiMo 原始检索 + fetch_page 来源验证，带自动降级链与位置定制化搜索。
零依赖：纯 Python 标准库（≥3.9），无第三方包
协议自实现：stdio + JSON-RPC 2.0，兼容 Claude Desktop / Codex / Cherry Studio / Hermes 等客户端
自动降级：BACKEND=auto 时 DeepSeek 失败自动切 MiMo，结果标注实际后端
位置搜索：location 参数（结构化对象或自由文本）本地化检索
MCP 客户端（LLM 决策与提问）
│ stdio, JSON-RPC 2.0
▼
deepseek_web_search_mcp.py（入口）→ mcp_search 包
├─ providers.py DeepSeekClient（全自动）· MimoClient（raw）· FallbackChain
├─ models.py 统一模型：Location / Citation / SearchResult
├─ fetch.py fetch_page（HTML/JSON → 文本，SSRF 防护）
└─ server.py MCP 协议 + 工具注册 + 深搜编排
│
├─ DeepSeek Responses API（原生 web_search 工具，多轮核实 + 带引用合成）
└─ MiMo Chat Completions API（web_search 工具，结构化来源 + user_location）Related MCP server: Percival Deep Research
工具 | 模式 | 用途 | 耗时 |
| DeepSeek 全自动 | 日常查询、新闻、事实确认 | 30–60s |
| 快速 | 时效敏感的快查 | 3–8s |
| 深搜 | 事实核查、调研报告（子查询拆解 + 交叉核验） | 3–10 分钟 |
| raw 检索 | 类似 Tavily：结构化来源列表 + 摘要，不编排 | 20–40s |
| 基础 | 抓取 URL 验证来源真实内容 | 1–10s |
| 诊断 | 验证各后端与 fetch 链路 | 30–60s |
location（三个搜索工具通用，可选）：{"country":"中国","region":"湖北","city":"武汉"} 或 "湖北省武汉市" / "Wuhan, Hubei, China"。MiMo 映射 user_location（实测显著提升本地结果），DeepSeek 注入查询上下文。
web_search_deep 的 enrich_mimo（可选，默认 false）：每路子查询额外注入 MiMo raw 结果作为补充来源，DeepSeek 定"准确性"、MiMo 补"覆盖面"。
mimo_search 的 fast / max_keyword / limit（可选）：控制检索成本（默认 5/5，fast 减半）。
fetch_page 的 max_chars（可选，默认 20000）：提取文本上限。
export DEEPSEEK_API_KEY="sk-..." # DeepSeek 全自动搜索（必填其一）
export MIMO_API_KEY="sk-..." # MiMo raw 检索 / 降级兜底
python deepseek_web_search_mcp.py --health # 健康检查
python deepseek_web_search_mcp.py # 作为 MCP 服务器运行（stdio）变量 | 默认 | 说明 |
|
|
|
| — | DeepSeek API Key |
|
| Responses API 目前仅支持该模型 |
|
| HTTP 超时（秒） |
|
| 标准/深搜合成答案的最大输出 token |
|
| 快速模式最大输出 token |
| — | 小米 MiMo API Key（platform.xiaomimimo.com） |
|
| 联网搜索支持 |
|
| 强制联网搜索（不依赖模型意图判断） |
|
| 每轮搜索关键词数 / 结果条数（fast 减半） |
|
| 搜索时 prompt 会拼接结果，过小会截断（ |
|
| fetch_page 超时与提取上限 |
|
| 设为 |
|
| 设为 |
以 Claude Desktop 的 claude_desktop_config.json 为例：
{
"mcpServers": {
"deepseek-search": {
"command": "python",
"args": ["/absolute/path/to/deepseek_web_search_mcp.py"],
"env": {
"DEEPSEEK_API_KEY": "sk-...",
"MIMO_API_KEY": "sk-...",
"BACKEND": "auto"
}
}
}
}超时：标准模式 30–60s、深搜最长 10 分钟，客户端侧超时需配置足够长（opencode 为
experimental.mcp_timeout，单位毫秒）。
mcp_search/ # models / providers / fetch / server
tests/ # 99 个用例：单元（mock）+ 集成（本地 HTTP）+ stdio 端到端
mcp_client.py # 通用 MCP stdio 客户端，可调任意工具# 全量测试（配置任一 API Key 后自动包含真实搜索用例）
python -m unittest discover -s tests -p "test_*.py"
# 手动调用示例
python mcp_client.py --cmd "python" --args "deepseek_web_search_mcp.py" \
--tool mimo_search --params-file params.json \
--env "MIMO_API_KEY=sk-..." --env "BACKEND=auto" --timeout 600可靠性设计：网络错误/5xx/429/空结果自动重试；深搜规划失败自动回退默认子查询拆解、综合失败降级为结果汇总；断连自动走降级链。详见 TESTING.md。
DeepSeek Responses API 仅支持 deepseek-v4-flash；MiMo 联网搜索需 mimo-v2.5 系列并在控制台启用联网插件（启停有约 5 分钟缓存期）。
MiMo 请求显式禁用 thinking（默认开启时偶发返回空 content）。
fetch_page 无法提取 JS 动态渲染页（SPA）正文，返回明确提示；SSRF 防护默认拒绝内网地址。
mimo_search 的答案摘要可能被截断（finish_reason: length），需更长输出请调大 MIMO_MAX_OUTPUT。
notifications/initialized 无响应，客户端不能同步等待。
MIT
健康检查：验证 DeepSeek API key 与联网搜索能力是否可用。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It states what is verified (API key and search capability) but does not mention whether the operation is read-only, what the response format is, or how failures are reported. This is a significant gap for a tool that may reveal system status.
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, concise sentence that front-loads the primary purpose. No unnecessary words or repetition, making it highly scannable.
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 health check with no parameters and no output schema, the description should explain what the user gets back (e.g., a status report or boolean). This is missing, though the tool's simplicity somewhat mitigates the impact. The absence of annotations also reduces completeness.
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?
The tool has zero parameters, and the schema coverage is 100%, so the baseline is 4. The description adds no parameter-specific details, which is acceptable since none exist.
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 explicitly states that this tool performs a health check to verify the DeepSeek API key and web search capability. This is a specific verb+resource combination, and it clearly distinguishes itself from sibling web_search tools by focusing on verification rather than performing searches.
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 purpose implies usage for pre-checking API connectivity and search availability, but there is no explicit guidance on when to use it versus the sibling search tools. A clear statement like 'use this before other tools to ensure credentials are valid' would improve this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
联网搜索（标准模式）。基于 DeepSeek V4-Flash 原生联网搜索：自动规划多次搜索、阅读并核实来源、返回带引用的结构化答案。适合日常查询、新闻、事实确认。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 要搜索的问题或主题，建议写成完整问题以提高相关性（例："2026年8月特斯拉股价走势如何？"） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the tool's core behavior: it automatically plans multiple searches, reads and verifies sources, and returns cited structured answers. This gives the agent operational expectations, though it does not address rate limits or failure modes.
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 concise Chinese sentences: first establishes the tool and its mechanism, second states use cases. No filler; every sentence carries meaning.
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 one-parameter search tool with no output schema, the description covers what it does, how it works, output format, and appropriate contexts. This is sufficient for an agent to select and invoke correctly.
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?
The schema already fully describes the 'query' parameter with a usage suggestion (complete question). The tool description adds no additional parameter-level detail beyond the schema, so baseline score applies.
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 tool performs standard online search, with specific behavioral details (multi-search planning, source verification, cited structured answers). The 'standard mode' phrasing hints at differentiation from siblings fast/deep, but it does not explicitly name them as alternatives.
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?
It specifies suitable use cases (daily queries, news, fact confirmation), giving the agent clear context for when to select this tool. However, it does not provide explicit exclusions or contrast with web_search_fast/web_search_deep.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
深度联网搜索（高准确性模式）。先把问题拆解为多个子查询分别检索，再由 DeepSeek V4-Flash 交叉核验、综合成带引用的最终答案。适合事实核查、研究报告、技术调研、需要多来源验证的场景。耗时更长。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 要深度调研的问题，需具体、可拆解（例："DeepSeek V4-Flash 正式版相比预览版有哪些能力变化？"） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the multi-step behavior (sub-queries, cross-verification, synthesis) and the output characteristic (citations), plus the latency trade-off. It doesn't mention error handling or rate limits, but this is a search tool, so coverage is solid.
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?
Three concise sentences: first states the purpose and mode, second explains the process and output, third lists use cases and the trade-off. Every sentence earns its place, and the structure is front-loaded with the key identity.
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 single-parameter search tool with no output schema or annotations, the description covers the mode, process, use cases, and latency. It doesn't explicitly state return structure beyond 'citations', but it's sufficiently complete for an agent to invoke it correctly.
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?
The input schema provides 100% coverage for the single 'query' parameter, including guidance to be specific and decomposable. The tool description's mention of decomposing into sub-queries reinforces this but adds no new parameter-level detail beyond the schema.
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 that this is a deep, high-accuracy web search mode that decomposes questions into sub-queries and synthesizes cited answers. It distinguishes itself from faster siblings by emphasizing accuracy and longer runtime, though it doesn't explicitly name alternatives.
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?
It explicitly lists suitable use cases: fact-checking, research reports, technical research, and multi-source verification. It also warns that it takes longer, implying faster alternatives exist, but it doesn't explicitly say when not to use it or name sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
联网搜索（快速模式）。使用低推理强度 + 精简指令优先响应速度，通常 1-2 轮搜索后直接给出简洁答案。适合对时效敏感、无需深度核验的查询。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 要搜索的问题或主题（例："2026年8月9日美元兑人民币汇率"） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses low reasoning intensity, expected 1-2 search rounds, and concise answer style, offering useful insight into trade-offs. It doesn't discuss error behavior or exact output structure, but the disclosed trade-offs are sufficient for a fast search 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 two sentences long, front-loads the purpose, and packs relevant details about usage and behavioral trade-offs without extraneous words.
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 simple one-parameter search tool with no output schema or annotations, the description adequately covers purpose, usage, and behavior. The phrase '直接给出简洁答案' (directly gives a concise answer) hints at the response format, making it complete enough for an agent to select and invoke correctly.
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% for the single 'query' parameter, with a description and example provided. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 this is a web search tool with a fast mode, distinguishing it from siblings through speed and low reasoning intensity. The verb '联网搜索' (web search) and modifier '快速模式' (fast mode) make the purpose unambiguous.
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?
Explicitly states it is suitable for time-sensitive queries that don't require deep verification, which provides a clear 'when to use'. This also implies not using it for deep verification, effectively giving a when-not via context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0healthweb_searchweb_search_deepweb_search_fastScored across 4 tools
The three search variants are clearly differentiated by depth and use case (standard, fast, deep), though an agent might occasionally hesitate between web_search and web_search_deep. health is obviously distinct.
Names use a consistent web_search_* pattern with fast/deep modifiers, plus a single health tool. Minor deviation: health doesn't follow the web_search prefix, but it's a different concern.
Four tools is appropriate for a search-focused server, covering three modes of the core operation and one utility. No bloat or thinness.
The domain is web search, and the server provides standard, fast, and deep modes plus health. No obvious missing capability within that scope, though one could imagine a continuous or batch mode.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
An MCP server for deep research or task groups
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
