Ollama MCP Tool for NanoClaw

Add Ollama Integration

This skill adds a stdio-based MCP server that exposes local Ollama models as tools for the container agent. Claude remains the orchestrator but can offload work to local models served by the Ollama daemon on the host, and can optionally manage the model library directly. Ollama runs locally and is keyless — there are no credentials to thread; the only configuration is the daemon's base URL.

Core tools (always available):

• ollama_list_models — list installed models with name, size, and family (GET /api/tags)
• ollama_generate — send a prompt to a specified model and return the response (POST /api/generate)

Management tools (opt-in via OLLAMA_ADMIN_TOOLS=true):

• ollama_pull_model — pull (download) a model from the Ollama registry (POST /api/pull)
• ollama_delete_model — delete a locally installed model to free disk space (DELETE /api/delete)
• ollama_show_model — show model details: modelfile, parameters, and architecture info (POST /api/show)
• ollama_list_running — list models currently loaded in memory with memory usage and processor type (GET /api/ps)

The skill ships the MCP server source (and its tests) in this folder and copies them into the agent-runner tree at install time, then registers the server in index.ts and forwards host env vars in container-runner.ts. Registering the server is enough to expose its tools — the agent's allow-pattern (mcp__ollama__*) is derived from the registered server name.

Phase 1: Pre-flight

Check if already applied

Check if container/agent-runner/src/ollama-mcp-stdio.ts exists. If it does, skip to Phase 3 (Configure).

Check prerequisites

Verify Ollama is installed and its daemon is reachable. On the host:

curl -s http://127.0.0.1:11434/api/tags | head

If the request fails:

1. Install Ollama from https://ollama.com/download.
2. Start it (the desktop app runs the daemon, or run ollama serve).
3. Confirm the daemon answers: curl -s http://127.0.0.1:11434/api/tags.

If no models are installed, suggest pulling one:

You need at least one model. For example:

ollama pull gemma3:1b        # Small, fast (~1GB)
ollama pull llama3.2         # Good general purpose (~2GB)
ollama pull qwen3-coder:30b  # Best for code tasks (~18GB)

Phase 2: Apply Code Changes

Copy the skill's source and tests into both trees

This skill reaches into both the container (Bun) tree and the host (Node) tree, so its files go into both, alongside the integration points they cover.

S=.claude/skills/add-ollama-tool
# Container (Bun) tree — the MCP server and the registration wiring test
cp $S/ollama-mcp-stdio.ts       container/agent-runner/src/ollama-mcp-stdio.ts
cp $S/ollama-registration.test.ts container/agent-runner/src/ollama-registration.test.ts
# Host (Node) tree — the env-forwarding helper and the wiring test
cp $S/ollama-env.ts             src/ollama-env.ts
cp $S/ollama-wiring.test.ts     src/ollama-wiring.test.ts

Register the MCP server in the agent-runner

Edit container/agent-runner/src/index.ts. Find the mcpServers object that currently looks like this:

  const mcpServers: Record<string, { command: string; args: string[]; env: Record<string, string> }> = {
    nanoclaw: {
      command: 'bun',
      args: ['run', mcpServerPath],
      env: {},
    },
  };

Add an ollama entry alongside nanoclaw:

  const mcpServers: Record<string, { command: string; args: string[]; env: Record<string, string> }> = {
    nanoclaw: {
      command: 'bun',
      args: ['run', mcpServerPath],
      env: {},
    },
    ollama: {
      command: 'bun',
      args: ['run', path.join(__dirname, 'ollama-mcp-stdio.ts')],
      env: {
        ...(process.env.OLLAMA_HOST ? { OLLAMA_HOST: process.env.OLLAMA_HOST } : {}),
        ...(process.env.OLLAMA_ADMIN_TOOLS ? { OLLAMA_ADMIN_TOOLS: process.env.OLLAMA_ADMIN_TOOLS } : {}),
      },
    },
  };

ollama-registration.test.ts asserts this entry is present and points at the server module — the tool only appears to the agent if it is registered here.

Forward host env vars into the container

The container receives TZ and OneCLI networking vars by default; any other host env var the MCP subprocess needs must be forwarded explicitly. The forwarding logic lives in the copied src/ollama-env.ts (ollamaEnv()) — OLLAMA_HOST (the daemon base URL) and OLLAMA_ADMIN_TOOLS (the library-management opt-in flag). Both are configuration, not credentials (Ollama itself is local and keyless), so they belong on the composed env literal — a credential-NAMED key would need the contributedEnv lane instead (see add-atomic-chat-tool for that shape).

Import it in src/container-runner.ts (alongside the other local imports):

import { ollamaEnv } from './ollama-env.js';

Then, in composeSessionSpec, find the env literal (the TZ line) and spread the helper right after it:

  const env: Record<string, string> = {
    TZ: containerConfig.timezone ?? TIMEZONE,
    ...ollamaEnv(),
  };

ollama-wiring.test.ts asserts this ...ollamaEnv() spread exists inside composeSessionSpec.

Surface [OLLAMA] log lines at info level

Shared block. This rewrites the driver's container-stderr logger, which other local-model tools (e.g. add-atomic-chat-tool for [ATOMIC]) also edit to surface their own prefix. Touch only the [OLLAMA] branch and leave the rest of the block intact, so the edits coexist and removal restores it cleanly.

Container stderr now lands in the Docker driver: in src/drivers/docker-driver.ts, inside DockerHandle.start(), find the stderr handler:

    proc.onStderr((line) => {
      log.debug(line, { container: this.name });
      this.#stderrTail.push(line);
      if (this.#stderrTail.length > 10) this.#stderrTail.shift();
    });

Replace the log.debug line with a prefix branch (leave the stderr-tail lines intact — they feed the non-zero-exit warning):

    proc.onStderr((line) => {
      if (line.includes('[OLLAMA]')) {
        log.info(line, { container: this.name });
      } else {
        log.debug(line, { container: this.name });
      }
      this.#stderrTail.push(line);
      if (this.#stderrTail.length > 10) this.#stderrTail.shift();
    });

If add-atomic-chat-tool (or another local-model tool) has already turned this into a multi-branch block, just add an else if (line.includes('[OLLAMA]')) branch instead of replacing it.

Add env-var stubs to .env.example

Append to .env.example:

# Ollama MCP tool (.claude/skills/add-ollama-tool)
# Override the host where the Ollama daemon listens.
# Default: http://host.docker.internal:11434 (with fallback to localhost)
# OLLAMA_HOST=http://host.docker.internal:11434

# Opt in to library-management tools (pull, delete, show, list-running).
# Leave unset to expose only list + generate.
# OLLAMA_ADMIN_TOOLS=true

Validate code changes

pnpm run build
pnpm exec tsc -p container/agent-runner/tsconfig.json --noEmit
# Host tree: composeSessionSpec wiring
pnpm exec vitest run src/ollama-wiring.test.ts
# Container tree: index.ts registration
(cd container/agent-runner && bun test src/ollama-registration.test.ts)
./container/build.sh

All must be clean before proceeding. The wiring and registration tests confirm the two integration points — the composeSessionSpec spread and the index.ts registration — are actually in place; a failure means one drifted. (The MCP server's own request/response behavior against the Ollama daemon is the author's build-time concern, not part of these tests — verify it manually in Phase 4.)

Phase 3: Configure

Enable library-management tools (optional)

Ask the user:

Would you like the agent to be able to manage Ollama models (pull, delete, inspect, list running)?

• Yes — adds tools to pull new models, delete old ones, show model info, and check what's loaded in memory
• No — the agent can only list installed models and generate responses (you manage models yourself on the host)

If the user wants management tools, add to .env:

OLLAMA_ADMIN_TOOLS=true

If they decline (or don't answer), leave the variable unset — only list + generate are exposed.