add-atomic-chat-tool skill

Add Atomic Chat Integration

This skill adds a stdio-based MCP server that exposes models running in the local Atomic Chat desktop app as tools for the container agent. Claude remains the orchestrator but can offload work to local models served by Atomic Chat on http://127.0.0.1:1337/v1 (OpenAI-compatible).

Tools exposed:

• atomicchatlist_models — list models currently available in Atomic Chat (GET /v1/models)
• atomicchatgenerate — send a prompt to a specified model and return the response (POST /v1/chat/completions)

Model management (download, delete) is done through the Atomic Chat desktop UI — the app is a fork of Jan and manages its own model library.

The skill ships the MCP server source (and its test) 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 (mcpatomicchat__*) is derived from the registered server name.

Phase 1: Pre-flight

Check if already applied

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

Check prerequisites

Verify Atomic Chat is installed and its local API server is running. On the host:

curl -s http://127.0.0.1:1337/v1/models | head

If the request fails:

1. Install Atomic Chat from the latest release (macOS only for now — atomic-chat.dmg).
2. Open the app.
3. Open Settings → Local API Server and make sure it's enabled on port 1337.
4. Go to the Hub (or Models) tab and download at least one model (e.g. Llama 3.2 3B, Qwen 2.5 Coder 7B).
5. Load the model once by sending any message in Atomic Chat's UI to warm it up.

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-atomic-chat-tool
# Container (Bun) tree — the MCP server and the registration wiring test
cp $S/atomic-chat-mcp-stdio.ts        container/agent-runner/src/atomic-chat-mcp-stdio.ts
cp $S/atomic-chat-registration.test.ts container/agent-runner/src/atomic-chat-registration.test.ts
# Host (Node) tree — the env-forwarding helper and the wiring test
cp $S/atomic-chat-env.ts              src/atomic-chat-env.ts
cp $S/atomic-chat-wiring.test.ts      src/atomic-chat-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 atomic_chat entry alongside nanoclaw:

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

atomic-chat-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 env-forwarding logic lives in the copied src/atomic-chat-env.ts (atomicChatEnv()), so the reach-in into composeSessionSpec is a single spread.

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

import { atomicChatEnv } from './atomic-chat-env.js';

Then, in composeSessionSpec, find the contributedEnv literal and spread the helper at the end. The contributed lane — not the composed env literal — because ATOMICCHATAPI_KEY is credential-NAMED and the composed lane's key-name check would refuse the spawn; the contributed lane exempts the name and still refuses credential-shaped values:

const contributedEnv: Record<string, string> = {
    ...(contribution.env ?? {}),
    ...(gateway.env ?? {}),
    ...atomicChatEnv(),
  };

atomic-chat-wiring.test.ts asserts this ...atomicChatEnv() spread exists inside composeSessionSpec.

Surface [ATOMIC] log lines at info level

Shared block. This rewrites the driver's container-stderr logger, which other local-model tools (e.g. add-ollama-tool for [OLLAMA]) also edit to surface their own prefix. Touch only the [ATOMIC] 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('[ATOMIC]')) {
        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();
    });

Add env-var stubs to .env.example

Append to .env.example:

# Atomic Chat MCP tool (.claude/skills/add-atomic-chat-tool)
# Override the host where Atomic Chat exposes its OpenAI-compatible API.
# Default: http://host.docker.internal:1337 (with fallback to localhost)
# ATOMIC_CHAT_HOST=http://host.docker.internal:1337

# Optional API key. Leave unset for a local Atomic Chat install — it does not require auth.
# ATOMIC_CHAT_API_KEY=

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/atomic-chat-wiring.test.ts
# Container tree: index.ts registration
(cd container/agent-runner && bun test src/atomic-chat-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 Atomic Chat is the author's build-time concern, not part of these tests — verify it manually in Phase 4.)

Phase 3: Configure

Set Atomic Chat host (optional)

By default, the MCP server connects to http://host.docker.internal:1337 (Docker Desktop) with a fallback to localhost. To use a custom host, add to .env:

ATOMIC_CHAT_HOST=http://your-atomic-chat-host:1337

Set API key (optional)

Atomic Chat does not require authentication when running locally — leave this unset. Only set it if you've put Atomic Chat behind a reverse proxy that enforces auth:

ATOMIC_CHAT_API_KEY=sk-...

Restart the service

Run from your NanoClaw project root:

source setup/lib/install-slug.sh
launchctl kickstart -k gui/$(id -u)/$(launchd_label)  # macOS
# Linux: systemctl --user restart $(systemd_unit)

Phase 4: Verify

Test inference

Tell the user:

Send a message like: "use atomic chat to tell me the capital of France"

The agent should use atomicchatlistmodels to find available models, then atomicchat_generate to get a response.

Check logs if needed

tail -f logs/nanoclaw.log | grep -i atomic