A new open-source bridge called simplelogin-mcp is giving technically inclined users a way to connect automated assistants directly to their SimpleLogin alias accounts, without handing control to any single company's platform. Built and maintained independently by developer Antoine Ménard, the project is explicit about what it is not: it carries no affiliation with, and no endorsement from, Proton AG or the official SimpleLogin product itself. Instead, it functions as a client that speaks to SimpleLogin's existing API, leaving the underlying service - the one that actually owns the account, the aliases, and the mail routing - exactly where it has always been.
The appeal lies in what the tool enables rather than what it replaces. Anyone already relying on SimpleLogin to generate disposable email aliases can use this bridge to let a compatible MCP client search for disabled aliases, create new ones, inspect recent alias activity, manage reverse aliases, or review mailbox routing - all through a reviewable, auditable workflow rather than manual clicking through a web dashboard. This matters because alias management, done well, is a quiet but significant piece of personal data hygiene; knowing which aliases are stale, which have been receiving odd traffic, or which mailboxes route where is the kind of housekeeping that most people put off. For readers weighing which privacy-oriented email or VPN services deserve a place in their toolkit, a provider comparison table can help frame how alias-based privacy tools fit alongside broader encryption and anonymity services before committing to any particular workflow. a provider comparison table
It is worth being clear about what this project deliberately avoids touching. Sign-in, multi-factor authentication, password resets, API-key creation, billing and subscription questions, account deletion, custom domain verification through DNS and MX records, and any decision about whether a message actually gets delivered - all of that remains the exclusive domain of the official SimpleLogin web app and its support channels. The bridge is a control layer for metadata and actions exposed through the API; it was never designed to replace the account infrastructure itself.
How the Access and Trust Model Works
Running the tool requires an SL_API_KEY, generated through SimpleLogin's own key-creation process, which grants full control over the account it belongs to. A separate credential, MCP_AUTH_TOKEN, authenticates an HTTP-based client to the bridge server itself - a distinct bearer token that does not touch SimpleLogin directly. The distinction matters for security reasons: rotating the MCP_AUTH_TOKEN does nothing to revoke a leaked SL_API_KEY, so users need to treat the two credentials as separate risk surfaces, not interchangeable safeguards.
Deployment options reflect that same risk-conscious design. A local stdio setup lets a single desktop client launch the server with no open network listener, which keeps the trust boundary as small as possible. A direct Node.js deployment using Streamable HTTP suits a persistent same-machine service, while a Docker Compose configuration offers an operator-managed container that publishes on loopback by default rather than exposing itself openly on a network.
What the Tool Sees, and What It Deliberately Ignores
simplelogin-mcp is not an inbox client. It cannot read message bodies. What it can access is metadata: alias details, bounded activity entries showing action, sender, recipient, and timestamp, along with reverse-alias information. That is still sensitive data - patterns of who is emailing an alias and when can reveal a good deal about a person's habits - so the project recommends reviewing the connected MCP client's own privacy and retention settings before granting it access, since the bridge itself keeps no database and does not persist tool inputs or results beyond sanitized diagnostic logging.
Several actions carry real consequences. Permanent deletion of aliases or contacts requires explicit confirmation, and mailbox deletion demands both confirmation and a choice about whether existing aliases get transferred or removed. Some routing changes are flagged as destructive even when technically reversible, because they can halt delivery immediately. The server enforces these checks locally, but it is ultimately the connected client's responsibility to present approval prompts clearly to the person using it - a reminder that automation tools shift convenience forward only as far as the humans supervising them allow.