How to Send Tracked Gmail from Claude, Cursor and Other AI Assistants (MCP)

You already draft emails with Claude or Cursor. Then you copy the text into Gmail, paste in the addresses, hit Send, and a week later you can't remember who answered. The assistant wrote the email but has no idea what happened to it.

A Gmail MCP server closes that loop. MCP (the Model Context Protocol) lets an AI client call outside tools, so the assistant can send the email from your Gmail itself and, with a tracking-aware server, read back who opened and who clicked. Before you connect one, check what it can see. Many Gmail MCP servers are built to read and search your inbox. If all you need is sending and tracking, you can set this up with a server that holds only Gmail's gmail.send permission and can't open a single message you've received.

What can a Gmail MCP server see?

That depends on the OAuth scope behind it, not on the word "Gmail" in its name. Gmail's API publishes a description for each scope in its discovery document. The ones that matter here:

gmail.readonly can read but not send. The other four can all send, and gmail.send is the only one of them that can't read anything.

Inbox-style servers need the broader scopes because their job is to search, read, and label your mail. That's a fair design for an assistant that triages email. For example, the open-source Gmail AutoAuth MCP Server requests gmail.modify and gmail.settings.basic, which it needs for search, labels, and filters. Claude's own Gmail connector can search and read emails and send, reply, and forward, asking for your approval before each send by default.

Here's how the options compare for the narrower job of sending outreach and following up:

The tradeoff runs both ways. An inbox server can see replies; ours can't (more on that below). Ours can tell you who opened and clicked; an inbox server can't, because tracking has to be added to the message when it's sent. If you want an assistant that reads your mail, use one of the first two. If you want one that sends tracked email and nothing more, keep reading. We explain why we stopped at one scope in why we only request gmail.send.

How to connect Claude Code, Cursor, or VS Code to Gmail (step by step)

This takes about five minutes. You need a Maildriply account with Gmail connected, which is free during early access.

Step 1: Create an API key

In the Maildriply dashboard, open Settings → AI & MCP. Name the key after the device or tool ("Cursor on work laptop"), decide whether to turn on Allow sending email, and click Create API key. Copy it right away. It starts with mdk_ and is shown only once.

Leave sending off if you only want the assistant to report on email you already sent. A read-only key can look up emails and tracking but gets an error from every send tool.

Step 2: Add the server to your client

In Claude Code, one command does it (Anthropic's Claude Code MCP docs use the same --header pattern for bearer tokens):

claude mcp add --transport http maildriply https://api.maildriply.com/mcp \
  --header "Authorization: Bearer mdk_your_key"

In Cursor, add this to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "maildriply": {
      "url": "https://api.maildriply.com/mcp",
      "headers": { "Authorization": "Bearer mdk_your_key" }
    }
  }
}

VS Code takes nearly the same block in .vscode/mcp.json, and Claude Desktop needs a small bridge because its config file only launches local servers. Both are spelled out in our MCP setup docs.

Step 3: Send a test to yourself

Start with something that can't go wrong:

Send a test email to myself with the subject "Hello from my assistant".

A good assistant first calls get_account, which returns the connected Gmail address, today's sending quota, and what the key is allowed to do. Then it calls send_test_email. The message lands in your own inbox and is left out of your analytics.

Step 4: Send the real thing

Now ask for what you actually want:

Send this note about the pilot to jordan@example.com and sam@example.com. Put the case study link in it.

Two details make this work better than you might expect:

• Each recipient gets their own copy. Jordan and Sam never see each other's address, and each copy carries its own tracking, so you can tell them apart later.
• Links in plain text get tracked. Assistants usually write plain text. The server turns blank lines into paragraphs and bare URLs into links, and each link becomes a tracked redirect to the URL you wrote.

You can also ask it to schedule ("send Monday at 9am Berlin time"), and it will create a scheduled send you can move or cancel later.

Who opened, who clicked, who gets a follow-up

Sending is the easy part. The reason to connect a tracking server is the next conversation:

Who opened the pilot email but didn't click the case study?

The assistant calls get_email_tracking, which returns each recipient's delivery status, open count, first and last open time, clicks, and which links they clicked. Then it can act on that:

Follow up with everyone who hasn't clicked. Offer a 15-minute call instead.

send_follow_up replies in the original Gmail thread, so the recipient sees it under your first message with a "Re:" subject. You can target a subset, but only people who received the original. If the assistant tries to add a new address to a follow-up, the server refuses with an error it can read and correct.

Treat opens as a hint, not a fact. Gmail's image proxy, Apple Mail Privacy Protection, and corporate security scanners can all load the tracking pixel without a person reading anything. Every tracking result our server returns carries that caveat in plain words, so the model sees it too. A click on a specific link is a much stronger signal. We cover the difference in tracking pixels vs link tracking, and how to read the numbers in the analytics docs.

What we built in so an agent can't misfire

An assistant with a send tool is different from a person with a Send button. It retries when a response is slow, it can loop, and it believes whatever a document told it. These are the guardrails we added after thinking through those failure modes:

• The sender isn't a model input. No tool takes a "from" address. Mail always goes out from the Gmail account you connected, which also keeps it aligned with your domain's SPF, DKIM, and DMARC.
• Retries don't double-send. Send tools accept an optional idempotencyKey. If the client retries with the same key after a lost response, it gets the original result back instead of a second email.
• Loops hit a wall. Send tools are rate-limited per account, and if the limiter itself is unavailable, sends are refused rather than let through. A runaway agent loop is exactly what that limit is for.
• Same rules as the dashboard. Your daily sending quota, warm-up pacing, and suppression of people who unsubscribed all apply. Sends from an assistant count toward Gmail's sending limits like any other.
• Your opens stay clean. The dashboard and extension learn which browser is yours so your own views of a sent email aren't counted as recipient opens. We deliberately skip that step for MCP requests. They come from an AI client, not your mail app, and learning from them could turn a real recipient's open into a "self-view".

Your client is the last check. Most MCP clients can ask for confirmation before running a tool, which shows you the recipients and body before anything goes out. For send tools, keep that confirmation on.

Does it work in the Claude.ai web app or ChatGPT?

Not yet, officially. Our server authenticates with an API key in an Authorization header and doesn't offer an OAuth sign-in flow, which is what most web-app connectors expect. Anthropic's guide to custom connectors now lists a Request headers option for servers that use an API key instead of OAuth. We haven't tested Maildriply through it yet, so our docs still list it as unsupported. Until then, use Claude Code, Claude Desktop, Cursor, or VS Code.

FAQ

Is there an official Gmail MCP server?

There are several, from AI vendors' own Gmail connectors to dozens of open-source servers. Most are designed to read and organize your inbox, so they ask for broad scopes. Check the scope before connecting any of them. It tells you more than the name does.

Can Claude send emails from my Gmail?

Yes. Claude's built-in Gmail connector can send, reply, and forward, and it asks for approval before each action by default. It doesn't add open or click tracking. A tracking server like ours adds that, sends from the same Gmail account, and doesn't need access to your inbox.

Is it safe to give an AI assistant a send-enabled API key?

Treat the key like a password. Create one per device or tool so you can revoke them individually in Settings → AI & MCP, keep it out of repositories, and leave your client's tool-approval prompt on for send tools. A revoked key stops working on its next request.

Can my assistant track emails I send from Gmail myself?

Not over MCP. The assistant sees email it sent through Maildriply. For email you write in Gmail's normal compose window, use the Chrome extension, which adds tracking at send time. Those emails show up in the dashboard as well.

How many people can my assistant email at once?

One send can go to up to 500 recipients, each getting an individual copy. Your daily sending quota still applies: recipients past today's quota wait for the next day's quota instead of failing. Newly connected accounts may start with a lower quota while they warm up.

If you want your assistant to send from your Gmail and tell you what happened afterward, connect it to Maildriply. It's free during early access.