Privacy policy

Last updated: 3 October 2026

The short version: email-mcp runs on your own machine and has no server of its own. It is an MCP (Model Context Protocol) server you install and run locally, alongside an AI assistant like Claude. When it reads, sends or organizes email, it calls Gmail's, Microsoft's, Apple's or your IMAP provider's API directly, from your machine, using your own OAuth token or password. Nothing about your email passes through a server we operate, because no such server exists in this flow.

What email-mcp stores, and where

• Account credentials. Gmail OAuth tokens, the Outlook access token and passwords (iCloud, generic IMAP) are stored in an encrypted file on your own machine (~/.email-mcp/credentials.enc). The Outlook refresh token is kept by Microsoft's own sign-in library in a separate token cache on your machine (~/.email-mcp/msal-cache.enc). Neither file ever leaves your machine or is sent to us. How both are protected is described in How sensitive data is protected below.
• Downloaded attachments saved via the email_save_attachment tool are written as ordinary, unencrypted files to a local directory (~/.email-mcp/downloads by default, configurable with EMAIL_MCP_DOWNLOADS_DIR) and go nowhere else. On macOS and Linux each saved file is readable and writable only by your user account (permissions 0600), and folders email-mcp creates for them are accessible only by your user account (0700).
• Email content itself is never stored by email-mcp. Messages are fetched from your provider on demand, at the request of whichever AI assistant is using the tool, and returned directly to that assistant. What that assistant's own provider (e.g. Anthropic, for Claude) does with the content it receives is governed by that provider's own privacy policy, not this one.

What email-mcp sends over the network, and to whom

Exactly two kinds of outbound request exist, both initiated by your own machine:

• To your email provider (Gmail's API, Microsoft Graph, or an IMAP/SMTP server), to authenticate, and to carry out whatever tool call you or your assistant triggered (search, send, organize, and so on).
• To Google's or Microsoft's OAuth endpoints, for the standard authorization-code exchange during setup, and silent token refresh afterward. This uses the shared OAuth Client ID this project ships with by default, or your own if you set EMAIL_MCP_GMAIL_CLIENT_ID/EMAIL_MCP_OUTLOOK_CLIENT_ID. A shared Client ID identifies the application to Google/Microsoft; it does not give us visibility into your account, your tokens, or your mail.

There is no third request. No analytics, no crash reporting, no telemetry, no update-check phone-home. You can verify this yourself: the source is on GitHub.

How sensitive data is protected

The sensitive data email-mcp handles is of three kinds: OAuth tokens that grant access to your Gmail or Outlook account, passwords for iCloud and IMAP accounts, and the content of your email. This section describes the safeguards the software applies to each. Every statement here can be checked against the source code on GitHub.

No server of ours holds or sees your data

email-mcp runs as a local process on your own computer. Your AI assistant starts it and talks to it over standard input and output (stdio), not over a network port. Your tokens, passwords and email content are handled only inside that process, on your machine, and travel only between your machine and your email provider. We, the publisher, operate no server in this flow and never receive, store or have access to your tokens, your passwords or the content of your email.

Encryption at rest

• Credentials file. ~/.email-mcp/credentials.enc is encrypted with AES-256-GCM, an authenticated cipher: any modification of the file is detected and decryption fails rather than returning altered data. The 256-bit key is derived with PBKDF2 (HMAC-SHA512, 100,000 iterations) from a fresh random 32-byte salt, and a fresh random 16-byte initialisation vector is used, every time the file is written.
• Where the key comes from. The key is derived either from the EMAIL_MCP_KEY environment variable, if you set one, or from your machine's stable hardware or operating system identifier combined with your user name. On a machine where no such identifier can be read, the computer's host name is used instead. No key is stored in the file itself.
• What this protects against, and what it does not. The encryption keeps the file unreadable if it is copied off your machine, for example into a backup, a synced folder or onto another computer. It is not a defence against software already running under your own user account on the same machine, which can derive the same key. For that reason the files are also restricted by permissions: on macOS and Linux, ~/.email-mcp is created readable only by your user account and the credential files are written with owner-only access. Setting your own EMAIL_MCP_KEY ties the key to a secret you hold rather than to the machine.
• Outlook token cache. The Outlook refresh token lives in ~/.email-mcp/msal-cache.enc, the token cache of Microsoft's authentication library (MSAL). email-mcp encrypts this file with the same AES-256-GCM scheme and key derivation as credentials.enc (so EMAIL_MCP_KEY, if you set one, protects both files), and writes it with owner-only access on macOS and Linux. A cache left in plain text by an older version is encrypted and the plain-text copy deleted the first time it is read.
• Email content is not stored. Messages are fetched from your provider on demand and passed straight to your AI assistant; email-mcp keeps no copy, cache or index of them on disk. The only email data it writes to disk is an attachment you explicitly ask it to save, described above.
• Local files are read only to attach them, and only from one folder. When you ask your assistant to attach a file to an outgoing message, email-mcp reads it from the folder you named in the EMAIL_MCP_ATTACHMENTS_DIR setting and from nowhere else. Without that setting it reads no local file at all. No tool of email-mcp can change the setting.

Encryption in transit

• All traffic to Google (the Gmail API and Google's OAuth endpoints) and to Microsoft (Microsoft Graph and Microsoft's sign-in endpoints) uses HTTPS, that is, Transport Layer Security (TLS).
• For iCloud and generic IMAP accounts, the IMAP connection uses TLS by default. Outgoing mail over SMTP uses TLS from the first byte on port 465, and on port 587 upgrades the connection to TLS (STARTTLS) when the mail server offers it. The setup wizard lets you turn TLS off for an IMAP server you control; we recommend leaving it on.

How sign-in is secured

• You sign in with Google or Microsoft directly. Your Google or Microsoft password is entered only on the provider's own sign-in page in your browser. email-mcp never sees it; it receives only the tokens the provider issues after you consent.
• PKCE. Both the Gmail and the Outlook sign-in use Proof Key for Code Exchange (PKCE) with the S256 method: a one-time secret generated on your machine for each sign-in must be presented to exchange the authorization code for tokens, so an intercepted code is useless on its own.
• State parameter. Each sign-in also carries a fresh random state value. The temporary callback listener on http://localhost accepts an authorization code only if it arrives with that exact value, and rejects anything else without exchanging it. This protects against cross-site request forgery. The listener accepts connections from this computer only (it listens on the loopback address, not on your network), exists only during sign-in, and shuts down once a code is received, or after two minutes.
• Minimum scopes, with a more restricted option. email-mcp requests only the Gmail scopes needed for the features it offers (listed under Gmail API scopes), and the setup wizard offers a Restricted mode that leaves out the permanent-delete permission. For Outlook it requests Mail.ReadWrite, Mail.Send, MailboxSettings.ReadWrite and offline_access.
• iCloud uses an app-specific password you create at Apple, not your Apple Account password, and you can revoke it at Apple at any time.

Revoking access and deleting your data

• Remove one account: the email_remove_account tool deletes that account's stored credentials from credentials.enc. For a Gmail account it also asks Google to revoke the permission you gave; for an Outlook account it also deletes the account's tokens from the Outlook token cache. The result tells you what it could not do.
• Remove everything: deleting the ~/.email-mcp folder removes every token, password, cache and saved attachment email-mcp has stored (unless you pointed EMAIL_MCP_DOWNLOADS_DIR elsewhere, in which case delete that folder too).
• Revoke the grant at the provider: for Gmail, removing the account revokes the grant at Google automatically. If Google cannot be reached or refuses, the result says so and links to myaccount.google.com/permissions, where you can remove email-mcp yourself (Security, Third-party apps with account access). Microsoft offers no endpoint through which an app can revoke this permission for a personal Microsoft account, so for Outlook the tokens are deleted from your machine but the permission stays until you remove email-mcp in your Microsoft account (Privacy, Apps and services, or account.live.com/consent/Manage). Delete app-specific passwords at Apple. After that, any token still on your machine stops working.
• Because we hold none of your data, there is nothing for us to delete on our side. If you have a question about this, contact us at the address below.

Gmail API scopes, specifically

The setup wizard lets you choose between two Gmail permission levels. Full (the default) requests https://mail.google.com/, gmail.modify and gmail.settings.basic, which includes the ability to permanently delete messages. Restricted drops the permanent-delete permission and keeps only gmail.modify and gmail.settings.basic, which covers every other tool this server exposes (read, send, label, archive, move to trash, manage filters).

gmail.settings.basic is used for two kinds of Gmail filter, both created when your assistant receives a request to create one: block rules, which delete or archive mail from a sender you named, and forwarding rules, which send matching mail on to another address (for example invoices to a bookkeeping address). Forwarding is switched off by default. It works only for addresses that you listed yourself in the EMAIL_MCP_FORWARD_ALLOWLIST setting of the program, which no tool of email-mcp can change, and that you also added and confirmed as a forwarding address in Gmail's own settings. email-mcp cannot add a forwarding address to your Google account: it does not request the scope that would allow that. For Outlook, where Microsoft asks for no confirmation, the same setting is the only way to allow a target. You can see every forwarding rule on an account with email_list_forward_rules and remove one with email_delete_forward_rule, or in your mail provider's settings.

Google verification and the security assessment

All three Gmail scopes above are on Google's list of restricted scopes, in Restricted mode as well. Google reviews every app that requests them before it can be offered to the public. For the shared OAuth app this project publishes, that review is still running. Status on 1 October 2026:

• Submitted so far: the app's branding, homepage and domain, this privacy policy, the requested scopes, and a demo video of the consent screen and each feature.
• Still open: a security assessment. On 30 September 2026 Google asked for a CASA (Cloud Application Security Assessment) at Assurance Level 1, formerly called Tier 2, due by 29 December 2026. An independent lab authorized by the App Defense Alliance checks the application against a published security standard, and the assessment has to be repeated every 12 months for as long as the app requests restricted scopes.
• Who charges for it: Google charges nothing. The lab does: 675 US dollars per assessment at the lab Google names as its preferred partner (its listed price on 1 October 2026), due again every year. This project is free and open source and has no paid tier, so the fee is collected through donations on GitHub Sponsors and Buy Me a Coffee until 2 November 2026, the day the assessment has to start, and the maintainer pays what is missing then. The homepage shows how much has come in. That number is read from the two platforms once a day when the site is built, and only the sum and the number of supporters are published, never names or single amounts.
• Whether it applies at all is being clarified. Google's restricted scope documentation requires the assessment for an app that "has the ability to access data from or through a third-party server". email-mcp has no server of its own (see How sensitive data is protected), so we are clarifying with Google whether the assessment applies to it. If it does, the assessment will be done.

What this means for you today: until the review is complete, Google only lets accounts on the shared app's test-user list sign in through it. Everyone else sees Google's "has not completed the Google verification process" screen. Two ways around that, both free: register your own OAuth client in the Google Cloud Console and set EMAIL_MCP_GMAIL_CLIENT_ID and EMAIL_MCP_GMAIL_CLIENT_SECRET (steps in the README), or connect Gmail as an "Other IMAP" account with a Google app password. Outlook, iCloud and other IMAP accounts are not affected. Progress is tracked in GitHub issue #1, and this section is updated when the status changes.

Google user data: Limited Use

email-mcp's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:

• Gmail data is used only to provide the email features you request through your AI assistant: reading, searching, sending, organizing and filtering your mail.
• It is transferred only to the AI assistant you connected email-mcp to, at your request, as part of those features. What that assistant's provider does with it is governed by that provider's own terms.
• It is never sold, never used for advertising, and never used by us to develop, improve or train generalized or non-personalized AI or machine learning models.
• No human at this project reads it, because it never reaches us.

What we collect

Nothing. There is no account with this project, no signup, and no server-side logging of your usage, your email content, or your credentials.

Third-party providers

Your use of Gmail, Outlook/Microsoft 365, iCloud, or any IMAP provider through email-mcp remains subject to that provider's own terms and privacy policy. email-mcp is an independent client and is not affiliated with or endorsed by Google, Microsoft or Apple.

Data removal

Uninstalling the package and deleting ~/.email-mcp removes everything email-mcp ever stored, because everything it stored lives on your machine. To revoke its access to your Google or Microsoft account at the source, follow the steps under Revoking access and deleting your data.

Changes

If this policy changes, the change will be visible on this page. The core commitment, that email-mcp runs locally and reports nothing back to us, will not change.

Contact

marlinjaipohl@gmail.com, or open an issue on GitHub.