Provides web search capabilities for research tasks, used as the default search provider when Tavily is not configured.
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., "@deep-research-mcp Start a research report on the effects of remote work on productivity"
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 Server：先生成并审阅报告大纲，再把完整报告放入后台队列生成。任务状态保存在 SQLite 中，章节完成后会建立检查点，MCP 进程重启后可以继续未完成任务。
需要 Python 3.11–3.13。建议在虚拟环境中安装：
py -m venv .venv
.venv\Scripts\python -m pip install -e ".[test,ui]"复制 .env.example 为 .env，至少设置 DEEPSEEK_API_KEY。TAVILY_API_KEY 可选；未设置时默认的 baidu_tavily 策略会降级为仅使用百度。
Related MCP server: MCP-Maestro
Deep Research/
├─ mcp_server.py # MCP 接口层：四个工具和 stdio 入口
├─ app.py # Web 界面层：可选 Streamlit 入口
├─ service/ # 任务与持久化层
│ ├─ report_service.py # 状态机、后台队列和报告生命周期
│ └─ report_store.py # SQLite、章节检查点和任务恢复
├─ research/ # 研究执行层
│ ├─ engine.py # 大纲、逐章研究和汇总编排
│ ├─ nodes.py # 模型、搜索、写作和引用节点
│ ├─ prompts.py # 大模型提示词
│ ├─ models.py # 章节、查询和报告状态模型
│ └─ utils.py # 搜索提供商与来源处理函数
├─ tests/ # 自动化测试
├─ reports/ # 本地报告产物（不会提交到 Git）
├─ configuration.py # 环境变量及默认运行配置
├─ pyproject.toml # Python 打包、依赖和命令入口
├─ requirements.txt # 传统依赖清单
└─ .env.example # 环境变量模板根目录只保留两个用户入口和公共配置。研究过程放在 research，长任务运行及恢复放在 service，避免为单个业务文件额外创建目录。
安装后可直接启动 stdio Server：
.venv\Scripts\deep-research-mcp.exe通用 MCP 客户端配置示例：
{
"mcpServers": {
"deep-research": {
"command": "D:\\Deep Research\\.venv\\Scripts\\deep-research-mcp.exe",
"env": {
"DEEPSEEK_API_KEY": "由客户端安全注入",
"TAVILY_API_KEY": "可选",
"DEEP_RESEARCH_DATA_DIR": "D:\\Deep Research Data"
}
}
}
}不要把真实密钥提交到配置仓库。也可以在启动 MCP 客户端前通过系统环境变量提供密钥。
下面按照项目目录的职责分别展示流程。先看整体关系，再按需查看各模块内部细节。
flowchart LR
U[用户或 AI 客户端] --> E[入口层<br/>mcp_server.py / app.py]
E --> S[任务层<br/>service/]
S --> R[研究层<br/>research/]
S <--> D[(SQLite)]
R --> X[模型与搜索服务]
S --> O[Markdown 报告]入口层接收操作，service/ 管理任务，research/ 执行调研，最后由任务层保存状态和报告。
mcp_server.pyflowchart LR
C[MCP 客户端] --> P[create_report_plan<br/>创建大纲]
P --> U[update_report_outline<br/>修改并确认]
U --> G[generate_report<br/>加入后台队列]
G --> Q[get_report<br/>查询进度和结果]
Q -. 未完成时继续查询 .-> Q这一层只定义工具和参数，不执行具体搜索，也不直接操作数据库。四个工具最终都交给 ReportService 处理。
service/flowchart LR
A[ReportService<br/>校验请求] --> B[后台任务队列]
B --> C[逐章调用研究引擎]
C --> D[ReportStore<br/>保存章节检查点]
D --> E{全部完成?}
E -->|否| C
E -->|是| F[保存 Markdown<br/>状态 completed]
C -. 失败 .-> G[状态 failed<br/>允许重试]report_service.py 管理状态机、后台队列、重试和报告输出。
report_store.py 管理 SQLite；每章完成后保存一次，进程重启时可恢复未完成任务。
research/flowchart LR
A[engine.py<br/>选择当前章节] --> B{需要研究?}
B -->|是| C[nodes.py<br/>生成查询并搜索]
B -->|否| D[nodes.py<br/>直接写作]
C --> E[nodes.py<br/>撰写章节]
D --> F[返回章节内容]
E --> F
F --> G[汇总章节<br/>处理引用]engine.py 决定节点执行顺序，一次只推进一个章节。
nodes.py 调用模型完成大纲、查询、搜索、写作和引用处理。
prompts.py 提供提示词，models.py 定义状态结构，utils.py 提供搜索及来源处理能力。
app.pyflowchart LR
A[输入研究主题] --> B[编辑并确认大纲]
B --> C[启动后台生成]
C --> D[刷新任务进度]
D --> E[查看或下载报告]Streamlit 和 MCP 是两个不同入口，但都会调用同一个 ReportService，因此共用任务状态、SQLite 和研究流程。
调用 create_report_plan(topic, options?)，保存返回的 report_id。
编辑返回的完整 sections，调用 update_report_outline(..., confirm=true)。
调用 generate_report(report_id)；它只负责入队，会立即返回。
定期调用 get_report(report_id) 查看进度。完成后使用 include_content=true 取得 Markdown，或读取 output_path。
research=false 的章节不会执行网络搜索。重复调用 generate_report 不会创建重复任务。失败任务在已有大纲的情况下可再次调用该工具重试，并从最后一个成功保存的章节继续。
options 只接受以下非敏感字段：
number_of_queries
planner_provider / planner_model
writer_provider / writer_model
search_api / search_api_config
max_tokens
API Key 不属于工具参数，只能通过环境变量提供。
设置 DEEP_RESEARCH_DATA_DIR 可以指定数据根目录。目录中包含：
reports.sqlite3：任务、大纲、章节检查点、来源和错误状态；
reports/<report_id>/*.md：完成后的 Markdown 报告。
默认路径为 Windows 的 %LOCALAPPDATA%\deep-research-mcp；其他系统使用用户本地数据目录。
.venv\Scripts\python -m pytest
.venv\Scripts\python -m mcp dev mcp_server.py第二条命令启动 MCP Inspector，用于确认四个工具及其 JSON Schema。
创建持久化任务并生成可编辑大纲。
大纲生成需要调用模型与搜索服务，所以这是异步 MCP 工具。
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| options | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly reveals two key behaviors: the tool creates a persistent side-effect task and runs asynchronously due to model/search service dependencies. This is meaningful, though it does not cover failure modes or how to track completion.
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 short sentences. The first sentence states the core purpose and the second adds the critical async caveat. There is no filler or repetition.
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?
The description covers the essential what and why-async, and an output schema exists so return values are not missing. However, without annotations and with no usage guidance or parameter semantics, the agent lacks workflow context such as how to check the persistent task later or when to use sibling tools.
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 the tool description does not mention 'topic' or 'options' at all. The nested ReportOptions type has some schema-level explanation (non-sensitive config, extra=forbid), but the description adds no parameter meaning, leaving the agent to infer from names alone.
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 a specific action: '创建持久化任务并生成可编辑大纲' (create a persistent task and generate an editable outline). It distinguishes this tool from siblings like generate_report by focusing on the outline, not the final report.
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 description provides context by explaining the tool is asynchronous because it calls model and search services, which implies when it should be used. However, it does not explicitly mention alternatives or when not to use it, such as preferring generate_report for final output or update_report_outline for editing an existing outline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
把已确认的报告放入后台队列；重复调用不会创建重复任务。
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It does reveal two important traits: the operation is queued asynchronously and repeated calls are idempotent. Still, it does not mention potential side effects, required permissions, failure behavior, or whether the report must already exist.
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 one compact sentence that leads with the core action and then adds the idempotency caveat. There is no filler or redundant restating of the tool name.
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 tool with an output schema, the description conveys the core behavior and idempotency. However, it lacks explicit usage context relative to sibling tools and does not clarify the relationship between report_id and a 'confirmed' report, leaving meaningful gaps for an agent deciding when and how to call it.
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 the description does not elaborate on report_id. The only parameter is minimally labeled 'Report Id', but the description neither explains what value it expects, how it maps to a confirmed report, nor any format constraints. It fails to compensate for the schema's lack of guidance.
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 states a specific action: placing a confirmed report into a background queue, with an idempotency guarantee. This distinguishes it from the sibling tools, though it does not explicitly name the 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?
The phrase '已确认的报告' implies the tool is for reports that have already been confirmed, giving some contextual guidance. However, there is no explicit statement of when to use this tool over siblings like create_report_plan or update_report_outline, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取任务进度；调用方可按需附带正文与来源，避免默认返回过大。
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | ||
| include_content | No | ||
| include_sources | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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. It discloses that the tool reads task progress, that the default response excludes content and sources, and that including them can result in a large return payload. This is adequate for a simple read operation, though it omits details like error conditions or authentication requirements.
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 with the main verb and resource front-loaded, followed by relevant parameter guidance. Every word earns its place, and there is no redundant or filler content.
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 low-complexity read tool with only three simple parameters and an output schema, the description provides enough context to call the tool correctly. The only minor gap is a slight ambiguity around what 任务进度 means exactly, but the reference to 正文 and 来源 helps clarify the tool's scope.
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%, so the description must compensate. It does so by mapping 正文 and 来源 to include_content and include_sources, and by indicating the default behavior through the phrase 避免默认返回过大. The report_id parameter is not described, but it is required and self-evident from 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 description states a specific action, 读取 (read), and resource, 任务进度 (task progress), which clearly identifies this as a retrieval tool. It distinguishes itself from siblings like create_report_plan, update_report_outline, and generate_report by being the only read-oriented operation.
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 description clearly implies this tool should be used to read task progress and optionally include content/sources. It does not explicitly name alternatives or exclusion conditions, but the sibling tools are all mutating or generation-oriented, making the proper usage context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
全量替换报告大纲，并可将其确认为可生成状态。
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | ||
| confirm | No | ||
| sections | Yes | ||
| report_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It does disclose two important behaviors: the operation is a full replacement of the outline, and it can optionally set the report into a generation-ready state. However, it does not mention permissions, reversibility, or what happens to existing report content or state when confirm is set.
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, tightly written sentence that leads with the core action ('全量替换报告大纲') and follows with the optional state confirmation. Every word contributes meaning, and there is no redundancy.
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?
The description covers the main action and the confirm behavior, and the input schema together with the output schema provide structural detail. Still, there is no guidance on when this tool should be selected over create_report_plan, and the role of `topic` remains unexplained. For a destructive replace operation, this is adequate but not fully self-sufficient.
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%, so the description must compensate for missing parameter docs. It does clarify that `sections` represent the full replacement outline and that `confirm` relates to making the outline generation-ready. However, the optional `topic` parameter is not mentioned at all, and `report_id` is only inferable from the tool 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 description uses a specific verb ('全量替换' = fully replace) and a specific resource ('报告大纲' = report outline), and it adds a distinct state-transition behavior ('可将其确认为可生成状态'). This makes it clearly distinguishable from siblings like get_report, create_report_plan, and generate_report.
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 description provides no guidance on when to use this tool versus create_report_plan or generate_report. There is no mention that the report must already have an outline, no mention of prerequisites, and no excluded cases. Usage context is only implied by the word 'replace'.
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. Dates show when Glama detected each change.
v0.1.0create_report_plangenerate_reportget_reportupdate_report_outlineEach tool maps to a distinct phase of the report lifecycle: plan creation, outline update, generation, and progress/result retrieval. There is no meaningful overlap between read and write operations.
Tool names consistently use snake_case verb_noun structure (get_report, create_report_plan, update_report_outline, generate_report). Minor deviation: generate_report acts on the same report object as get_report, but the verb clearly differentiates the action.
Four tools cover a focused asynchronous research workflow without redundancy. This is a well-scoped set for the server's purpose.
Core lifecycle is covered: create plan, update outline, generate report, and read progress/results. Missing operations like cancel or delete are minor gaps that agents can work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Research portfolio management — organize projects and track research artifacts.
AI research library. Save, organise and reuse notes and webpages as clean markdown context.
Create, edit, review, and explicitly publish Live or Snapshot Markdown Documents in mdedit.ai.
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/asteriii123/deep-research-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
