The README states plainly that the compose scope grants sending but the server does not implement it, and the same for deletion and labels. That is the kind of thing most projects leave for you to discover. The persistent HTTP mode is worth setting up early: in stdio mode a client spawns a fresh process per tab, and each one triggers its own OAuth popup.
A Gmail server built around drafting rather than sending. It requests read and compose scopes only, and it generates a writing-style guide from your recent sent messages so drafts sound closer to you.
- search_threads searches Gmail with the usual query syntax — from:, subject: — and includes draft information in the results
- create_draft creates a draft or updates an existing one, thread-aware
- extract_attachment_by_filename pulls text out of PDF, DOCX and TXT attachments by filename
- get_personal_email_style_guide returns your writing-style guide, which the agent reads before composing
- A file://personal-email-style-guide resource exposes the same guide for clients that support resources
- A /generate-email-tone prompt rebuilds the style guide from your last 25 sent emails, and /server-status reports file locations and server state
- Sending, deleting and label management are not implemented, even though the compose scope would permit sending
A Google Cloud project with the Gmail API enabled and an OAuth Client ID of the Desktop application type; GMAIL_CLIENT_ID and GMAIL_CLIENT_SECRET go in the environment, along with OPENAI_API_KEY. It is a Go program built with `go build`. The token lands in token.json under an application directory — ~/.auto-gmail on macOS and Linux — and deleting that file forces re-authentication.