#1137·gogcli

feat(mcp): add typed, capability-scoped Gmail write and mutation tools

Author: alex-strattabCreated Sep 16, 2026Updated Sep 16, 2026
Labelsissue-rating: 🌊 off-meta tidepoolclawsweeper:no-new-fix-prclawsweeper:needs-product-decisionP2impact:securityclawsweeper:needs-security-review

Summary

Please add typed Gmail write tools to gog mcp for compose/send, draft lifecycle, labels/read state, archive, trash, and other ordinary mailbox mutations supported by the existing gog gmail CLI. Keep them hidden behind the existing explicit write/send gates and per-account capability policy.

This is not a request for a generic command runner or model-supplied argv.

Current behavior

Tested with gog v0.38.2:

bash
gog mcp --allow-write --allow-tool gmail --list-tools

The registered Gmail surface remains read-only:

  • gmail_search
  • gmail_get_message
  • gmail_get_thread

No typed Gmail write tools are registered even when the authenticated profile has gmail.modify, gmail.compose, and gmail.send grants and write exposure is explicitly requested. Live read-only probes succeed; this is not an OAuth failure.

The current MCP documentation likewise lists Gmail reads and only Docs/Sheets writes: https://github.com/openclaw/gogcli/blob/main/docs/mcp.md

Requested behavior

Expose a curated set of typed, auditable Gmail mutation tools that:

  1. map one tool to one reviewed gog Gmail operation;
  2. use fixed schemas with unknown-field rejection;
  3. remain absent by default;
  4. require the existing explicit write/send authorization and command safety gates;
  5. respect the per-account capability policy added by #914, so one account can remain read-only while another receives a narrowly selected write surface;
  6. preserve --wrap-untrusted, --no-input, dry-run behavior where supported, bounded output, and the existing subprocess safety model.

Useful initial operations would be compose/create draft, send draft/message, add/remove labels, mark read/unread, archive, trash, restore, and delete only if the existing baked safety policy permits it. Tool naming and exact initial scope should follow the maintainers' existing registry conventions.

Why

A trusted-side MCP integration needs ordinary mailbox control without exposing reusable OAuth material to an agent sandbox and without introducing a custom wrapper or generic shell bridge. gog mcp already provides the correct typed-tool, untrusted-content, account-policy, and safety architecture; the missing piece is a curated Gmail mutation surface.

Duplicate check

I searched the open and closed issue set for Gmail MCP write/send/mutation requests. #913/#914 adds persistent capability policy but explicitly adds no tools. I did not find an existing request for the Gmail mutation tool surface described here.