Before MCP: "Write a script that reads my Gmail." Claude writes a Python script. I run it. I read the output. I come back. "Now filter for just the important ones." Claude modifies the script. I run it again.
After MCP: "Read my Gmail and show me the important ones." Done. No script. No running. No output parsing. The feedback loop tightens from minutes to seconds.
That's the shift. Claude stops being a code generator and starts being an agent that acts in the world.
The Never-Send Rule
This was an explicit architectural decision from day one:
# Gmail MCP tools:
# ✅ list_emails
# ✅ get_email
# ✅ create_draft
# ✅ apply_label
# ❌ send_email ← This tool does not exist
Not disabled. Not behind a confirmation. Doesn't exist. Claude can read every email, classify them, draft perfect replies, and put them in your Drafts folder. You review. You click Send.
Every time I thought "wouldn't it be nice if it could just send the reply," I remembered: email is permanent, context is lossy, and Claude occasionally hallucinates. Drafts are cheap. Sending the wrong thing to the wrong person is not.
This is a design pattern, not a Gmail decision. When building AI tools that interact with the real world, don't disable the dangerous capability. Don't put it behind a confirmation dialog that everyone clicks through. Omit it entirely. Make the safe path the only path.
I use this pattern across every MCP server I build. The Sheets MCP: read-only. The Calendar MCP: can read events and create drafts, can't delete or modify. The principle is always the same: give AI read access to everything and write access to nothing permanent. The human reviews the draft, the proposed change, the classified email. The human clicks Send, Confirm, Delete. That boundary never moves.
Every time I was tempted to remove the boundary, thinking "it would be so much faster if Claude could just send the reply," I imagined explaining to someone why an AI sent them a hallucinated email. That imagination exercise has a 100% success rate at preserving the boundary.
What I Built On Top
37 tools across five Google Workspace APIs: Gmail, Sheets, Calendar, Slides, Forms.
The email system built on top is called Letter Rip. It classifies email into four categories (FYI, Respond, Draft, Archive) using a hybrid approach: explicit rules handle the obvious stuff (GitHub notifications → FYI, noreply@ addresses → Archive) and Claude handles the ambiguous 20% that needs actual judgment.
The clever part: it learns from corrections. Reclassify an email manually and the system records the pattern. After enough corrections for a sender or pattern, it promotes the correction to an explicit rule. Claude handles the long tail; rules handle the head. Over time, the rules grow and Claude has less work to do.
The Paradigm Shift
Before MCP (batch): Write code → Run it → Read output → Come back → Iterate After MCP (interactive): Ask → Receive → Decide → Act
The difference isn't speed. It's the interaction model. You're not telling Claude what code to write. You're telling it what you want done. "Triage my inbox" is three words and a minute of execution. The same task as a Python script is an afternoon of OAuth debugging and Gmail API pagination.
The Takeaway
MCP turns Claude from "writes code" to "does things." The architectural insight: separate the tools (stable MCP infrastructure) from the products (fast-iterating applications on top). And always, always, keep the human in the loop at the points that matter.
Claude can read every email in my inbox. It can draft replies to all of them. It cannot send a single one. That's not a limitation. That's the design.