> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nanoclaw.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Give agents tools

> Two ways to add MCP tools to NanoClaw agents — install a tool skill like /add-gmail-tool, or register any MCP server yourself via the container config.

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](/extend/overview) that wires an MCP server into the agent groups you choose, with credentials handled by the [OneCLI Agent Vault](/operate/credentials) where the service needs them.
2. **Bring your own MCP server** — register any stdio MCP server in a group's [container config](/reference/container-config#mcp_servers) with one `ncl` command. No skill required.

Two things are already there before you add anything: the built-in `nanoclaw` MCP server (messaging, sub-agents, self-modification — see [Agent MCP tools](/reference/mcp-tools)), and web access via the `agent-browser` container skill (below).

<Note>
  **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.
</Note>

## Gmail

`/add-gmail-tool` wires the [`@gongrzhe/server-gmail-autoauth-mcp`](https://github.com/GongRzhe/Gmail-MCP-Server) stdio server into the groups you pick. The agent sees the tools as `mcp__gmail__<name>` (from `gmail-mcp@1.1.11`):

| Area            | Tools                                                                                         |
| --------------- | --------------------------------------------------------------------------------------------- |
| Search & read   | `search_emails`, `read_email`, `download_attachment`                                          |
| Send & draft    | `send_email`, `draft_email`                                                                   |
| Modify & delete | `modify_email`, `delete_email`, `batch_modify_emails`, `batch_delete_emails`                  |
| Labels          | `list_email_labels`, `create_label`, `update_label`, `delete_label`, `get_or_create_label`    |
| Filters         | `list_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](/operate/credentials#accessing-the-onecli-dashboard); 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](/operate/credentials#credential-stubs).

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`](https://github.com/cocal-com/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 the agent offload work to local models. In both cases **the agent stays the orchestrator** — it decides when to delegate, calls the local model as a tool, and uses the result.

| Skill                   | What it adds                                                                                                                                                                                                                                              |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/add-ollama-tool`      | `ollama_list_models` and `ollama_generate` against the host's [Ollama](https://ollama.com) 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-tool` | `atomic_chat_list_models` and `atomic_chat_generate` against the [Atomic Chat](https://github.com/AtomicBot-ai/Atomic-Chat) desktop app's OpenAI-compatible API on port 1337.                                                                             |

<Note>
  Don't confuse `/add-ollama-tool` with `/add-ollama-provider`. The tool skill keeps your existing provider 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](/extend/providers).
</Note>

## 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](/reference/container-config#skills).

## 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:

```bash theme={null}
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](/reference/container-config#mcp_servers).

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](/operate/credentials).

## Next steps

<CardGroup cols={2}>
  <Card title="Skills catalog" icon="list" href="/reference/skills-catalog#tool-installs">
    All ten tool-install skills, including dashboard, memory, and Vercel
  </Card>

  <Card title="Agent MCP tools" icon="screwdriver-wrench" href="/reference/mcp-tools">
    The built-in nanoclaw server every agent already has
  </Card>

  <Card title="Credentials" icon="key" href="/operate/credentials">
    How the vault keeps raw tokens out of containers
  </Card>

  <Card title="Container config" icon="box" href="/reference/container-config">
    The full mcp\_servers, skills, and mounts reference
  </Card>
</CardGroup>
