Wire Gmail drafts through Google's official MCP

Why this matters

The single biggest failure mode in agent email workflows is “the agent sent a thing it shouldn’t have.” A misclassified lead, a confidential paragraph quoted into a reply, a follow-up to the wrong customer because the agent confused two threads. Once the email is in the recipient’s inbox, the recovery options are an apology and a careful conversation. The structural answer is to wire the agent so it cannot send.

Google’s official Gmail MCP is the cleanest path for this. It exposes a draft tool (the agent calls it; the draft lands in the user’s Gmail Drafts folder) and the user opens Gmail and clicks send. The Drafts folder IS the review gate; no Auxot-side human-step is needed on top of it, because the structural gap between “agent finished” and “email goes out” is wide and obvious.

This is different from wrapping Gmail in a send tool and then adding a tool policy to block sends. The official Gmail MCP supports draft creation as a first-class operation; the agent’s flow is “draft, stop, hand to human,” not “send tool exists but is blocked.” The wiring matches the discipline.

Nothing leaves your sent folder: you read the draft, you click send.

Quick start

1. Connect the official Gmail MCP (Add an MCP server). Search for “Gmail” in the connector catalog; pick the entry labeled Google official. Walk through the OAuth flow using the team’s Workspace account, not a personal Gmail.
2. Review the OAuth scopes. The official MCP requests Gmail compose scope (sufficient to create drafts) and Gmail read scope (so the agent can read prior thread context for replies). It does not request the send scope. If your team’s Workspace admin requires scope review, this is the spot to walk them through it.
3. Write the tool policy (Define a tool policy). Allow only draft-creating tools (create_draft, create_draft_reply). Block any tool that includes “send” in the name. Even if Google adds a send tool to the MCP in a future release, the policy prevents the agent from picking it up.
4. Test the policy with a send attempt. Ask the agent to send a test email to your own address. The agent should refuse via the tool policy, or attempt the call and fail. Either is fine; both prove the structural lock holds.
5. Write a one-paragraph operating note explaining the Drafts-folder review step. Lives beside the agent description or in the team’s MCP-wiring doc. The note’s job: the next person who wires an agent to this MCP knows why the policy excludes send.

Done? A connected Gmail MCP, a tool policy that prevents the agent from sending mail under any condition, and a written note your team can read before the next agent is wired.

The agent can do that?

1. Wire the MCP and verify the scopes

Chat → Admin Agent:

I'm wiring Google's official Gmail MCP for an Auxot agent. The agent will produce email drafts that land in Gmail Drafts; the user clicks send from the Gmail UI. List the OAuth scopes the official MCP requests, flag any scope that includes send permission, and explain what each requested scope enables so I can walk our Workspace admin through the review. Output a paste-ready scope-review note.

Why it’s non-obvious: Workspace admins reflexively block new OAuth connections until they understand the scopes. Having the agent enumerate the scopes (compose, read for thread context, optionally labels for filing) and explicitly confirm there is no send scope short-circuits the back-and-forth. The note becomes evidence for the Workspace admin’s records.

2. Lock the tool policy

I'm writing a tool policy for an agent that uses Google's official Gmail MCP. The agent must only call draft tools (typically `create_draft`, `create_draft_reply`). It must not call any tool with "send" in the name, even if such a tool exists or is added in a future MCP release. List the tool policy rules needed: which tools to allow, which to block by name pattern, and which to block by parameter shape. Flag any draft tool that accepts a send-now parameter (some connectors expose a single tool with a send flag; that flag must be blocked).

Why it’s non-obvious: Some Gmail-adjacent MCPs (Composio Gmail, Pipedream Gmail) expose a single update-draft tool that accepts a send flag. If you ever migrate from the official MCP to one of these wrappers, the same policy must block the send flag, not just the send tool. Having the agent name the pattern up-front means the policy survives MCP swaps.

3. Operating note for the team

MCP: Google's official Gmail MCP. Authenticated user: [name]. Agents using this MCP: [list]. Produce a one-paragraph operating note: (1) the agent drafts, the human sends from Gmail; (2) the Drafts folder is the review gate, not a separate Auxot human-step; (3) the tool policy excludes send tools by design; (4) what to do if the agent appears to have sent something (verify in Gmail Sent folder; if it shipped, the policy was loosened or the wrong MCP was wired). Tone: factual. Lives beside the agent description so the next admin reads it before wiring more agents.

Why it’s non-obvious: The biggest risk to this pattern is a second agent being wired to a different Gmail MCP that does allow sends. The operating note is the breadcrumb that tells the next admin: this team’s Gmail wiring is draft-only by design; if you need to write an agent that sends mail, raise it as a separate conversation, not a default migration.

Go deeper

Why Google’s official MCP, not a community wrapper

Two reasons. First, the official MCP is maintained by Google; OAuth flow updates, scope changes, and API deprecations land in the official server before the community wrappers catch up. Second, the official MCP exposes draft tools as a first-class operation; community wrappers sometimes expose a single send-or-draft tool with a flag, which is harder to lock down at the tool-policy layer. The community Gmail MCPs (Composio Gmail, Pipedream Gmail) work and are sometimes necessary for non-Workspace accounts or for cross-product workflows; the official MCP is the recommended default when the agent only needs Gmail.

Where the agent’s output goes in Gmail

The draft lands in the authenticated user’s Drafts folder. The user opens Gmail, sees the draft, reviews, and clicks send. Standard Gmail behavior. If the user has Gmail open in a tab when the agent finishes, the draft appears in the Drafts folder list without a page refresh in most cases. The user does not need to leave Gmail to see the draft.

Reply drafts vs new drafts

The official MCP exposes both. create_draft builds a new message; create_draft_reply builds a reply tied to a thread (preserving the In-Reply-To and References headers so the reply threads correctly in the recipient’s client). Use the reply variant when the agent is responding to an inbound message; the threading discipline matters for the recipient’s experience.

When the Workspace admin requires per-app review

Some Workspace tenants have OAuth app review turned on, which means the official Gmail MCP cannot connect until the Workspace admin approves the app. The approval is a one-time configuration. If the agent’s wiring fails with a scope-related error, the most likely cause is admin review pending; the Auxot UI surfaces the error but the resolution is in the Google Workspace admin console.

Troubleshooting

• The agent appears to have sent an email. Check the Gmail Sent folder for the authenticated user. If the email is in Sent, the tool policy was loosened or a different MCP was wired in parallel. Revoke the connection, audit the tool policy, re-wire.
• The Workspace admin blocked the connection. Per-app review is on. Walk the admin through the scope-review note from power move 1; the official MCP does not request send permission, which is the most common admin concern.
• Drafts are appearing for the wrong user. The OAuth flow was completed by a different user than expected. Each Auxot user authenticates the MCP under their own Google account; team-shared mailboxes need a Workspace identity (a Workspace account dedicated to the shared mailbox) authenticated separately.
• The agent says the tool is unavailable. The MCP connection dropped, often because the OAuth token expired. Re-authenticate from the MCP-server settings panel; the agent picks up the refreshed connection on the next call.

Variations and edge cases

• The team uses Outlook, not Gmail. Microsoft does not offer a first-party Outlook MCP for mailbox operations as of May 2026. See Lock Outlook drafts via a draft-only tool policy for the Composio Outlook wiring.
• The team uses both Gmail and Outlook on different segments. Wire both MCPs. The same tool-policy discipline applies to both (draft tools only, no send tools). Use one agent per mail platform; mixing the two in a single agent confuses the tool-call routing.
• The agent needs to attach files to drafts. The official MCP supports attachments via the create-draft API. The file payload is part of the tool call, not a separate operation. Watch your tool-policy size limits if the attachment is large; some Auxot tiers limit tool-call payload size.
• A shared mailbox needs draft-creation. Authenticate the MCP as the shared mailbox’s Workspace identity, not as an individual user with delegated access. Delegated access works for reading but is unreliable for draft creation across Workspace tenants.

Walkthrough

Step 1: Open the MCP-server settings

Open Settings → MCP servers in Auxot. Click Add server. Search for “Gmail” in the catalog.

Step 2: Pick the official Gmail MCP

The catalog shows multiple Gmail connectors. Pick the one labeled “Google official” or marked as the official Google Workspace connector. The other entries (Composio Gmail, Pipedream Gmail) are community wrappers; they work, but the official MCP is the recommended default for the draft-only pattern.

Step 3: Walk through the OAuth flow

Click connect. The OAuth flow opens in a new tab. Sign in with the team’s Workspace account (not a personal Gmail unless you are testing). Review the requested scopes; the official MCP requests compose, read, and labels scopes. Confirm there is no send scope on the list. Approve.

Step 4: Verify the connection

Back in Auxot, the MCP-server entry should show “Connected” with the authenticated user’s email. Run a single read tool call to verify the connector can see the inbox (the agent should list a few recent message subjects back to you).

Step 5: Write the tool policy

Open Settings → Tool Policies (Define a tool policy). Create a new policy. Allow create_draft and create_draft_reply. Block any tool with “send” in the name. Save.

Step 6: Test both the draft path and the send block

Ask the agent to draft a test email. Confirm the draft appears in Gmail Drafts. Then ask the agent to send a test email. The agent should refuse via the tool policy. Both behaviors confirm the wiring.

What’s next

• → Lock Outlook drafts via a draft-only tool policy. The Outlook counterpart of this pattern, using Composio Outlook.
• → Keep send_email out of your agent tool policies. The cross-cutting principle: why every email-producing agent should be draft-only.
• → Set up your Monday morning briefing. The first place to wire this pattern: a daily briefing the agent drafts and you send.
• → Triage and follow up on inbound leads. Lead-reply drafts use this exact wiring.
• → Screen resumes and draft replies. Candidate decline and advance drafts use the same MCP.
• → Add an MCP server. The MCP wiring foundation this tutorial builds on.

Reference

• MCP: Google’s official Gmail MCP. Free for personal and Workspace accounts.
• Scopes requested: compose (draft creation), read (thread context for replies), labels (optional filing). No send scope.
• Tool policy shape: allow create_draft, create_draft_reply; block any tool with “send” in the name; block any draft tool that exposes a send-now parameter.
• Authentication: per-user OAuth. Each Auxot user authenticates their own Gmail; shared mailboxes need a Workspace identity authenticated separately.
• Where drafts land: the authenticated user’s Gmail Drafts folder.
• The structural review gate: the Drafts folder. No Auxot human-step needed on top.
• Operating note discipline: lives beside the agent description; explains the draft-only design so the next admin does not wire a send-capable MCP in parallel.
• When to use a community Gmail MCP instead: non-Workspace accounts where the official MCP is not approved, or cross-product workflows where Composio’s tool surface is needed. In those cases, the same tool-policy discipline applies, plus extra care on the send-flag parameter.