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

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:

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.

Start with the existing gog mcp tool registry and docs/mcp.md, then compare the Gmail read tools with the operations exposed by the gog gmail CLI. Read the per-account capability policy from #914 and the existing write/send safety gates. Done means a maintainer-approved, typed Gmail mutation surface follows those policies, remains absent by default, and preserves the stated safety behavior.