en es ja ko zh

mcp-server-ollama-deep-researcher

Name: mcp-server-ollama-deep-researcher
Author: Cam10001110101

by Cam10001110101

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

MCP サーバー: Ollama Deep Researcher

これは、LangChain Ollama Deep Researcherのモデルコンテキストプロトコル（MCP）サーバー版です。モデルコンテキストプロトコルエコシステム内で利用可能なMCPツールとしてディープリサーチ機能を提供し、AIアシスタントがOllamaを介してローカルLLMを用いてトピックに関する詳細なリサーチを実行できるようにします。

コア機能

サーバーは、 Ollamaがホストする任意の LLM を使用して、MCP ツールとリソースを通じて研究機能を提供します。

研究プロセス

トピックを指定すると、次のようになります。

ウェブ検索クエリを生成する
TavilyまたはPerplexity API経由でウェブ検索結果を収集する
検索結果を要約する
要約を振り返り、知識のギャップを調べる
ギャップを埋めるための新しい検索クエリを生成する
複数の調査サイクルを通じて要約を反復的に改善する
使用したすべてのソースを含む最終的なマークダウンの概要を提供する

複数のサイクルを通じた反復的な研究プロセスを示す図

Related MCP server: deep-research

前提条件

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

これらのコマンドが失敗した場合は、次の操作が必要になる可能性があります。

インストール後に端末/コンピュータを再起動してください
システム PATH に Node.js を追加します。
- Windows: システム環境変数の編集 → 環境変数 → パス → 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 Code 拡張機能) の場合:

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"
  }
}

研究

Web 検索と LLM 統合を使用して、あらゆるトピックを調査します。

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

ステータスを取得する

進行中の研究の現在の状況を取得します。

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

促す

デフォルトの検索 API、モデル、最大反復回数（ループ）の使用

プロンプトの例:「AIファーストのアプリケーションの研究」

デフォルト設定を変更して調査を開始する

構文: configure with <searchapi> and <model> then research <topic>
プロンプトの例:「perplexity と deepseek-r1:8b を設定して、AI ファーストアプリケーションを調査します」

Ollamaリサーチワークフロー

この研究プロセスはIterDRAGに着想を得ています。このアプローチでは、クエリをサブクエリに分解し、それぞれのサブクエリに対応するドキュメントを取得し、サブクエリに回答した後、その回答に基づいて2番目のサブクエリに対応するドキュメントを取得します。

プロセスは次のように機能します。

ユーザーが指定したトピックに基づいて、ローカル LLM ( Ollama経由) を使用して Web 検索クエリを生成します。
検索エンジン（ Tavily用に構成）を使用して関連するソースを検索します
LLM を使用して、ユーザーが提供した研究トピックに関連する Web 検索からの結果を要約します。
次に、LLMを使用して要約を振り返り、知識のギャップを特定します。
知識ギャップを埋めるために新しい検索クエリを生成する
このプロセスは繰り返され、要約はウェブ検索からの新しい情報で繰り返し更新されます。
研究のウサギの穴に落ちて繰り返すことになる
設定可能な反復回数だけ実行します

出力

出力は、研究プロセス中に使用されたすべてのソースへの引用を含む、研究概要を含むマークダウンファイルです。

調査中に収集されたすべてのソースは保存され、最終出力で参照できます。

システム統合の概要

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を実行します。
Ollamaがlocalhost:11434``0.0.0.0:11434 、または127.0.0.1:11434でアクセス可能か確認します。

APIキーの問題

設定ファイルにAPIキーが正しく設定されていることを確認してください
パス引数がこのリポジトリ内のindex.jsの実際の場所を指していることを確認してください
APIキーの周囲に余分なスペースや引用符がないことを確認してください
APIキーに十分なクレジット/権限があるかどうかを確認してください

MCP サーバーの問題

デバッグには MCP インスペクタを使用します。

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. システム PATH に Node.js を追加します。
  - Windows: システム環境変数の編集 → 環境変数 → パス → Node.jsインストールディレクトリの追加
  - macOS/Linux: 通常はインストーラーによって処理されます
3. 端末/コンピュータを再起動します
4. インストールを確認するには、 node --versionを実行してみてください。

Pythonの問題

ウィンドウズ:

PythonがPATHにあることを確認する
python3の代わりにpythonを使ってみてください
pipがインストールされているかどうかを確認します: python -m pip --version

macOS/Linux:

pythonの代わりにpython3使用する
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
}

オラマ研究者の成果

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 Deep Researcher

コア機能

研究プロセス

前提条件

インストール

オプション1: 標準インストール

オプション2: Dockerのインストール

クライアント構成

オプション1: 標準インストール構成

オプション2: Dockerインストール構成

追跡と監視

MCPリソース

利用可能なツール

設定

研究

ステータスを取得する

促す

デフォルトの検索 API、モデル、最大反復回数（ループ）の使用

デフォルト設定を変更して調査を開始する

Ollamaリサーチワークフロー

出力

システム統合の概要

トラブルシューティング

Ollama 接続の問題

APIキーの問題

MCP サーバーの問題

Dockerの問題

ビルドの問題

Pythonの問題

エラー処理

必要な機能強化

建築

Glama.ai バッジ

プロンプトと出力のトランスクリプトの例

プロンプト

構成出力

オラマ研究者の成果

クロード最終出力

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches