Node.js（用于运行 MCP 服务器）
- 从https://nodejs.org/下载并安装
- 确保 Node.js 已添加到系统 PATH
Python 3.10 或更高版本
能够运行您选择的 Ollama 模型的计算（CPU/GPU）
至少 8GB RAM 用于运行更大的语言模型
所需的 API 密钥：
- Tavily API 密钥（在https://tavily.com获取）
- Perplexity API 密钥（在https://perplexity.ai获取）
- LangSmith API 密钥（在https://smith.langchain.com获取）用于跟踪和监控

确保你能从终端/命令提示符运行 Node.js 和 npm。你可以使用以下命令验证安装：

node --version
npm --version
python --version

如果这些命令失败，您可能需要：

安装后重新启动终端/计算机
将 Node.js 添加到您的系统 PATH：
- Windows：编辑系统环境变量 → 环境变量 → Path → 添加 Node.js 安装目录
- macOS/Linux：通常由安装程序处理

安装

选项 1：标准安装

为您的平台下载并安装Ollama
克隆此存储库并安装依赖项：

git clone https://github.com/Cam10001110101/mcp-server-ollama-deep-researcher
cd mcp-server-ollama-deep-researcher
npm install

安装 Python 依赖项：

首先，安装 uv（建议安装以获得更好的性能和依赖性解析）：

# Windows
pip install uv

# macOS/Linux
pip3 install uv

然后使用 pyproject.toml 安装项目依赖项：

uv pip install .

注意：这将以可编辑模式安装项目，并包含 pyproject.toml 中指定的所有依赖项。如果您更喜欢 pip：

pip install .  # Windows
pip3 install .  # macOS/Linux

构建 TypeScript 代码：

npm run build

从Ollama获得本地 LLM 学位：

ollama pull deepseek-r1:8b

选项 2：Docker 安装

您还可以使用 Docker 运行 MCP 服务器，从而简化设置过程。

下载并安装适合您平台的Docker
克隆此存储库：

git clone https://github.com/Cam10001110101/mcp-server-ollama-deep-researcher
cd mcp-server-ollama-deep-researcher

使用您的 API 密钥创建一个.env文件（您可以从.env.example复制）：

cp .env.example .env
# Edit the .env file with your API keys

使帮助脚本可执行：

chmod +x run-docker.sh

构建并运行 Docker 容器：

./run-docker.sh start

确保 Ollama 在您的主机上运行：

ollama pull deepseek-r1:8b  # or your preferred model
ollama serve

帮助脚本提供了几个命令：

对于 macOS/Linux（使用 run-docker.sh）：

./run-docker.sh start - 构建并启动 Docker 容器
./run-docker.sh stop停止Docker容器
./run-docker.sh restart重新启动 Docker 容器
./run-docker.sh logs - 显示来自 Docker 容器的日志
./run-docker.sh status - 检查 Docker 容器的状态
./run-docker.sh help显示帮助信息

对于 Windows（使用 run-docker.bat）：

run-docker.bat start - 构建并启动 Docker 容器
run-docker.bat stop - 停止 Docker 容器
run-docker.bat restart - 重新启动 Docker 容器
run-docker.bat logs - 显示来自 Docker 容器的日志
run-docker.bat status - 检查 Docker 容器的状态
run-docker.bat help - 显示帮助信息

注意：Docker 容器已配置为连接到主机上运行的 Ollama。如果您也想在容器中运行 Ollama，请在 docker-compose.yml 文件中取消注释 Ollama 服务。

客户端配置

将服务器添加到您的 MCP 客户端配置：

对于 Claude 桌面应用程序：

macOS： ~/Library/Application Support/Claude/claude_desktop_config.json
Windows： %APPDATA%\Claude\claude_desktop_config.json

对于 Cline（VS 代码扩展）：

Windows： %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
macOS： ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Linux： ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

选项 1：标准安装配置

{
  "mcpServers": {
    "ollama-deep-researcher": {
      "command": "node",
      "args": ["path/to/mcp-server-ollama-deep-researcher/build/index.js"],
      "env": {
        "LANGSMITH_TRACING": "true",
        "LANGSMITH_ENDPOINT": "https://api.smith.langchain.com",
        "LANGSMITH_API_KEY": "your-langsmith-key",
        "LANGSMITH_PROJECT": "ollama-deep-researcher-mcp-server",
        "TAVILY_API_KEY": "your-tavily-key",  // Include tvly- prefix
        "PERPLEXITY_API_KEY": "your-perplexity-key",
        "PYTHONPATH": "path/to/mcp-server-ollama-deep-researcher/src"
      }
    }
  }
}

注意：用系统的绝对路径替换路径：

Windows：使用C:\\Users\\username\\path\\to\\mcp-server-ollama-deep-researcher
macOS/Linux：使用/Users/username/path/to/mcp-server-ollama-deep-researcher

对于 macOS/Linux，您可能还需要添加：

"PYTHONUNBUFFERED": "1"

选项 2：Docker 安装配置

如果您正在使用 Docker 容器，则可以配置 MCP 客户端以连接到正在运行的容器：

{
  "mcpServers": {
    "ollama-deep-researcher": {
      "command": "docker",
      "args": ["exec", "-i", "ollama-deep-researcher-mcp", "node", "build/index.js"],
      "env": {}
    }
  }
}

此配置假设 Docker 容器正在运行。环境变量已在 Docker 容器中设置，因此您无需在 MCP 客户端配置中指定它们。

追踪与监控

该服务器与 LangSmith 集成，可全面跟踪和监控研究过程：

操作追踪：
- 所有 LLM 互动均有记录
- 网络搜索操作受到监控
- 跟踪研究工作流程步骤
性能监控：
- 每个操作的响应时间
- 成功/失败率
- 资源利用率
调试和优化：
- 用于故障排除的详细跟踪
- 性能瓶颈识别
- 查询优化见解

使用您配置的项目名称访问https://smith.langchain.com上的所有跟踪。

MCP 资源

研究结果自动存储为 MCP 资源，从而实现：

持久访问
- 可通过research://{topic} URI 访问结果
- 自动存储已完成的研究
- 带有元数据的 JSON 格式内容
资源面板集成
- 研究成果出现在 MCP 客户端的资源面板中
- 轻松访问过去的研究主题
- 每个结果的时间戳和描述
上下文管理
- 在对话中有效地重复使用研究成果
- 通过资源引用减少令牌使用
- 选择性纳入研究背景

可用工具

配置

maxLoops ：研究迭代次数（1-5）
llmModel ：要使用的 Ollama 模型（例如，“deepseek-r1:1.5b”、“llama3.2”）
searchApi ：要使用的搜索 API（“perplexity”或“tavily”）

配置研究参数。

{
  "name": "configure",
  "arguments": {
    "maxLoops": 3,
    "llmModel": "deepseek-r1:1.5b",
    "searchApi": "tavily"
  }
}

研究

使用网络搜索和 LLM 综合研究任何主题。

{
  "name": "research",
  "arguments": {
    "topic": "Austin LangChain, aimug.org"
  }
}

获取状态

了解正在进行的研究的当前状态。

{
  "name": "get_status",
  "arguments": {
    "_dummy": "dummy"
  }
}

提示

使用默认搜索 API、模型和最大迭代次数（循环）

提示示例：“研究 AI-First 应用程序”

更改默认配置并开始研究

语法： configure with <searchapi> and <model> then research <topic>
提示示例：“使用 perplexity 和 deepseek-r1:8b 进行配置，然后研究 AI-First 应用程序”

Ollama 研究工作流程

研究过程受到IterDRAG的启发。此方法将查询分解为子查询，检索每个子查询的文档，回答子查询，然后通过检索第二个子查询的文档来构建答案。

该过程的工作原理如下：

给定用户提供的主题，使用本地 LLM（通过Ollama ）生成网络搜索查询
使用搜索引擎（为Tavily配置）查找相关来源
使用 LLM 总结与用户提供的研究主题相关的网络搜索结果
然后，利用法学硕士（LLM）来反思总结，找出知识差距
它生成一个新的搜索查询来解决知识差距
该过程不断重复，摘要会根据来自网络搜索的新信息进行迭代更新
它将在研究兔子洞中重复
运行可配置的迭代次数

输出

输出是一个 markdown 文件，其中包含研究摘要，以及研究过程中使用的所有来源的引用。

研究期间收集的所有来源均会保留，并可在最终输出中引用：

系统集成概述

graph TD
    subgraph "Claude Desktop App"
        A[Claude Assistant] --> B[Task Planning]
        B --> C[Tool Selection]
        C --> D[Resource Selection]
        D --> E[Prompt Templates]
    end

    subgraph "MCP Client Layer"
        F[Tool Registry] --> G[Protocol Handler]
        G --> H[Server Manager]
        I[Resource Manager] --> G
        J[Prompt Manager] --> G
    end

    subgraph "MCP Server"
        K[Tools API] --> L[Research Controller]
        L --> M[Configuration Manager]
        L --> N[State Manager]
        O[Resource API] --> L
        P[Prompt API] --> L
    end

    subgraph "External Services"
        Q[Ollama] --> L
        R[Search APIs] --> L
    end

    %% Feature Support Flow
    C -->|"use_mcp_tool"| F
    D -->|"access_resource"| I
    E -->|"use_prompt"| J
    H -->|"Execute"| K
    H -->|"Read"| O
    H -->|"Get"| P

    %% Status Flow
    L -->|"Results"| H
    H -->|"Response"| C

    %% Feature Support Notes
    classDef support fill:#e1f3d8,stroke:#333
    classDef partial fill:#fff3cd,stroke:#333
    
    %% Full Support Features
    A:::support
    F:::support
    I:::support
    J:::support

故障排除

以下是您可能遇到的常见问题的解决方案：

Ollama连接问题

确保 Ollama 正在运行：在终端中执行ollama list
尝试通过关闭应用程序（系统托盘/菜单栏）在终端模式下运行 ollama，然后执行ollama serve
检查是否可以通过localhost:11434 、 0.0.0.0:11434或127.0.0.1:11434访问 Ollama

API 密钥问题

验证您的 API 密钥是否在配置文件中正确设置
验证您的路径参数是否指向此 repo 中 index.js 的实际位置
确保 API 密钥周围没有多余的空格或引号
检查您的 API 密钥是否具有足够的信用/权限

MCP 服务器问题

使用 MCP Inspector 进行调试：

npx @modelcontextprotocol/inspector node path/to/server/index.js --model llama3.2 --max-loops 3 --search-api tavily

Docker 问题

如果您遇到 Docker 容器问题：
- 检查容器是否正在运行： docker ps
- 查看容器日志： docker logs ollama-deep-researcher-mcp
- 确保您的.env文件包含有效的 API 密钥
- 验证 Ollama 是否在主机上运行并可从容器访问
- 如果使用 host.docker.internal 不起作用，请尝试在 OLLAMA_BASE_URL 环境变量中使用主机的 IP 地址
- 对于容器之间的网络问题，请确保它们位于同一个 Docker 网络上
如果您在容器中运行 Ollama：
- 取消注释 docker-compose.yml 中的 Ollama 服务
- 确保 Ollama 容器分配了足够的资源
- 拉取Ollama容器中的模型： docker exec -it ollama ollama pull deepseek-r1:8b

构建问题

如果npm run build失败并显示“无法识别‘node’”：
1. 确保 Node.js 已正确安装
2. 将 Node.js 添加到您的系统 PATH：
  - Windows：编辑系统环境变量 → 环境变量 → Path → 添加 Node.js 安装目录
  - macOS/Linux：通常由安装程序处理
3. 重新启动终端/计算机
4. 尝试运行node --version来验证安装

Python 问题

视窗：

确保 Python 位于你的 PATH 中
尝试使用python而不是python3
检查 pip 是否已安装： python -m pip --version

macOS/Linux：

使用python3而不是python
检查 pip 是否已安装： python3 -m pip --version
您可能需要安装 pip： sudo apt install python3-pip （Ubuntu/Debian）或brew install python3 （macOS）

错误处理

服务器提供了以下清晰的错误消息：

API 密钥缺失或无效
配置问题
搜索 API 问题
LLM 处理错误

需要改进

更紧密地重新集成和验证 langgraph 以获得更多有趣的用例。

建筑学

有关服务器架构和实现的详细信息，请参阅.context/index.md 。

Glama.ai徽章

示例提示和输出记录

迅速的

Configure with perplexity and deepseek-r1:8b then research AI-First Applications

配置输出

{
  "searchApi": "perplexity",
  "llmModel": "deepseek-r1:8b",
  "maxLoops": 3
}

Ollama 研究员成果

Research configuration updated:
Max Loops: 3
LLM Model: deepseek-r1:8b
Search API: perplexity

### Complete Research Results

**Updated Summary: AI-First Applications in Healthcare: Focus on PathAI**

1. **Design Principles**:
   - PathAI exemplifies a data-driven approach by leveraging extensive datasets to train advanced AI models like PLUTO.
   - Collaboration is central to their success, integrating technology into clinical workflows through partnerships with institutions such as Cleveland Clinic.

2. **Industry Transformations**:
   - In healthcare, PathAI has significantly impacted diagnostic accuracy and efficiency. Their foundation model, PLUTO, demonstrates superior performance in various pathology tasks, outperforming existing models while reducing costs.
   - Collaborations with leading institutions have facilitated the creation of digital pathology data networks, enhancing research and clinical care.

3. **Scalability and Performance**:
   - PathAI's PLUTO model offers enhanced efficiency and compactness, significantly reducing training and inference costs.
   - This innovation underscores their commitment to scalable and effective solutions in healthcare.

4. **Growth and Impact**:
   - PathAI's growth strategy includes strategic partnerships and collaborations, such as their partnership with Cleveland Clinic and acquisition by Quest Diagnostics.
   - These moves accelerate AI and digital pathology adoption, particularly in cancer diagnosis.

This summary highlights PathAI's contributions to healthcare through innovative technology and strategic collaborations, emphasizing their role in driving advancements and improving patient outcomes.

## Sources

### Perplexity Search 1
1. https://intelifaz.com/insights/ai-first-software-design
2. https://www.uxdesigninstitute.com/blog/how-to-design-for-ai-first-products/
3. https://vux.world/ai-design-principles/
4. https://www.leanware.co/insights/ai-first-apps
5. https://adamfard.com/blog/ai-ux-design-framework
6. https://www.sgh.com/insight/artificial-intelligence-best-practices/
7. https://www.index.dev/blog/generative-ai-application-design-principles
8. https://onstrategyhq.com/resources/ai-guiding-principles/
9. https://orangematter.solarwinds.com/2024/04/29/introducing-ai-by-design-principles-for-responsible-ai/
10. https://principles.design/examples/10-principles-for-design-in-the-age-of-ai

### Perplexity Search 2
1. https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders
2. https://www.cloudera.com/resources/the-art-of-the-possible/ai-first-benefits-5-real-world-outcomes.html
3. https://builtin.com/artificial-intelligence/examples-ai-in-industry
4. https://www.uxforai.com/p/the-rise-of-ai-first-products
5. https://www.1051theblaze.com/ai-first-mobile-apps/
6. https://www.techtarget.com/searchenterpriseai/tip/The-history-of-artificial-intelligence-Complete-AI-timeline
7. https://gitnation.com/contents/demystifying-ai-first-building-applications-for-the-future
8. https://fptsoftware.com/resource-center/blogs/the-ai-first-future-challenges-and-opportunities
9. https://online.maryville.edu/blog/history-of-ai/
10. https://www.audience.io/blog/artificial-intelligence-first-party-data-the-future-of-data

### Perplexity Search 3
1. https://monday.com/blog/rnd/technical-specification/
2. https://softwaremind.com/blog/8-steps-for-successful-software-implementation/
3. https://www.infotech.com/research/ss/build-your-enterprise-application-implementation-playbook
4. https://interactiveimmersive.io/blog/touchdesigner-lessons/04-technical-implementation-design/
5. https://www.indeed.com/career-advice/finding-a-job/technical-requirements
6. https://www.techtarget.com/searchcustomerexperience/definition/implementation
7. https://theobogroup.com/what-to-know-about-technical-implementations/
8. https://www.ntietz.com/blog/whats-behind-just-implementation/
9. https://public.cyber.mil/stigs/

### Perplexity Search 4
1. https://www.ittbiomed.com/transforming-pathology-with-ai/
2. https://www.pathai.com/resources/pathai-commences-new-year-with-strong-foundation-for-growth-following-key-2023-achievements-in-ai-powered-pathology-products-strategic-partnerships-and-leadership-team-hires/
3. https://canvasbusinessmodel.com/blogs/target-market/pathai-target-market
4. https://www.pathologynews.com/industry-news/pathai-launches-new-pathologist-centric-features-on-aisight-to-enable-efficient-case-review-through-intelligent-case-prioritization-and-real-time-multi-institutional-collaboration/
5. https://newsroom.clevelandclinic.org/2022/03/10/pathai-and-cleveland-clinic-announce-collaboration-to-build-digital-pathology-infrastructure-and-evolve-use-of-ai-powered-pathology-algorithms-in-research-and-clinical-care
6. https://academic.oup.com/jamia/article/30/9/1503/7174318
7. https://hitconsultant.net/2024/05/14/pathai-unveils-ai-foundation-model-built-for-disease-detection/
8. https://newsroom.questdiagnostics.com/2024-05-01-Quest-Diagnostics-to-Acquire-PathAI-Diagnostics-to-Accelerate-AI-and-Digital-Pathology-Adoption-in-Cancer-Diagnosis-Forms-Licensing-Agreements-with-PathAI
9. https://www.multimodal.dev/post/ai-in-healthcare
10. https://canvasbusinessmodel.com/blogs/growth-strategy/pathai-growth-strategy

克劳德最终输出

Key Principles of AI-First Applications:

1. Human-AI Collaboration
- Applications are designed with AI as a core component rather than an add-on
- Focus on augmenting human capabilities rather than replacing them
- Clear feedback loops between AI systems and human users

2. Data-Centric Architecture
- Built around robust data pipelines and continuous learning
- Strong emphasis on data quality and governance
- Scalable infrastructure to handle growing datasets

3. Adaptive User Experience
- Interfaces that evolve based on user interaction patterns
- Contextual awareness and personalization
- Clear communication of AI capabilities and limitations

Real-World Example: PathAI in Healthcare

Core Technology:
- PLUTO foundation model demonstrates superior performance in pathology tasks
- Focuses on efficiency and cost reduction while maintaining high accuracy
- Built for scalability and integration into existing workflows

Implementation Strategy:
- Strategic partnerships with healthcare institutions like Cleveland Clinic
- Creation of digital pathology data networks
- Focus on practical clinical applications and research

Impact:
- Improved diagnostic accuracy in cancer detection
- Enhanced efficiency in pathology workflows
- Reduced costs through optimized resource utilization

Best Practices for AI-First Applications:

1. Technical Implementation
- Start with clear use cases and success metrics
- Build robust data pipelines and validation processes
- Implement continuous monitoring and model updating

2. User Experience
- Design transparent interfaces that build trust
- Provide clear feedback on AI decisions and confidence levels
- Allow for human oversight and intervention

3. Integration and Scaling
- Focus on seamless integration with existing workflows
- Build scalable infrastructure from the start
- Plan for continuous improvement and iteration

Available Tools

3 tools

configureC

Configure the research parameters (max loops, LLM model, search API)

ParametersJSON Schema

Name	Required	Description
`maxLoops`	No	Maximum number of research loops (1-10)
`llmModel`	No	Ollama model to use (e.g. llama3.2)
`searchApi`	No	Search API to use for web research

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 states the tool configures parameters but doesn't explain if this is a one-time setup, if changes persist, what happens to ongoing research, or if it requires specific permissions. For a configuration tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's function and enumerates the configurable parameters. It's front-loaded with the core action and wastes no words, making it easy to parse quickly.

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 the complexity of a configuration tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like persistence of settings, effects on sibling tools, or error handling. With 3 parameters and no structured output info, more context is needed for the agent to use this tool effectively.

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

Parameters3/5

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

The description lists the three parameters (max loops, LLM model, search API), which matches the input schema. Since schema description coverage is 100%, the schema already documents each parameter's purpose, constraints, and enums. The description adds no additional semantic context beyond what's in the schema, so it meets the baseline for high coverage.

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 clearly states the verb ('configure') and the resource ('research parameters'), specifying what the tool does. It lists the three specific parameters that can be configured, making the purpose concrete. However, it doesn't explicitly differentiate from sibling tools like 'get_status' or 'research', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternatives like 'research' or 'get_status'. It doesn't mention prerequisites, such as whether this should be called before starting research, or if it's optional. There's no explicit when/when-not context, leaving usage ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_statusB

Get the current status of any ongoing research

ParametersJSON Schema

Name	Required	Description	Default
`_dummy`	Yes	No parameters needed

TDQS

B3.1/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 states the tool retrieves status but doesn't describe what the status includes (e.g., format, fields), whether it's real-time or cached, error handling, or any side effects. For a tool with zero annotation coverage, this is a significant gap in transparency about its behavior and output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every part of the sentence earns its place by conveying essential information.

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 the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what 'status' means in terms of return values (e.g., progress indicators, error messages), which is critical for an agent to interpret results. For a tool with no structured output documentation, the description should provide more context about the expected response.

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

Parameters4/5

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

The input schema has 100% description coverage, indicating the single parameter '_dummy' is documented as 'No parameters needed' with a const value. The description doesn't add any parameter details beyond this, which is acceptable since the schema fully covers it. With zero meaningful parameters, the baseline is 4, as the description doesn't need to compensate for gaps.

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 clearly states the verb ('Get') and resource ('current status of any ongoing research'), making the purpose unambiguous. It distinguishes itself from sibling tools 'configure' and 'research' by focusing on status retrieval rather than configuration or research initiation. However, it doesn't specify what 'status' entails (e.g., progress percentage, completion state, errors), which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether research must be initiated first), exclusions, or how it relates to sibling tools like 'research' (which might initiate research) or 'configure' (which might set up research parameters). This leaves the agent without context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

researchC

Research a topic using web search and LLM synthesis

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	The topic to research

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool performs web search and LLM synthesis, which implies external API calls and potential latency, but doesn't disclose important behavioral traits like rate limits, authentication requirements, cost implications, privacy considerations, or what happens when research fails. The description is insufficient for a tool that likely makes external calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is extremely concise (8 words) and front-loaded with the core functionality. Every word earns its place by specifying the action ('research'), resource ('topic'), and methods ('web search and LLM synthesis'). There's zero waste or redundancy.

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 the complexity of a research tool that likely makes external API calls and performs synthesis, and with no annotations or output schema provided, the description is incomplete. It doesn't explain what the output looks like, how comprehensive the research is, what sources are used, or any limitations. For a tool with this level of potential complexity, the description should provide more context.

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

Parameters3/5

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

The schema description coverage is 100% with a single parameter 'topic' clearly documented. The description adds no additional parameter semantics beyond what the schema already provides. It doesn't elaborate on topic format, length constraints, or examples. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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 clearly states the tool's purpose with specific verbs ('research', 'search', 'synthesize') and identifies the resource ('topic'). It distinguishes itself from sibling tools (configure, get_status) by focusing on research rather than configuration or status retrieval. However, it doesn't specify what distinguishes it from other potential research tools that might exist elsewhere.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternatives. It doesn't mention prerequisites, limitations, or when other tools might be more appropriate. While the sibling tools (configure, get_status) are clearly different in function, there's no explicit comparison or usage context provided.

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 tool updatev1.0.0Jan 2, 2026

Changedconfigure2 fields changed

changedInput schema / properties / maxLoops / description

Previous value: -"Maximum number of research loops (1-5)"New value: +"Maximum number of research loops (1-10)"

changedInput schema / properties / searchApi / enum

Previous value: -[
-  "perplexity",
-  "tavily"
-]New value: +[
+  "perplexity",
+  "tavily",
+  "exa"
+]

3 tool updatesAug 18, 2025
- First observedconfigure
- First observedget_status
- First observedresearch

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

B3.3/5.0

Scored 2026-04-18 11:35 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: configure sets parameters, get_status checks progress, and research initiates the core workflow. An agent can easily distinguish between setup, monitoring, and execution functions.

Naming Consistency5/5

All three tools follow a consistent verb_noun pattern (configure, get_status, research), with clear and predictable naming. There are no deviations in style or convention across the set.

Tool Count3/5

With only 3 tools, the server feels thin for a 'deep researcher' domain that might benefit from more granular operations like refining queries or managing results. However, the core workflow is covered, making it borderline appropriate.

Completeness3/5

The tools cover the basic research lifecycle (configure, execute, monitor), but there are notable gaps such as no way to retrieve or export past research results, modify parameters mid-research, or handle errors. This could limit agent effectiveness in complex scenarios.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

langchain
io.github.doc2mcp
MCP server for langchain documentation, generated by doc2mcp.
Documentation Access AI & Machine Learning
24
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
Keenable Web Search A
ai.keenable.api
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Research & Data Search Web Scraping
23
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Related MCP Servers

WebQuest MCP
Browser Automation Web Scraping
mustafametesengul
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server that exposes powerful web search and scraping tools to AI agents and MCP-compatible clients.
Updated 7 months ago (2026-02-12 20:56 UTC)
Apache 2.0
deep-research
Agent Orchestration Autonomous Agents
troyhantech
A
license
Not graded
quality
D
maintenance
Enables deep research tasks using a multi-agent architecture that integrates any LLM and MCP tools. Available via MCP stdio, streamable HTTP, and SSE transports.
Updated 3 months ago (2026-06-15 01:55 UTC)
17
MIT
myscrape
Browser Automation Web Scraping Search
Bonifatius94
A
license
Not graded
quality
C
maintenance
A self-contained web-research MCP server that lets local LLM agents search, fetch, and synthesize web content using tools like web_search, web_fetch, and web_research.
Updated 24 days ago (2026-08-26 18:34 UTC)
2
MIT
research
Web Scraping Search Research & Data
id5463
A
license
Not graded
quality
C
maintenance
Multi-purpose research MCP server integrating web search, deep research, web scraping, research methodology routing, and GPT Researcher report generation.
Updated 2 months ago (2026-07-10 05:02 UTC)
MIT

MCP 服务器：Ollama 深度研究员

核心功能

研究过程

先决条件

安装

选项 1：标准安装

选项 2：Docker 安装

客户端配置

选项 1：标准安装配置

选项 2：Docker 安装配置

追踪与监控

MCP 资源

可用工具

配置

研究

获取状态

提示

使用默认搜索 API、模型和最大迭代次数（循环）

更改默认配置并开始研究

Ollama 研究工作流程

输出

系统集成概述

故障排除

Ollama连接问题

API 密钥问题

MCP 服务器问题

Docker 问题

构建问题

Python 问题

错误处理

需要改进

建筑学

Glama.ai徽章

示例提示和输出记录

迅速的

配置输出

Ollama 研究员成果

克劳德最终输出

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches