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.
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.
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.
Position in the GTM operating system
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.
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.
Chaining recommendations
Anti patterns to avoid
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.
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)
The Gmail ecosystem inside Yalc
MCPs to consider instead
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