Content · MCP server

Gmail MCP and the Yalc Framework

The personal inbox layer for Yalc workflows. Read replies, draft responses, and search your sent folder for context, all from Claude Code without the Gmail UI.

Try Gmail →
Yalc Fit Score
8/10
Auth
Google OAuth
Maintainer
Community + ModelContextProtocol
Tools
Read + send + search
Last reviewed
2026-04-29
Install

Add Gmail to Claude Code in one command

claude mcp add gmail --env GOOGLE_CLIENT_ID=xxx --env GOOGLE_CLIENT_SECRET=xxx --env GOOGLE_REFRESH_TOKEN=xxx -- npx -y @gongrzhe/server-gmail-autoauth-mcp

Multiple Gmail MCP packages exist. The community `@gongrzhe/server-gmail-autoauth-mcp` handles OAuth automatically on first run. Alternatively, use Composio's Gmail toolkit which abstracts the OAuth dance behind a single Composio API key. Both work; pick the one your team already standardizes on.

What it does

Gmail, plainly

The Gmail MCP exposes the Gmail API (read messages, send messages, search threads, manage labels) as native Claude tool calls. Auth is Google OAuth, which means a one-time browser-based authorization the first time you run the MCP. After that, the refresh token persists.

For Yalc operators, Gmail is the personal inbox layer. Where Instantly handles outbound campaign sends, Gmail handles individual one-off sends and the human-managed inbox. The MCP lets Yalc draft personal replies, search past conversations for context, and pull warm threads into structured workflows.

Where it slots in

Position in the GTM operating system

Intake
→
Enrich
→
Score
→
Route
→
Draft
→
Send
→
Listen

The Gmail MCP sits at the **send** node for personal one-off sends and at the **listen** node for the personal inbox. It pairs with Instantly (campaign sends) and Unipile (LinkedIn) to complete the messaging surface.

Yalc workflows that benefit most: triage the founder's inbox each morning, draft replies to warm intros, search past conversations for relevant context before a follow up, and pull commit-confirmed deals into the CRM.

The Yalc Framework

Deploying the Gmail MCP inside Yalc workflows

Workflow position

The personal inbox node. Yalc reads sent and received messages for context, drafts replies, and sends individual emails. Not the right tool for cold email at scale (use Instantly).

Prompt patterns

Copy paste prompts for Claude Code that invoke the Gmail MCP.

Yalc, summarize my last 7 days of unread emails, group by sender importance and topic. Suggest top 3 to reply to today. → Yalc reads inbox via Gmail MCP, classifies via Claude, returns prioritized triage.
Yalc, search my sent folder for any reply to this prospect in the last 90 days. Surface the thread context before I draft a follow up. → Yalc searches Gmail via the MCP, returns relevant threads for context.
Yalc, draft a reply to this email in [my voice]. Include 2 specific references to our prior thread. Save as draft, do not send. → Yalc reads the thread, drafts via Claude, creates a Gmail draft.

Chaining recommendations

UpstreamYalc workflow → Claude draft → Gmail MCP (save as draft or send)
DownstreamGmail reply → Yalc workflow trigger (via webhook handler)

Anti patterns to avoid

Don't auto-send without human review on personal Gmail. Account reputation is irreplaceable. Yalc workflows always create drafts, never auto send to your personal inbox.
Don't use Gmail MCP for cold email campaigns. Gmail's TOS and rate limits make it unsuitable for outbound at scale. Use Instantly with dedicated sending domains.
Don't grant the broadest OAuth scope. Use the minimum scopes needed (gmail.readonly, gmail.send, gmail.compose). Avoid full mailbox modify unless you genuinely need it.

Compatibility

Multiple community MCP packages support Gmail. Most work with Claude Code, Claude Desktop, and Cursor. Composio's Gmail toolkit also exposes Gmail via their unified MCP URL pattern. All approaches use Google OAuth.

Operator take

Pros, cons, who it's for

Pros

  • One MCP covers read, send, search, and label management.
  • Google OAuth refresh tokens persist after first auth.
  • Free to use (Gmail's API quotas are generous for personal use).
  • Well documented because Gmail's API is mature.
  • Multiple maintainers means the ecosystem doesn't depend on one vendor.

Cons

  • Multiple competing packages. You have to pick one and stick with it.
  • OAuth setup requires creating a Google Cloud project and configuring an OAuth consent screen. Real friction on first install.
  • Personal Gmail accounts have stricter TOS than Workspace. Cold email is a fast way to get suspended.
  • The MCP doesn't subscribe to push notifications natively. For real time inbox events, set up Gmail Push via Pub/Sub separately.

Who it's for

  • Founders who run their inbox triage from Claude Code
  • GTM operators who need to pull email context into Yalc workflows
  • Anyone who treats Gmail as the warm-thread layer (not the cold-send layer)
Related

The Gmail ecosystem inside Yalc

Gmail (planned vendor review)
Workspace plan context.
→
Instantly (planned MCP)
Switch when the workflow is cold email at scale, not personal inbox management.
→
Alternatives

MCPs to consider instead

Outlook MCP
Switch when your team runs on Microsoft 365 instead of Google Workspace.
→
Composio Gmail toolkit
Switch when you already have a Composio account and want unified credential management.
→
Direct Gmail REST API
Skip the MCP for headless cron jobs. Direct API calls are cleaner outside of Claude conversations.
→
FAQ

Frequently asked

Which Gmail MCP package should I install?

For solo operators, `@gongrzhe/server-gmail-autoauth-mcp` is the most common community choice because it handles OAuth automatically. For teams already on Composio, use Composio's Gmail toolkit. Both expose roughly the same surface.

Can I use this MCP with a Google Workspace account?

Yes. Workspace accounts work the same way as personal Gmail. Some Workspace admin policies may require admin approval for the OAuth consent screen.

How do I scope the OAuth permissions?

When you create the OAuth client, request only the scopes you need. For most Yalc workflows, gmail.readonly + gmail.send + gmail.compose covers the surface. Avoid gmail.modify unless you need to delete or label messages.

Will Yalc workflows hit Gmail's API quotas?

Gmail's API quotas (1 billion units per day) are generous. Typical Yalc volume (a few hundred reads and sends per day) is nowhere close. Watch the per-user-per-second limit if you batch a large search.

Can I trigger workflows from inbox events?

Not via the MCP directly. Set up Gmail's Push API via Google Pub/Sub, route the push to a webhook handler, invoke Yalc from there.

Does the MCP draft or auto-send?

Both. Yalc workflows on personal inboxes should always create drafts and never auto send. The MCP supports both modes; the discipline is enforced in your prompt patterns.

Install the Gmail MCP

Drop it into Claude Code and orchestrate from your next Yalc prompt.

claude mcp add gmail --env GOOGLE_CLIENT_ID=xxx --env GOOGLE_CLIENT_SECRET=xxx --env GOOGLE_REFRESH_TOKEN=xxx -- npx -y @gongrzhe/server-gmail-autoauth-mcp
View on GitHub We deploy it for you
Last reviewed 2026-04-29 by Othmane Khadri