MCP Ollama Bridge Powers Agents — Local Tools That Win

A local chatbot answers questions. A local agent does work: reads the runbook, checks the dashboard, files the ticket. The gap between those two is tool access, and hand-wiring tools per project doesn't scale.

MCP fixes the wiring. It's an open standard where servers expose tools, data, and prompts the same way for every host. Write a server once and any compatible agent can use it. You'll feel the payoff the second time you reuse a server untouched.

The bridge connects that standard to Ollama. Your private local model gains the same tool ecosystem cloud agents enjoy, with prompts that never leave your machine.

But agents with tools can break things faster than chatbots ever could. This guide builds the bridge with guardrails from the start.

Why MCP Exists — USB for Agent Tools

Every agent project starts with glue code: custom functions for search, files, tickets, each wired to one model SDK. The second project rewrites all of it. The third adds auth. By the fourth, tool plumbing outnumbers agent logic.

MCP breaks the cycle the way USB broke peripheral chaos: one standard plug, many devices. A filesystem server, a docs server, a ticketing server — each speaks JSON-RPC 2.0, each advertises capabilities the same way, each works with any host from Claude Code to a local bridge.

The 2026-07-28 spec sharpened the model: stateless requests carrying version and capabilities per call, a server/discover handshake, and long-running work moved to an opt-in tasks extension. Stateless servers survive transport changes; session-based ones broke on upgrade.

Configure the Bridge — Servers, Model, and Policy

The bridge config declares servers (how to launch each one, with what env) and policy (which model, where Ollama lives, when to ask approval). Read-only servers run free; write servers require approval. That two-line policy is your primary safety boundary.

Prefer stdio servers for local processes and Streamable HTTP for shared ones. Scope every credential per server — the docs server gets a docs path, the tickets server gets its own token, nothing shares the engineer's keys.

Keep the file in version control next to your Modelfile. Agent behavior is now configuration, and configuration diffs are reviewable in a way that demo-day click-ops never is.

{
  "mcpServers": {
    "docs": {
      "command": "python",
      "args": ["/srv/mcp/docs_server.py"],
      "env": { "DOCS_ROOT": "/srv/docs", "MODE": "read-only" }
    },
    "tickets": {
      "command": "node",
      "args": ["/srv/mcp/tickets_server.js"],
      "env": { "API_TOKEN": "${TICKETS_TOKEN}", "REQUIRE_APPROVAL": "true" }
    }
  },
  "bridge": {
    "model": "qwen3-coder:30b",
    "host": "http://localhost:11434",
    "approval": { "writes": "always", "reads": "never" }
  }
}

The Execution Loop — List, Present, Approve, Execute

The loop is mechanical: bridge fetches tools/list from each server, translates schemas into the chat API's tool format, sends the user prompt plus tools to Ollama, executes any requested calls (after approval), appends results as tool messages, and repeats until the model answers directly.

The subtlety is the Tools-versus-Resources split. Tools are model-chosen actions with side effects; Resources are app-chosen context the bridge attaches. Letting the model invent resource URIs is a prompt-injection hole — the app decides what the model sees, the model decides what it does.

Prompts (templated workflows exposed by servers) complete the picture: a triage prompt can bundle the right resources with the right tool subset for on-call work, so the model starts constrained instead of omnipotent.

[
  {
    "name": "search_docs",
    "description": "Search local runbooks by keyword. Returns up to 5 matches.",
    "input_schema": {
      "type": "object",
      "properties": { "q": { "type": "string", "description": "keyword, e.g. checkout-500" } },
      "required": ["q"]
    }
  },
  {
    "name": "file_ticket",
    "description": "File an incident ticket. Requires human approval.",
    "input_schema": {
      "type": "object",
      "properties": {
        "title": { "type": "string" },
        "severity": { "type": "string", "enum": ["low", "high", "critical"] }
      },
      "required": ["title", "severity"]
    }
  }
]

Build a Minimal Bridge in Fifty Lines

The minimal bridge is under fifty lines: translate tools/list into chat tools, loop chat plus approval plus execute. The example above shows the shape — the approval assert is the load-bearing line, not decoration.

Real bridges add timeouts, retries, result truncation (tool output can flood context), and per-server logging. Each addition is boring infrastructure, and each one prevents a class of incident.

Use a tool-capable 2026 model (30B-class agent builds or Qwen coders) with low temperature for structured calls. Small chat models describe tool calls in prose instead of emitting them — that failure looks like model stupidity but is really model selection.

from ollama import Client
import json, subprocess

client = Client(host="http://localhost:11434")
tools = json.load(open("tools.json"))  # translated from MCP tools/list

messages = [{"role": "user", "content": "File a ticket for the checkout 500s"}]
resp = client.chat(model="qwen3-coder:30b", messages=messages, tools=tools)
msg = resp.message
if msg.tool_calls:
    for call in msg.tool_calls:
        print(f"APPROVAL: {call.function.name}{call.function.arguments}")
        assert input("approve? [y/N] ") == "y", "denied"
        # execute against the MCP server, append result, loop
        messages.append({"role": "tool", "content": execute(call)})

Bridge vs Cloud Functions vs Bespoke Glue

Compared with cloud functions, the bridge trades frontier reasoning for privacy and zero marginal cost. Compared with bespoke scripts, it trades an afternoon of config for freedom from perpetual glue maintenance. Both trades favor the bridge for internal workflows.

The ceiling is real: local 30B-class models fumble multi-hop plans that frontier cloud models nail. Route accordingly — local agents own triage, lookup, and filing; cloud owns the gnarliest reasoning.

The ecosystem compounds: every new MCP server (500+ app connectors exist via bridges like Rube) instantly extends your local agent. Bespoke-script teams add integrations one painful PR at a time.

Operate It Like Production — Supervise, Log, Rehearse

Operate the bridge like a small production service: supervise server processes, health-check tools/list on boot, rotate per-server tokens, and retain append-only invocation logs. Review the logs weekly — they show which tools earn their keep and which confuse the model.

Version-pin everything: model tags, server revisions, bridge config, protocol version. The 2026 transport migration broke unpinned session-based servers silently; pinned stateless ones sailed through.

Finally, rehearse failure: kill a server mid-task and watch the agent report the outage cleanly instead of hallucinating results. An agent that admits its tools are down is trustworthy; one that invents answers is a liability.