Taylor Gmail MCP Tool Rules

Safe Starting Point

A first useful Gmail setup should usually expose only labels, search, and read tools with result limits.

Good first tools:

• list labels
• search messages with a short query
• read one message by message_id
• read one thread by thread_id

Keep draft, send, trash, archive, label mutation, batch mutation, and broader Workspace write tools blocked or review-required until you intentionally test one action at a time.

Tool Surface Overview

Typical Gmail-relevant tools:

• search messages
• read message content
• read thread content
• create a draft
• send a message
• modify labels, archive, or trash
• batch modify

Treat the server as a broad workspace surface first, then intentionally select a small Gmail subset.

Read Rules

Start with read/list tools because they are easiest to verify in Activity.

Add result limits to broad search and thread reads. Mailboxes can return more text than expected, and a read can still expose sensitive content.

Controlled Draft Rule

Draft creation still modifies mailbox state. It is not the same as sending, but it is also not a pure read.

Use a controlled draft rule only after read/list calls work through MCP Boundary. For first tests, prefer no-recipient drafts or tightly controlled recipient arguments.

High-Risk Actions

Use block, dashboard_only, or review_required for:

• direct send
• send draft
• forward
• trash
• permanent delete
• batch label modification
• broad mailbox cleanup
• any Drive, Calendar, Docs, Sheets, or Chat write exposed by the same server

Permanent delete and batch mutation should not be part of a first rule config.

Good Bindings

Good Gmail scope bindings:

• message_id
• thread_id
• draft id
• label id
• exact recipient address for controlled tests
• no bcc unless intentionally allowed
• attachment fields blocked or constrained unless tested

For replies, bind the draft or send action to the same thread_id that was read. For label changes, bind to the exact message_id or thread_id that was reviewed.

thread_id and message_id are scope bindings, not hard stale-state checks. They identify the resource, but they do not prove that the thread content is unchanged.

State binding for Gmail-style tools only works if the downstream MCP Server returns a stable state fact such as:

• last message id
• message count
• provider history id
• thread state hash

This playbook intentionally does not include a copyable Gmail state_binding JSON example. Use the database playbook for the hard observation_rules + state_binding example, and only adapt that pattern to Gmail after your selected server exposes and tests stable thread-state fields.

Weak Bindings To Avoid

Avoid rules that rely only on:

• subject line
• sender display name
• search query
• "latest message"
• mailbox position
• agent memory of the last thread
• tool name containing draft, send, or read

These values are not stable enough for write permission.

Example Rule Configs

Labels And Reads First

Use this when you want the agent to search/read Gmail content but keep draft, send, and label mutation out of the normal path.

The agent can see the two read-like tools. MCP Boundary allows those calls and limits returned bytes. Draft is visible only in the dashboard and requires review; send and label mutation are hidden and blocked. This does not claim that Gmail is safe or that every Taylor Workspace tool is supported.

Controlled Draft

Use this only after read/list calls work and you intentionally want to test one draft path.

The agent can request draft_gmail_message. MCP Boundary allows the draft call if the top-level argument rules pass. This still writes to the mailbox, and it does not allow sending.

If the server exposes a stable thread state field, use a read-then-write pattern for send-like actions:

read thread -> record thread_id and state hash -> send only with same thread_id and matching state hash

Do not claim this pattern unless your selected downstream server exposes the needed fields and you have tested the flow. Without those fields, this Gmail playbook demonstrates scope binding and controlled draft/send blocking, not a hard stale-state guarantee.

Demo Walkthrough

Useful walkthrough sequence:

• Discover the Taylor Workspace server.
• Hide every non-Gmail tool.
• Expose one Gmail read/list tool.
• Prove one read call through MCP Boundary Activity.
• Expose one controlled draft tool.
• Keep send blocked.
• Show that send, trash, archive, and batch modify do not dispatch.

Only run a real send in a dedicated test mailbox and only after read and draft evidence is already clean. A controlled send test is not a general email-safety claim.