Skip to content
Ollama MCP Bridge

MCP × Ollama

Your Ollama clients just learned to use tools.

An API layer in front of Ollama that transparently adds tools from multiple MCP servers to every chat request. Point any Ollama SDK at the bridge — the tool-calling loop runs server-side and the answer streams straight back.

Quick start How it works

uv tool install --upgrade ollama-mcp-bridge Python 3.10+ · MIT

client.py the only change is the host 
from ollama import Client

# the bridge, not Ollama — that is the whole change
client = Client(host="http://localhost:8000")

for chunk in client.chat(
    model="qwen3",
    messages=[{"role": "user", "content": "Weather in Paris?"}],
    stream=True,
):
    print(chunk["message"]["content"], end="")

inside that one call

you Weather in Paris?
bridge forwards it to Ollama with every MCP tool attached
ollama asks for weather.get_current_temperature
bridge runs it on your MCP server, feeds the result back 12°C, light rain
ollama asks for weather.get_forecast — round 2
bridge runs it, loops again tomorrow 15°C, sunny
answer It's 12°C in Paris right now with light rain. Tomorrow looks better — 15°C and sunny.

Home

What it does

The bridge sits in front of your Ollama server and speaks the same API. Every endpoint behaves identically except /api/chat, which injects the tools from all connected MCP servers and runs the tool-calling loop server-side.

Your client never sees the loop. It sends one chat request and gets one answer back — with tool results already folded in, streamed in real time.

  • Drop-in replacement

    Same endpoints, same payloads. Change the host your Ollama client points at and nothing else. Existing SDKs and libraries keep working.

    API reference

  • Any MCP transport

    Local processes over stdio, remote servers over StreamableHTTP or SSE. The transport is inferred from the config — you just declare the server.

    Configure servers

  • Multi-round tool calling

    The bridge loops until the model stops asking for tools, then returns the final answer. Cap it with --max-tool-rounds when you want a ceiling.

    How it works

  • Per-server tool filtering

    Allow-list or deny-list the tools each server exposes, so the model only sees what you want it to reach for.

    Tool filtering

  • Local and cloud models

    Point it at a local Ollama, a remote one, or Ollama's cloud models. Add upstream headers when there's a gateway or auth layer in between.

    CLI options

  • Runs anywhere

    uvx, pip, or pre-built multi-arch Docker images for linux/amd64 and linux/arm64 published on every release.

    Docker

Get running in a minute

uv tool install --upgrade ollama-mcp-bridge
ollama-mcp-bridge

pip install --upgrade ollama-mcp-bridge
ollama-mcp-bridge

docker run -p 8000:8000 \
  -e OLLAMA_URL=http://host.docker.internal:11434 \
  -v "$PWD/mcp-config.json:/mcp-config.json" \
  -w / \
  ghcr.io/jonigl/ollama-mcp-bridge:latest

uvx ollama-mcp-bridge

You'll need an mcp-config.json with at least one server in it, and an Ollama server running.

Full quick start Installation options

  • MCP Client for Ollama — a TUI client for MCP servers with Ollama. Multi-server support, model switching, streaming, tool management, human-in-the-loop, thinking mode and saved preferences.
  • simple-ollama-chat — a small chat UI that works with the bridge, handy for exercising tool-augmented models quickly.