deepseek-search-mcp
Click on "Deploy 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-mcpsearch for the latest DeepSeek API news"
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.
deepseek-search-mcp
一个基于 DeepSeek Search API 的 MCP(Model Context Protocol)服务器,通过 stdio 为 AI Agent 提供实时网页搜索与网页抓取能力。
工具
工具 | 说明 | 参数 |
| 搜索网页,返回标题、链接、摘要、正文等内容 |
|
| 抓取网页,返回页面标题与 Markdown 格式的内容 |
|
Related MCP server: searxNcrawl
安装
需要 Node.js 20+ 和一个 DeepSeek API Key。
在 MCP 客户端(如 VS Code、Claude Desktop 等)的配置文件中添加:
{
"servers": {
"deepseek-search": {
"type": "stdio",
"command": "npx",
"args": ["-y", "github:aimmetal-tech/deepseek-search-mcp"],
"env": { "DS_API_KEY": "sk-xxxx" }
}
}
}把 sk-xxxx 替换为你自己的 API Key。npx 会自动克隆仓库、安装依赖并构建,无需手动操作。
本地开发
git clone https://github.com/aimmetal-tech/deepseek-search-mcp.git
cd deepseek-search-mcp
npm install
cp .env.example .env # 填入 DS_API_KEY
npm run devAPI 文档
本项目基于 DeepSeek 官方的 Search 与 Fetch 接口:
License
Available Tools
2 toolsfetchDeepSeek Web FetchC
抓取网页,返回页面标题与 Markdown 格式的内容
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only discloses the return format. It says nothing about rate limits, redirect handling, dynamic/JS-rendered pages, truncation, or failure behavior for a network operation.
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?
A single tight sentence with the verb front-loaded and no filler. Efficient, though brevity comes at the cost of omitted parameter and usage detail.
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 tool with no output schema or annotations, stating the return shape (title + Markdown) is a useful addition. However, it leaves the URL format and the fetch-vs-search routing unexplained, so it is only minimally 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 0% for the single required 'url' parameter, and the description only implies a webpage target without specifying format (http/https), the 8192-char max, or whether it accepts non-URL inputs. It adds almost no meaning beyond the parameter name.
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?
States a specific verb (抓取) and resource (网页) plus the return payload (title + Markdown content). It does not explicitly contrast with the sibling 'search', so differentiation is only implicit, but the core action is 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?
No guidance on when to use fetch versus the sibling 'search', and no prerequisites (e.g. requiring a full URL vs a search query) are given. The agent must infer the use case from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchDeepSeek Web SearchC
搜索网页
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no indication of whether results are live/real-time, how many are returned, whether there is a rate limit, or what the output looks like. It only implies an external web query.
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 short phrase with no filler and is fully front-loaded. It is concise, though arguably too sparse to be useful rather than padded.
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 an external search tool with no output schema and no annotations, the description should at least indicate the nature of results or how it differs from 'fetch'. It leaves the agent without enough to call it confidently in a multi-tool context.
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 0% and there is a single undocumented 'query' parameter. The description does not explain what the query should contain or any format expectations, adding no meaning beyond the parameter name.
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 Chinese phrase '搜索网页' gives a clear verb (search) and resource (web pages), so the agent knows this is a web search tool. It does not, however, distinguish itself from the sibling 'fetch', leaving the search-vs-retrieve boundary unstated.
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?
There is no guidance on when to use this tool versus the sibling 'fetch', nor any mention of query formulation, freshness, or result limits. Usage context is entirely left to inference.
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.
2 tool updates
v0.0.1- First observed
fetch - First observed
search
TDQS
Scored across 2 tools
search and fetch have clearly distinct purposes: one locates web results, the other retrieves a specific page's content. There is no meaningful overlap in how an agent would select between them.
Both names are lowercase single verbs, which is consistent and readable. However, there is no object/noun component to make the pattern as predictable as a verb_noun convention.
Two tools is slightly thin, but this server has a narrowly scoped search-and-fetch purpose where each tool clearly earns its place. It is not excessive or confusing.
The core lifecycle of web search followed by page retrieval is covered. Minor gaps exist, such as filtering, pagination, or batch retrieval, but agents can still accomplish the main use cases.
Maintenance
Related MCP Connectors
Web search and any page as LLM-ready Markdown for AI agents. Free keyless tier, no signup.
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Web scraping for AI agents: scrape, search, crawl, map any website to markdown + JSON. No browser.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables agents to search the live web and fetch URLs as clean Markdown, returning ranked search results and paginated page content through two lightweight tools.28 npmMIT
- FlicenseNot gradedqualityAmaintenanceEnables AI agents to search the web through configured providers and crawl pages or entire sites into clean Markdown or JSON, including authenticated crawls, over STDIO or HTTP.-
- FlicenseNot gradedqualityAmaintenanceEnables AI agents to search the web across configurable providers and crawl single pages or whole sites into clean, deduplicated Markdown or JSON. It runs on your own hardware, requiring no API key with SearXNG, and supports authenticated crawls plus STDIO and HTTP transport.-
- FlicenseNot gradedqualityAmaintenanceEnables AI agents to search the web through configured providers and crawl single pages or entire sites into clean Markdown or JSON, including authenticated crawls, filtering, CLI/Python use, and STDIO or HTTP transport.-