Skip to main content
Glama
enesjakozh
Cam10001110101

mcp-server-ollama-deep-researcher

by Cam10001110101
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

⛔ ARCHIVED — this code has moved

Migrated into the mcpcentral platform monorepo on 2026-07-23 (ADR-043).

Work here instead: mcpcentral-io/mcpcentral → apps/deep-researcher/ Worker: mcpcentral-deep-researcher

This repository is read-only and kept for history. See DEPRECATED.md.

Ollama Deep Researcher DXT Extension

Overview

Ollama Deep Researcher is a Desktop Extension (DXT) that enables advanced topic research using web search and LLM synthesis, powered by a local MCP server. It supports configurable research parameters, status tracking, and resource access, and is designed for seamless integration with the DXT ecosystem.

  • Research any topic using web search APIs (Tavily, Perplexity, Exa) and LLMs (Ollama, DeepSeek, etc.)

  • Configure max research loops, LLM model, and search API

  • Track status of ongoing research

  • Access research results as resources via MCP protocol

Related MCP server: AI Blog MCP Agent

Features

  • Implements the MCP protocol over stdio for local, secure operation

  • Defensive programming: error handling, timeouts, and validation

  • Logging and debugging via stderr

  • Compatible with DXT host environments

Directory Structure

.
├── manifest.json         # DXT manifest (see MANIFEST.md for spec)
├── src/
│   ├── index.ts         # MCP server entrypoint (Node.js, stdio transport)
│   └── assistant/       # Python research logic
│       └── run_research.py
├── README.md            # This documentation
└── ...

Installation & Setup

  1. Clone the repository and install dependencies:

    git clone <your-repo-url>
cd mcp-server-ollama-deep-researcher
npm install

  2. Install Python dependencies for the assistant:

    cd src/assistant
pip install -r requirements.txt
# or use pyproject.toml/uv if preferred

  3. Set required environment variables for web search APIs:

    • For Tavily: TAVILY_API_KEY

    • For Perplexity: PERPLEXITY_API_KEY

    • For Exa: EXA_API_KEY (Get yours at https://dashboard.exa.ai/api-keys)

    • Optional: LANGSMITH_API_KEY, LANGSMITH_TRACING=true, OLLAMA_BASE_URL (defaults to http://localhost:11434)

    • Example:

      export TAVILY_API_KEY=your_tavily_key
export PERPLEXITY_API_KEY=your_perplexity_key
export EXA_API_KEY=your_exa_key

    • Prefer not to keep plaintext keys on disk? See Optional: secure secrets with 1Password below.

  4. Build the TypeScript server (if needed):

    npm run build

  5. Run the extension locally for testing:

    node dist/index.js
# Or use the DXT host to load the extension per DXT documentation

Usage

  • Research a topic:

    • Use the research tool with { "topic": "Your subject" }

  • Get research status:

    • Use the get_status tool

  • Configure research parameters:

    • Use the configure tool with any of: maxLoops, llmModel, searchApi

Manifest

See manifest.json for the full DXT manifest, including tool schemas and resource templates. Follows DXT MANIFEST.md.

Logging & Debugging

  • All server logs and errors are output to stderr for debugging.

  • Research subprocesses are killed after 30 minutes to prevent hangs.

  • Invalid requests and configuration errors return clear, structured error messages.

Security & Best Practices

  • All tool schemas are validated before execution.

  • API keys are required for web search APIs and are never logged.

  • MCP protocol is used over stdio for local, secure communication.

Testing & Validation

  • Validate the extension by loading it in a DXT-compatible host.

  • Ensure all tool calls return valid, structured JSON responses.

  • Check that the manifest loads and the extension registers as a DXT.

Troubleshooting

  • Missing API key: Ensure TAVILY_API_KEY, PERPLEXITY_API_KEY, or EXA_API_KEY is set in your environment depending on which search API you're using.

  • Python errors: Check Python dependencies and logs in stderr.

  • Timeouts: Research subprocesses are limited to 30 minutes.

Search API Comparison

  • Tavily: Fast, comprehensive web search with raw content extraction

  • Perplexity: AI-powered search with natural language summaries and citations

  • Exa: Neural search engine optimized for semantic search with highlights

Optional: secure secrets with 1Password

If you use 1Password, you can keep plaintext API keys off your disk and out of your AI coding agent's context. This is opt-in and additive — the plaintext setup above keeps working unchanged. Prerequisites: 1Password for Mac or Linux, the op CLI (brew install --cask 1password-cli), and sqlite3.

Create one 1Password Environment holding these eight variables (the four keys are secret; the rest are non-secret config):

Variable

Secret?

TAVILY_API_KEY, PERPLEXITY_API_KEY, EXA_API_KEY, LANGSMITH_API_KEY

yes

OLLAMA_BASE_URL, LANGSMITH_TRACING, LANGSMITH_ENDPOINT, LANGSMITH_PROJECT

no

You can import an existing .env directly when creating the Environment. Once it exists, choose any of the three mechanisms below (A is the AI-coding pattern; B is 1Password's recommended MCP launch; C is a fallback for hosts that can't run op).

A. Mounted .env + validation hook (keeps plaintext out of the LLM context)

1Password Environments mount a local .env as a UNIX named pipe (FIFO): contents are streamed on demand to authorized readers and never stored on disk. A Claude Code PreToolUse hook validates the mount before the agent runs shell commands.

  1. In the 1Password desktop app, open your Environment → Destinations → Local .env file → Choose file path → .env → Mount. Verify with cat .env (approves via Touch ID; auth lasts until 1Password locks).

  2. .1password/environments.toml (committed) tells the hook which paths to validate — already set to mount_paths = [".env"].

  3. Install the validation hook locally:

    git clone https://github.com/1Password/agent-hooks /tmp/agent-hooks
/tmp/agent-hooks/install.sh --agent claude-code --target-dir .

    This creates .claude/claude-code-1password-hooks-bundle/ and .claude/settings.json (both gitignored). The hook is fail-open: if 1Password or sqlite3 is unavailable it allows execution, so non-1Password contributors are unaffected.

  4. Test it: echo '{"command":"echo test","workspace_roots":["'"$PWD"'"]}' | .claude/claude-code-1password-hooks-bundle/bin/run-hook.sh 1password-validate-mounted-env-files → {"permission":"allow"} while unlocked, deny with fix instructions when locked.

B. op run --environment for the MCP server launch

Copy .mcp.json.1password.example → .mcp.json (gitignored), replace <ENVIRONMENT_ID> with your Environment ID, and your MCP host will resolve secrets at launch via op run. Non-secret config stays in the env block; secrets are injected from the Environment. The template uses the full path /opt/homebrew/bin/op because GUI-launched hosts (e.g. Claude Desktop) don't inherit your shell $PATH — adjust if your op lives elsewhere (which op).

Fallback if your op CLI lacks --environment (the environment subcommand is part of the 1Password Environments beta and is absent from some builds, e.g. op v2.34.x): use op run --env-file .env against a plain .env of op:// references instead. Create the item once (op item create --vault "Your Vault" --category "Login" --title "ollama-deep-researcher" "TAVILY_API_KEY[concealed]=..." …), then write a gitignored .env of references and point the launcher at it:

# .env (gitignored) — references only, no plaintext
# TAVILY_API_KEY=op://Your Vault/ollama-deep-researcher/TAVILY_API_KEY
# …
op run --env-file .env -- node build/index.js

The same .env also powers Docker (see below), so one references file covers both launch paths. op run prompts Touch ID once per launch.

C. op inject template for .mcp.json

For MCP hosts that can't use op run, copy .mcp.json.template → a working file, replace <vault> with your vault name, then materialize the {{ op://... }} references into real values:

op inject -i .mcp.json.template -o .mcp.json

op inject writes the output with filemode 0600. .mcp.json is gitignored. Recompile after rotating secrets in 1Password. (Requires op CLI with standard item/vault support; the op run --environment form in option B additionally requires 1Password Environments beta.)

Docker

docker-compose.yml interpolates all eight vars from the environment. Run compose through op run --env-file so the op:// references in .env (or the FIFO mount, if you set one up in A) are resolved and forwarded into the container:

op run --env-file .env -- docker compose up

References

Available Tools

3 tools
configureC

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

ParametersJSON Schema
NameRequiredDescriptionDefault
maxLoopsNoMaximum number of research loops (1-10)
llmModelNoOllama model to use (e.g. llama3.2)
searchApiNoSearch 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
NameRequiredDescriptionDefault
_dummyYesNo 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
NameRequiredDescriptionDefault
topicYesThe 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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
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
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • AI Blog MCP Agent

    BhavinXAgheda
    F
    license
    Not graded
    quality
    D
    maintenance
    A local AI-powered research agent that searches the web, fetches real content, and generates grounded answers using a local Ollama model, exposed as an MCP tool for Claude Desktop.

  • deep-research

    troyhantech
    A
    license
    Not graded
    quality
    C
    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.
    17
    MIT

  • myscrape

    Bonifatius94
    A
    license
    Not graded
    quality
    A
    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.
    1
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cam10001110101/mcp-server-ollama-deep-researcher'

If you have feedback or need assistance with the MCP directory API, please join our Discord server