What can you do with this server?

This MCP server exposes Ollama's hosted web search and web fetch APIs as tools for any MCP client. * web_search: run a web search with a required query and optional max_results (default 10), returning search results. * web_fetch: fetch a single absolute url, returning page content and related metadata. * MCP integration: use it from clients like Claude Desktop, Cursor, OpenCode, and MCPorter via stdio or HTTP. * Cloud-backed: requires an Ollama account/API key and sends queries/URLs to Ollama's cloud service, so avoid confidential data.

Which integrations are available for this server?

Provides tools for performing web searches and fetching web page content using Ollama's hosted search API.

How do I use ollama-websearch-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ollama-websearch-mcp search for latest AI research papers" 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.

ollama-websearch-mcp

by akopper

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Ollama Search MCP Server

MCP server exposing Ollama's hosted web search and web fetch APIs as tools for any MCP client.

Overview

The server provides two tools:

web_search: search the web through Ollama's hosted search API
web_fetch: fetch a web page and return its content

It works with any MCP client, including Claude Desktop, Cursor, OpenCode, and MCPorter. An Ollama account and API key are required for the cloud endpoints.

Related MCP server: mcp-web-tools

Requirements

Python 3.10+
MCP Python SDK v2
Ollama account (for cloud API access)

Installation

PyPI

uvx ollama-search-mcp
# or install the console script
pip install ollama-search-mcp

uvx runs the server on demand, which is the recommended command for MCP client configuration.

From Git

uvx --from git+https://github.com/akopper/ollama-search-mcp ollama-search-mcp

Pin a release with @<tag>:

uvx --from 'git+https://github.com/akopper/ollama-search-mcp@v0.2.1' ollama-search-mcp

Docker

The Docker image defaults to HTTP mode.

# HTTP mode (default) - for remote usage
docker run -d -p 8000:8000 -e OLLAMA_API_KEY=your-api-key ghcr.io/akopper/ollama-search-mcp

# stdio mode - for Claude Desktop/Cursor
docker run -it --rm -e OLLAMA_API_KEY=your-api-key ghcr.io/akopper/ollama-search-mcp --stdio

Docker Compose

cp .env.example .env
# Edit .env with your API key
docker-compose up -d

From Source

git clone https://github.com/akopper/ollama-search-mcp.git
cd ollama-search-mcp
pip install -e .

Configuration

Environment Variables

Variable	Description	Default
`OLLAMA_API_KEY`	API key for Ollama cloud services	None
`OLLAMA_HOST`	Host URL for Ollama	`https://ollama.com`

Getting an API Key

Go to ollama.com
Sign in to your account
Navigate to API settings
Generate an API key

Search queries and fetched URLs are sent to Ollama's cloud service. Do not send confidential data in search queries.

Usage

Running the Server

stdio mode (default, for Claude Desktop/Cursor)

# Using the installed command
ollama-search-mcp

# Explicit stdio (same as the default)
ollama-search-mcp --stdio

# Or on demand with uvx
uvx ollama-search-mcp

# Or directly with Python
python -m ollama_search_mcp.server

HTTP mode (for remote usage)

python -m ollama_search_mcp.server --http

The server starts on http://localhost:8000/mcp by default. Use --host and --port to change the bind address, for example inside a container:

python -m ollama_search_mcp.server --http --host 0.0.0.0 --port 8000

Claude Desktop Integration

Add the following to your Claude Desktop configuration:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "ollama-search": {
      "command": "uvx",
      "args": ["ollama-search-mcp"],
      "env": {
        "OLLAMA_API_KEY": "your-api-key-here"
      }
    }
  }
}

A globally installed ollama-search-mcp console script also works as command.

Cursor Integration

Add to Cursor settings (or .cursor/mcp.json in the project):

{
  "mcpServers": {
    "ollama-search": {
      "command": "uvx",
      "args": ["ollama-search-mcp"],
      "env": {
        "OLLAMA_API_KEY": "your-api-key-here"
      }
    }
  }
}

OpenCode Integration

Add the server to your ~/.config/opencode/opencode.jsonc:

{
  "mcp": {
    "servers": {
      "ollama-search": {
        "type": "local",
        "command": ["uvx", "ollama-search-mcp"],
        "environment": {
          "OLLAMA_API_KEY": "{env:OLLAMA_API_KEY}"
        }
      }
    }
  }
}

Then run opencode mcp list to verify the connection; it should report ✓ ollama-search connected.

If OpenCode is started from a desktop session instead of a login shell, it usually does not inherit ~/.bashrc. Two things then break: ~/.local/bin is missing from PATH (so uvx cannot be spawned) and exported variables like OLLAMA_API_KEY are unset (so {env:OLLAMA_API_KEY} becomes an empty string). In that case use an absolute command path and read the key from a file:

mkdir -p ~/.config/opencode/secrets
printf '%s' 'your-api-key-here' > ~/.config/opencode/secrets/ollama-search.key
chmod 600 ~/.config/opencode/secrets/ollama-search.key

{
  "mcp": {
    "servers": {
      "ollama-search": {
        "type": "local",
        "command": ["/home/you/.local/bin/uvx", "ollama-search-mcp"],
        "environment": {
          "OLLAMA_API_KEY": "{file:./secrets/ollama-search.key}"
        }
      }
    }
  }
}

{file:…} paths are resolved relative to the config file, and ~/ is expanded, so {file:~/.config/opencode/secrets/ollama-search.key} works as well. Keep the file free of a trailing newline, otherwise it becomes part of the header value. If your OpenCode version does not support {file:…} yet, put the key into environment literally instead.

Symptom	Cause	Fix
`mcp connect failed … NotFound: ChildProcess.spawn (uvx ollama-search-mcp)`	`uvx` is not on the `PATH` OpenCode inherited	use the absolute `uvx` path as shown above
Tools work but `web_search` returns `Error executing tool web_search`, log says `Authorization header with Bearer token is required for web search`	`OLLAMA_API_KEY` was substituted with an empty string	read it from a file as shown above, set it literally, or export it in the environment that starts OpenCode

OpenCode Skill

The repository ships an OpenCode skill that teaches the agent how to call the server's tools. It lives at .opencode/skills/ollamawebsearch/SKILL.md.

Install it globally so it is available in every OpenCode project:

mkdir -p ~/.config/opencode/skills/ollamawebsearch
cp .opencode/skills/ollamawebsearch/SKILL.md \
  ~/.config/opencode/skills/ollamawebsearch/SKILL.md

To keep the installed skill in sync with this repository, link it instead:

mkdir -p ~/.config/opencode/skills
ln -s "$PWD/.opencode/skills/ollamawebsearch" \
  ~/.config/opencode/skills/ollamawebsearch

For a single project, copy the directory to <project>/.opencode/skills/ollamawebsearch/. OpenCode also discovers skills in ~/.claude/skills and ~/.agents/skills.

The skill is registered as ollamawebsearch; load it with @ollamawebsearch or the skill tool. OpenCode reloads skills automatically, so no restart is required. When working inside this repository, OpenCode already discovers the skill from .opencode/skills.

MCPorter Integration

MCPorter can discover and use this server. Example config/mcporter.json:

{
  "mcpServers": {
    "ollama-search": {
      "description": "Ollama web search and web fetch MCP server",
      "command": "uvx",
      "args": ["ollama-search-mcp"],
      "env": {
        "OLLAMA_API_KEY": "$env:OLLAMA_API_KEY"
      }
    }
  }
}

Or run ad-hoc:

# List tools
npx mcporter list ollama-search

# Call a tool
npx mcporter call ollama-search.web_search query:python max_results:10

Available Tools

web_search

Search the web through Ollama's hosted search API.

Parameters:

query (required): the search query
max_results (optional): maximum number of results (default: 10)

Returns: a dictionary with a results list; each entry contains title, url, and content.

web_fetch

Fetch a single web page.

Parameters:

url (required): the absolute URL to fetch

Returns: a dictionary containing the page title, content, and links.

Development

Setup

python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

# Or with uv
uv sync --extra dev

Running Tests

# Run all tests
pytest

# Run with coverage
pytest --cov --cov-report=term-missing

# Run a single test
pytest tests/test_server.py::TestWebSearch::test_web_search_returns_dict

Linting and Formatting

ruff check src/ tests/
ruff format --check src/ tests/

Building Distributions

python -m build
python -m twine check dist/*

Running the Server for Development

# stdio mode with mcp dev
mcp dev src/ollama_search_mcp/server.py

# Or run directly
python -m ollama_search_mcp.server

Releasing

See RELEASING.md for versioning, tagging, and PyPI trusted publishing.

License

MIT. See LICENSE.

Available Tools

2 tools

web_fetchA

Fetch the content of a web page.

Args: url: The absolute URL to fetch.

Returns: A dictionary containing the fetched content with html, text, and metadata.

Name	Required	Description	Default
`url`	Yes

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It mentions the return dictionary structure but does not disclose potential side effects, error handling, rate limits, or that it is a read-only operation, though 'fetch' implies this.

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 concise and well-structured with clear sections for purpose, arguments, and returns. Every sentence contributes value without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema, the description is mostly complete. However, it lacks usage guidelines and does not mention any limitations or behavioral assumptions (e.g., whether it follows redirects).

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?

Schema description coverage is 0%, so the description must compensate. It adds 'absolute URL' to the parameter meaning, but this is minimal and does not elaborate on format or examples. However, with only one parameter, the provided clarification is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Fetch the content') and the resource ('a web page'). It also distinguishes itself from the sibling tool web_search by indicating direct URL fetching rather than searching.

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 web_search or other alternatives. There is no explicit 'use when' or 'instead of' context.

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

web_searchA

Perform a web search using Ollama's hosted search API.

Args: query: The search query to run. max_results: Maximum number of results to return (default: 10).

Returns: A dictionary containing search results with title, url, and snippet.

Name	Required	Description	Default
`query`	Yes
`max_results`	No

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.5/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 burden. It mentions the return format (dictionary with title, url, snippet) but does not disclose behavioral traits such as read-only nature, rate limits, authentication, or side effects. The return description is redundant given the output schema.

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 structured with a clear one-sentence purpose followed by concise parameter definitions and a one-line return description. Every line serves a purpose and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter search tool with an output schema, the description covers the essential purpose and parameters. However, it lacks any explicit guidance on selecting this tool over web_fetch or any operational caveats, making it slightly incomplete.

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

Parameters5/5

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

The input schema lacks descriptions (0% coverage), so the description's Args section adds necessary meaning. It clearly defines query and max_results, including the default for max_results, providing full semantic clarity for both parameters.

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 it performs a web search using Ollama's hosted search API, which is a specific verb and resource. It does not explicitly differentiate from web_fetch, but the purpose is unambiguous.

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 web_search versus web_fetch, and no mention of scenarios or exclusions. It simply restates the tool's function without actionable usage context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.1.0Aug 9, 2026
- First observedweb_fetch
- First observedweb_search

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

A3.7/5.0

Scored 2026-08-09 22:55 across 2 tools

Disambiguation5/5

Web search and web fetch are clearly distinct operations with no overlap. An agent can easily tell them apart based on their names and descriptions.

Naming Consistency5/5

Both tools follow the same web_<verb> pattern, making the naming predictable and consistent. The convention is uniform across the entire set.

Tool Count3/5

Only two tools are provided, which feels thin for a general-purpose websearch server. The count is borderline but acceptable for a narrow scope.

Completeness4/5

Search and fetch cover the core operations for a websearch tool. Minor gaps exist (e.g., no advanced filtering or content extraction options), but no critical dead ends are apparent.

Maintenance

ActivityMaintained

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Geonode MCP ServerA
com.geonode
Web data for agents. Extract web pages, crawl websites, discover URLs, and search the web.
Web Scraping Browser Automation Search
161
https://mcp.geonode.com/mcp
BrowsingBee
io.github.theindianappguy
Hosted browser for agents: open pages, search the web, extract data, read PDFs and take screenshots.
Browser Automation Web Scraping Agent Orchestration
1
https://www.browsingbee.com/mcp
seltz-ai-seltz-mcp
ai.seltz
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Search Browser Automation Web Scraping
2
https://mcp.seltz.ai/mcp
Levirge Search
com.levirge
Web search and page reading for AI agents, including JSON APIs, RSS feeds and YouTube.
Research & Data Search
1
https://search.levirge.com/mcp

Related MCP Servers

Jina Web Search MCP
Web Scraping Search RAG Systems
hypersniper05
A
license
Not graded
quality
D
maintenance
Enables web content retrieval and semantic search capabilities through the Jina AI API. Provides tools to fetch content from URLs and perform intelligent web searches with natural language queries.
Updated a year ago (2025-08-08 16:00 UTC)
3
MIT
mcp-web-tools
Browser Automation Web Scraping Search
pietz
A
license
A
quality
D
maintenance
Provides web access capabilities for LLMs including search, fetching, content extraction, PDF reading, image viewing, and screenshots.
Updated a year ago (2025-12-09 10:58 UTC)
3
46
MIT
MCP Search & Fetch
Browser Automation Web Scraping Search
lkiesow
A
license
Not graded
quality
F
maintenance
Provides web search and page fetching capabilities using Ollama's API.
Updated 8 days ago (2026-11-01 23:27 UTC)
MIT
Ollama Web Search
Web Scraping Search
deXterbed
A
license
A
quality
B
maintenance
Enables web search and web fetch operations using Ollama's hosted APIs, allowing MCP clients to search the web and retrieve page content.
Updated 2 months ago (2026-09-07 12:46 UTC)
2
MIT

Ollama Search MCP Server

Overview

Requirements

Installation

PyPI

From Git

Docker

Docker Compose

From Source

Configuration

Environment Variables

Getting an API Key

Usage

Running the Server

stdio mode (default, for Claude Desktop/Cursor)

HTTP mode (for remote usage)

Claude Desktop Integration

Cursor Integration

OpenCode Integration

OpenCode Skill

MCPorter Integration

Available Tools

web_search

web_fetch

Development

Setup

Running Tests

Linting and Formatting

Building Distributions

Running the Server for Development

Releasing

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Jina Web Search MCP

mcp-web-tools

MCP Search & Fetch

Ollama Web Search