add-gmail-tool
Add Gmail as an MCP tool (read, search, send, label, draft) using OneCLI-managed OAuth. The agent gets Gmail tools in every enabled group; OneCLI injects real tokens at request time so no raw credentials are ever in the container or on disk in usable form.
Profile →npx skills add nanocoai/nanoclaw --skill add-gmail-tool --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Add Gmail Tool (OneCLI-native) This skill wires the [`@gongrzhe/server-gmail-autoauth-mcp`](https://www.npmjs.com/package/@gongrzhe/server-gmail-autoauth-mcp) stdio MCP server into selected agent groups. The MCP server reads stub credentials containing the `onecli-managed` placeholder; the OneCLI gateway intercepts outbound calls to `gmail.googleapis.com` and injects the real OAuth bearer from its vault. Tools exposed (from `gmail-mcp@1.1.11`, surfaced to the agent as `mcp__gmail__<name>`): `search_emails`, `read_email`, `send_email`, `draft_email`, `delete_email`, `modify_email`, `batch_modify_emails`, `batch_delete_emails`, `download_attachment`, `list_email_labels`, `create_label`, `update_label`, `delete_label`, `get_or_create_label`, `list_filters`, `get_filter`, `create_filter`, `create_filter_from_template`, `delete_filter`. **Why this pattern:** v2's invariant is that containers never receive raw API keys — OneCLI is the sole credential path (see CHANGELOG v2.0.0). The stub-file pattern satisfies this: the container sees `"onecli-managed"` placeholders, the gateway swaps them in flight. ## Phase 1: Pre-flight ### Verify OneCLI has Gmail connected ```bash onecli apps get -
- Phase 1: Pre-flight
- Verify OneCLI has Gmail connected
- Verify stub credentials exist
- Verify mount allowlist covers the path
- Check agent secret-mode
- Phase 2: Apply Code Changes
- Check if already applied
- Copy the skill's tests into the container tree
- Add MCP server to Dockerfile
- Rebuild the container image
- Phase 3: Wire Per-Agent-Group
- List groups, pick which ones get Gmail
- Register the MCP server
- Add the .gmail-mcp mount
onecli apps get --provider gmail ls -la ~/.gmail-mcp/gcp-oauth.keys.json ~/.gmail-mcp/credentials.json 2>&1 grep -l onecli-managed ~/.gmail-mcp/gcp-oauth.keys.json ~/.gmail-mcp/credentials.json mkdir -p ~/.gmail-mcp cat > ~/.gmail-mcp/gcp-oauth.keys.json <<'EOF' cat > ~/.gmail-mcp/credentials.json <<'EOF' chmod 600 ~/.gmail-mcp/gcp-oauth.keys.json ~/.gmail-mcp/credentials.json cat ~/.config/nanoclaw/mount-allowlist.json onecli agents list onecli agents set-secrets --id <agent-id> --secret-ids "$MERGED"
What does the add-gmail-tool skill do?
Add Gmail as an MCP tool (read, search, send, label, draft) using OneCLI-managed OAuth. The agent gets Gmail tools in every enabled group; OneCLI injects real tokens at request time so no raw credentials are ever in the container or on disk in usable form.
How do I install it?
Run `npx skills add nanocoai/nanoclaw --skill add-gmail-tool --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From nanocoai/nanoclaw, a repository with 30,426 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.