Skip to main content
Agents get tools two ways:
  1. Install a tool skill — /add-gmail-tool, /add-gcal-tool, /add-ollama-tool, and friends. Each is a SKILL.md workflow that wires an MCP server into the agent groups you choose, with credentials handled by the OneCLI Agent Vault where the service needs them.
  2. Bring your own MCP server — register any stdio MCP server in a group’s container config with one ncl command. No skill required.
Two things are already there before you add anything: the built-in nanoclaw MCP server (messaging, scheduling, sub-agents — see Agent MCP tools), and web access via the agent-browser container skill (below).
Landed here looking for the Gmail channel? Gmail was a channel in v1 — it polled your inbox and triggered the agent on new emails. In v2 it’s an MCP tool: /add-gmail-tool gives the agent the ability to read, search, and send email, but inbound email does not trigger the agent. An inbound Gmail channel hasn’t been ported to v2’s channel architecture.

​
Gmail

/add-gmail-tool wires the @gongrzhe/server-gmail-autoauth-mcp stdio server into the groups you pick. The agent sees the tools as mcp__gmail__<name> (from gmail-mcp@1.1.11):
AreaTools
Search & readsearch_emails, read_email, download_attachment
Send & draftsend_email, draft_email
Modify & deletemodify_email, delete_email, batch_modify_emails, batch_delete_emails
Labelslist_email_labels, create_label, update_label, delete_label, get_or_create_label
Filterslist_filters, get_filter, create_filter, create_filter_from_template, delete_filter
OAuth follows v2’s credential invariant — containers never hold raw tokens. You connect Gmail once in the OneCLI web UI; the skill writes stub files (~/.gmail-mcp/) whose values are the "onecli-managed" placeholder. The MCP server starts happily against the stubs, and the vault’s gateway rewrites Authorization: Bearer onecli-managed to the real OAuth token in flight to gmail.googleapis.com. Full mechanics in Credentials. The skill installs the MCP server into the container image, registers it per group with ncl groups config add-mcp-server, and mounts the stub directory. To test: ask the agent to “list my gmail labels” — the first call takes a moment while the server starts and the vault does the token exchange.

​
Google Calendar

/add-gcal-tool is a direct sibling of the Gmail skill — same stub-credential pattern, separate install and removal. It wires @cocal/google-calendar-mcp (chosen for multi-calendar and multi-account support), surfaced as mcp__calendar__<name>: list/search/create/update/delete events, list calendars, free/busy queries, and current time.

​
Local models as tools

Two skills let Claude offload work to local models. In both cases Claude stays the orchestrator — it decides when to delegate, calls the local model as a tool, and uses the result.
SkillWhat it adds
/add-ollama-toolollama_list_models and ollama_generate against the host’s Ollama daemon. Set OLLAMA_ADMIN_TOOLS=true to also expose model management (pull, delete, show, list_running). Keyless — the only config is the daemon URL.
/add-atomic-chat-toolatomic_chat_list_models and atomic_chat_generate against the Atomic Chat desktop app’s OpenAI-compatible API on port 1337.
Don’t confuse /add-ollama-tool with /add-ollama-provider. The tool skill keeps Claude as the agent’s brain and gives it a local model to call; the provider skill replaces the agent’s brain with a local Ollama model for an entire group. See Providers.

​
Web access

Every agent can already browse the web. The agent-browser container skill ships in container/skills/, which is mounted read-only into every container — and the container config’s skills field defaults to "all", so it’s available without any setup. It teaches the agent the agent-browser CLI: navigate to URLs, snapshot pages as accessibility trees with element refs, click and fill forms, extract text and attributes, take screenshots, save PDFs, run JavaScript, and persist login state across sessions. The agent uses it on its own whenever a browser helps — research, reading articles, interacting with web apps — not just when you ask explicitly. Which container skills a group gets is controlled per group — see Container config.

​
Bring your own MCP server

Any stdio MCP server can be added to a group without a skill. Register it in the group’s container config: 
ncl groups config add-mcp-server \
  --id <group-id> \
  --name github \
  --command npx \
  --args '["-y", "@modelcontextprotocol/server-github"]' \
  --env '{}'
--args and --env are optional JSON. The server is merged with the built-in nanoclaw server at runner startup, and the agent’s allow-pattern (mcp__github__*) is derived automatically from the server name. The change lands in the central database and takes effect on the group’s next container spawn — restart the group (ncl groups restart --id <group-id>) to pick it up immediately. Run from inside an agent’s container, ncl write commands are approval-gated; from a host operator shell they execute immediately. Remove with ncl groups config remove-mcp-server --id <group-id> --name github. The optional instructions field (composed into the group’s CLAUDE.md) can’t be set through ncl as of v2.1.4 — see Container config. If your server needs a credential, don’t put a raw key in --env — connect the service in the OneCLI vault and let the gateway inject it, or use the stub pattern the Gmail skill demonstrates. See Credentials.

​
Next steps

Skills catalog

All ten tool-install skills, including dashboard, memory, and Vercel

Agent MCP tools

The built-in nanoclaw server every agent already has

Credentials

How the vault keeps raw tokens out of containers

Container config

The full mcp_servers, skills, and mounts reference
Last modified on June 10, 2026