search_threadsLABSCO SUMMARY
The scopes it asks for and the operations it implements are listed separately, which is unusually honest.
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. Expect sign-in popups: in stdio mode a client spawns a fresh process per tab, and each one can trigger its own OAuth prompt. The README's persistent HTTP mode is meant to fix that, but its client configuration still launches the binary over stdio, and full HTTP transport is still on its TODO list.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
Build from source
USE CASES
01
Finding the thread you half remember
Search by sender or subject, with draft state included in what comes back.
02
Drafting a reply that sounds like you
The style guide is consulted before the draft is written.
03
Reading an attachment without opening it
Text extracted from a PDF, DOCX or TXT attachment by filename.
04
Keeping the assistant from sending anything
Drafts are the only write path the server implements.
4 tools
Listed in project docs. Your client may show a different list.
create_draftextract_attachment_by_filenameget_personal_email_style_guideBEFORE YOU INSTALL
What to know first
Tools you get
4 tools named in the project's documentation. It searches, reads attachments and writes drafts, but cannot send, delete or change labels, even though the gmail.compose consent includes send permission.
Requires
- Go, to build the binary from the clone
- A Google Cloud OAuth desktop-application client (GMAIL_CLIENT_ID and GMAIL_CLIENT_SECRET) with the Gmail API enabled
- An OpenAI API key (OPENAI_API_KEY)
- All three go in the client configuration's env, or are exported when you run the binary yourself
Where it runs
The documented client runs the server on your machine.
INSTALLATION
Connect your client
You clone and build this one yourself.
Server setup
TERMINAL
git clone https://github.com/PaulFidika/gmail-mcp-server
cd gmail-mcp-server
go build .Add the configuration under MCP Clients to your agent's config file with the built binary's path and your three env values
MCP Clients
Any MCP client
ANY MCP CLIENT · JSON
{
"mcpServers": {
"gmail": {
"command": "<YOUR_PATH_TO_AUTO_GMAIL>",
"env": {
"GMAIL_CLIENT_ID": "<YOUR_CLIENT_ID>.apps.googleusercontent.com",
"GMAIL_CLIENT_SECRET": "<YOUR_GMAIL_CLIENT_SECRET>",
"OPENAI_API_KEY": "<YOUR_OPENAI_API_KEY>"
}
}
}
}<YOUR_PATH_TO_AUTO_GMAIL> is the full path of the binary go build . produced in your clone — auto-gmail (auto-gmail.exe on Windows), named after the module in go.mod.
