A
licenseNot graded
qualityB
maintenanceProvides web search and page fetching capabilities using Ollama's API.
MIT
ollama-web-search-mcp
by wzul
The server provides a web_search tool via Ollama's web search API. It enables you to:
Search the web with a required
queryand optionalcount(1-10 results, default 5)Get results as a numbered list including title, URL, and content snippet
Discover niche or lesser-indexed content (e.g., personal blogs) that might be missed by other search backends
Provides a web_search tool backed by Ollama's web search API, allowing searches for sites and content that other search backends may miss (like small personal blogs).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ollama-web-search-mcpsearch wanzul.net and show me the top 5 results"
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 Web Search MCP Server
An MCP server that exposes Ollama's web search API as a web_search tool for Claude Code.
Use it when the built-in Claude Code WebSearch returns no results for a site — the Ollama search backend indexes sites (like small personal blogs) that other backends miss.
Features
Single
web_searchtool:query(required) +count(optional, 1–10, default 5)Reads your API key from the environment — never hardcoded, never committed
10s outbound timeout, friendly errors for missing key / bad status / network failure
Pure Node.js stdio server — no build step, no runtime outside Node 18+
Related MCP server: CC Web MCP
Prerequisites
Install
git clone https://github.com/wzul/ollama-web-search-mcp.git
cd ollama-web-search-mcp
npm installRegister with Claude Code
Register the server globally (available in every project) with one command:
claude mcp add --scope user ollama-web-search -- node "$HOME/ollama-web-search-mcp/index.js"Why
--scope user:claude mcp adddefaults to the project-local scope. Without this flag the server is registered to the current project only and silently won't load when Claude Code is started from any other directory. Ifweb_searchdoesn't appear after a restart, the registration is almost certainly project-scoped — fix it withclaude mcp add --scope user ...(thencd <repo> && claude mcp remove ollama-web-search -s localto drop the stale entry).
Or add it manually to the top-level mcpServers object in ~/.claude.json:
{
"mcpServers": {
"ollama-web-search": {
"command": "node",
"args": ["/absolute/path/to/ollama-web-search-mcp/index.js"]
}
}
}Set your API key
The server reads the key from the environment, so export it in your shell profile (~/.zshrc, ~/.bashrc, etc.):
export OLLAMA_API_KEY="your-ollama-api-key"Security: use a key you have not shared anywhere. If a key was ever pasted into a chat, log, or screenshot, rotate it at ollama.com/settings/keys before using it here.
Then restart Claude Code — the web_search tool will be available in every session.
(Optional) Disable the built-in WebSearch
Claude Code ships a built-in WebSearch tool. If you want your sessions to use only the Ollama-backed web_search, deny the built-in one in ~/.claude/settings.json:
{
"permissions": {
"deny": ["WebSearch"]
}
}deny takes precedence over allow, and rules merge across scopes, so this stays blocked even if another settings file allows it. Restart Claude Code afterwards. You can verify with /permissions that WebSearch is no longer offered.
Usage
Ask Claude Code to search, e.g.:
web_search "wanzul.net"
web_search "best 5G plan malaysia" count 10Results come back as a numbered list: title, URL, and content snippet.
Test
npm testRuns 10 tests: unit tests for the fetch wrapper and result formatting (mocked fetch) plus a live stdio smoke test that drives the MCP protocol.
Helper skill (optional)
The repo ships a copy-paste install skill at .claude/skills/install-ollama-web-search/. Install it so you (or Claude Code) can reproduce these steps on demand:
mkdir -p ~/.claude/skills
cp -r .claude/skills/install-ollama-web-search ~/.claude/skills/Once installed, an agent can follow it (or ask "install ollama-web-search") instead of retyping commands from memory.
Layout
index.js— MCP stdio server +searchOllama/formatResultsexportstest.js— unit tests (mocked fetch) + stdio smoke testpackage.json— deps (@modelcontextprotocol/sdk) and scripts
License
MIT
Available Tools
1 toolweb_searchA
Search the web using Ollama's web search API. Returns a numbered list of results with title, URL, and content snippet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results to return (1-10, default 5) | |
| query | Yes | Search query |
TDQS
A4/5.0
Behavior3/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 for behavioral disclosure. It does state the return format, which is a useful behavioral trait. However, it does not mention potential network/API side effects, rate limits, or explicitly confirm that this is a read-only operation, leaving some 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 sentence that immediately states the action and the expected output, with no redundant details. It is concise, well-structured, and easy to parse.
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 tool, the description and schema together provide enough context: what to search, how many results, and the output format. It lacks optional details like examples or error handling, but these are not critical for a tool of this complexity.
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 input schema fully describes both parameters ('query' and 'count') with clear descriptions and constraints. The description adds no additional parameter-specific semantics beyond the schema, so the baseline of 3 applies due to 100% schema coverage.
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 uses a specific verb ('Search the web'), identifies the resource ('Ollama's web search API'), and states the output format (numbered list with title, URL, snippet). This makes the tool's function unmistakable. No sibling tools exist, so differentiation is not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No alternatives are listed, but the purpose statement clearly implies when to use it: whenever web search results are needed. The context is evident from the description, though it does not include explicit when-not-to-use guidance or exclusions.
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 update
v1.0.0- First observed
web_search
TDQS
A4.1/5.0
Scored across 1 tool
Disambiguation5/5
With only a single tool, there is no possibility of confusing it with other tools. The purpose of web_search is clear and unambiguous.
Naming Consistency5/5
The tool name follows a consistent verb_noun pattern (web_search), which is predictable and readable even as the only tool in the server.
Tool Count3/5
The server has only one tool, which is on the thin side of the typical 3-15 range. For a dedicated search utility, one tool can be sufficient, but it feels minimal and lacks auxiliary features.
Completeness5/5
The tool fully covers the domain of web search by returning a numbered list of results with titles, URLs, and snippets. There are no obvious dead ends or missing critical operations for this simple purpose.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Related MCP Connectors
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Web search, scraping, Google Trends and data lookups. Paid per call in USDC on Base via x402.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides web search and page fetching tools for third-party models (e.g., DeepSeek, Qwen, Kimi) in Claude Code, with configurable search backends, Markdown output, and safety boundaries.63MIT
- FlicenseNot gradedqualityCmaintenanceA drop-in replacement for Claude's built-in web_search tool that automatically tracks usage and provides multiple search backends.-
- AlicenseAqualityDmaintenanceEnables performing web searches and fetching web page content via Ollama's hosted APIs, providing search results and raw page data.21MIT