Gmail MCP

Gmail MCP

English | Русский

A1 Gmail MCP lets an AI app work with your Gmail mailbox in plain language. Search and read mail, prepare replies as drafts, send them when you are ready, keep labels tidy and use the trash instead of permanent deletion.

It uses the Gmail API with your Google account. It distinguishes a draft you can still edit from a sent email that cannot be recalled, and makes the limits of the Gmail API explicit instead of implying that every mail task is reversible.

• 24 tools. Search and read messages and threads, send email directly or through drafts, manage the draft lifecycle, labels and the trash.
• Connects from the conversation. Say "connect Gmail": the server walks you through the OAuth client, catches Google's redirect on 127.0.0.1 with PKCE and keeps the tokens itself — no config files, no restart.
• Send deliberately. The draft → review → send path is first-class; sending is marked destructive, and the server never re-sends after an ambiguous failure — an email cannot be unsent.
• The trash is the safety net. Removing mail goes through the reversible trash (about 30 days); there is deliberately no permanent message delete tool.
• Bounded reading. Decoded bodies are truncated at an explicit limit and attachments come back as metadata, so a long newsletter cannot silently flood the conversation.
• Minimal Google scope. It uses gmail.modify only — no permanent deletion and no access to Gmail settings.

Start with a read-only question:

Show my unread emails from the last week and tell me which ones need a reply.

Connect the server · Explore use cases · Open technical documentation

See it work in a minute

You: What is unread in my inbox from this week about the Acme contract?

Assistant: Searches with Gmail query syntax and shows senders, subjects, dates and snippets. Nothing changes.

You: Draft a reply to the latest one: we send the signed copy on Friday.

Assistant: Creates a draft in the same thread and shows it for review. Nothing is sent.

You: Send it.

Assistant: Sends the draft. Sending is a separate, explicitly destructive step, so your AI app can ask for confirmation first.

Contents

• Quick start
• What you can ask it to do
• How mail changes
• What can change
• Getting access
• Configuration
• Data, limits and background work
• Technical documentation
• Support

Quick start

You need Node.js 20+ and a Google account. Credentials are not required at install time — the server connects from the conversation.

1. Add the server to your AI app.
2. Say "connect Gmail": the assistant walks you through creating the OAuth client and approving access without editing config files.
3. Ask the read-only question above.

In the app: open Settings → MCP servers, select Add server, choose STDIO, enter the command npx -y mcp-google-gmail@latest and environment variables GOOGLE_GMAIL_CLIENT_ID, GOOGLE_GMAIL_CLIENT_SECRET, GOOGLE_GMAIL_REFRESH_TOKEN, then select Save and Restart.

From the command line:

codex mcp add google-gmail \
  -- npx -y mcp-google-gmail@latest

codex mcp list

Codex MCP documentation

claude mcp add \
  --transport stdio --scope user google-gmail \
  -- npx -y mcp-google-gmail@latest

claude mcp list

Claude Code MCP documentation

The current official path is Settings → Extensions. For a custom desktop extension, open Advanced settings → Extension Developer → Install Extension…, select a .mcpb file and follow the prompts.

This repository currently publishes an npm stdio package and does not contain a .mcpb bundle. For Claude Desktop builds that still support local configuration, use the following JSON stdio configuration as a fallback:

{
  "mcpServers": {
    "google-gmail": {
      "command": "npx",
      "args": ["-y", "mcp-google-gmail@latest"]
    }
  }
}

In those builds, save it to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows.

Claude Desktop MCP documentation

Add this to ~/.cursor/mcp.json on macOS/Linux or %USERPROFILE%\.cursor\mcp.json on Windows:

{
  "mcpServers": {
    "google-gmail": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-google-gmail@latest"]
    }
  }
}

Cursor MCP documentation

Run MCP: Open User Configuration and add:

{
  "servers": {
    "google-gmail": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-google-gmail@latest"]
    }
  }
}

Check it with MCP: List Servers.

VS Code MCP documentation

What you can ask it to do

Triage the inbox

• Show unread messages from the last seven days and group them by sender.
• Find the conversation with Acme about the contract and summarize it, oldest to newest.
• Which messages have attachments waiting for me? Show subjects and file names.

Write and send email

• Draft a reply in this thread saying the signed copy goes out on Friday.
• Show me the draft, tighten the wording, then send it.
• Send a short status email to the team, with the manager in CC.

Keep the mailbox organized

• Create a label Receipts/2026 and apply it to the matching messages.
• Mark this week's newsletters as read and archive them.
• Move that thread to the trash — and restore it if I change my mind.

How mail changes

1. The safe path to sending is a draft: create_draft prepares the email, get_draft shows it for review, send_draft sends it. send_message skips the draft and sends immediately.
2. A sent email is externally irreversible. After a timeout or a 5xx error the server does not re-send; search in:sent before trying again, because a replayed send would be a double-sent email.
3. Removing a message or thread means trashing it. manage_trash is reversible for about 30 days; there is deliberately no permanent-delete tool.
4. Drafts are the exception: update_draft replaces the whole draft (the API has no partial edit) and delete_draft is permanent, because drafts skip the trash.

Every call works on one mailbox — the account that granted the token. Decoded bodies are truncated at a configurable limit with explicit flags, and attachments come back as metadata only; attachment content is fetched through raw_request deliberately.

What can change

The AI client controls confirmation prompts. The server marks reads, writes and destructive tools so the client can distinguish an inspection from a live change.

Getting access

Google Gmail requires OAuth 2.0; an API key is not enough. There are two ways in, and the first one needs no configuration files.

Connect from the chat (recommended)

Say "connect Gmail" and the assistant runs the flow with you:

1. setup_instructions prints the checklist: create or select a Google Cloud project, enable Gmail API, configure the consent screen and create a Desktop app OAuth client.
2. Download that client's JSON ("Download JSON") and give the assistant its path — set_client stores it owner-only. The secret never goes through the conversation.
3. start_login returns a Google consent link. Open it on this machine and approve; the code comes back to a one-shot listener on 127.0.0.1 (PKCE), never through the chat.
4. finish_login exchanges the code and saves the tokens to ~/.config/mcp-google-gmail/credentials.json (mode 0600) and verifies them with a real Gmail API call — so an API that is still switched off is caught right there.

The tokens are re-read on every call, so the connection works immediately — no restart of the AI app. auth_status shows what is connected, logout revokes and deletes it.

Environment variables (CI, unattended installs)

1. Create or select a Google Cloud project and enable the Gmail API.

2. Configure the OAuth consent screen and create a Desktop app OAuth client.

3. Authorize the Google account whose mailbox you want to connect — every call works on that one mailbox. The OAuth 2.0 Playground can obtain the refresh token when Use your own OAuth credentials is enabled.

4. Request the scope:

   https://www.googleapis.com/auth/gmail.modify
   

   It covers search, reading, sending, drafts, labels and the trash — but not permanent deletion and not Gmail settings. Permanent deletion through raw_request additionally requires the full https://mail.google.com/ scope.

Testing-mode OAuth refresh tokens can expire after seven days. Publish the OAuth app, or use an Internal app in a Workspace domain, when you need long-lived access. Treat the client secret and refresh token as passwords.

Configuration

Every variable is optional — with none of them the server connects from the chat.

* Provide either the OAuth trio or an access token.

Data, limits and background work

• Requests go to Gmail. The local server refreshes Google OAuth tokens and calls the Gmail API. Its anonymous telemetry contains an installation ID, package version, AI client and platform versions, and tool names — never OAuth tokens, mail content, tool arguments or prompts. Set ASKADS_TELEMETRY=0 to opt out.
• Google meters quota units. Gmail allows roughly 250 quota units per second per user; a send costs 100 units, a typical read 5. Consumer accounts can send about 500 emails a day, Workspace accounts about 2,000. On 429, the server uses backoff; reads also retry after network and 5xx errors, while sends and other writes are never replayed after an uncertain failure.
• There is no background polling. The server runs only when called. If your AI app supports scheduled tasks, it can check the inbox periodically; raw_request can also reach history.list for incremental sync.

Technical documentation

• MCP capability catalog — task-oriented pages for every tool.
• All tools and inputs
• Development documentation
• Publishing documentation
• Gmail API reference

Support

Found a bug or need a scenario? Create an issue or write in Telegram.