A new open-source bridge called simplelogin-mcp is giving technically inclined SimpleLogin users a way to manage their email aliases through AI assistants and command-line tools, without handing control of the underlying account to anyone but themselves. Built and maintained independently by developer Antoine Ménard, the project has no affiliation with Proton AG, the company behind SimpleLogin - it simply talks to SimpleLogin's existing API on the user's behalf.
The distinction matters more than it might first appear. Alias management services sit at a sensitive junction of identity and inbox security: an alias address, once compromised or mismanaged, can expose a user's real email, break mail routing, or silently reroute sensitive correspondence. simplelogin-mcp does not store accounts, messages, or credentials of its own. It acts as a translator between a Model Context Protocol (MCP) client - the kind of interface increasingly used by AI assistants and developer tools - and the official SimpleLogin API, which remains the sole owner of the account, its aliases, and its mail routing. Users who are comparing privacy-focused infrastructure more broadly, including VPN or proxy options that pair well with alias-based anonymity, can see the server list at see the server list before deciding how to structure their setup.
What the Bridge Actually Does
The tool is built for specific, reviewable workflows: finding disabled aliases, creating new ones, inspecting recent alias activity, managing reverse aliases, or checking mailbox routing. It is explicitly not a replacement for the SimpleLogin web application. Anything involving sign-in, multi-factor authentication, password resets, billing, API-key issuance, custom domain verification, or account deletion still has to happen directly through SimpleLogin's own interface or support channels - areas the project considers out of scope by design, not oversight.
Three deployment paths are documented: a local stdio mode for a single desktop or command-line client, a persistent Node.js service using Streamable HTTP, and a Docker Compose setup for operators who prefer containerized, loopback-bound deployments. Each represents a different trust boundary. Local stdio opens no network listener at all, making it the most contained option for individual users; the HTTP variants suit shared or persistent setups but require more careful access control.
Two Keys, Two Very Different Risks
Authentication in this system runs on two separate credentials, and conflating them is the most consequential mistake a user can make. The SL_API_KEY authenticates the bridge itself to SimpleLogin and effectively grants full control of the account - creating, disabling, or deleting aliases included. The MCP_AUTH_TOKEN, by contrast, only authenticates an MCP client to the local server; rotating it does nothing to revoke a leaked SimpleLogin key. Treating these as interchangeable credentials would undermine the entire point of separating them.
This separation reflects a broader pattern in how privacy-conscious tooling is evolving: rather than one monolithic login granting blanket access, systems increasingly split authority into narrower, revocable scopes. It mirrors the logic behind API tokens, OAuth scopes, and hardware security keys - the assumption that any single credential will eventually leak, so damage should be containable.
Where the Limits Are Drawn
The server has no database and does not retain tool inputs or outputs; it writes only sanitized diagnostic information to its own error stream. But the project is candid that this does not guarantee privacy end-to-end - the MCP client, the AI model provider behind it, and the surrounding deployment environment may all retain data according to their own policies. Alias metadata, mailbox routes, and activity logs are explicitly flagged as sensitive, even though the tool never exposes actual message content.
Destructive actions carry deliberate friction. Permanent deletion of aliases or contacts requires an explicit confirmation flag, and mailbox deletion additionally forces a choice about transferring or discarding associated aliases. Some routing changes are marked as destructive even when technically reversible, because they can interrupt mail delivery in the interim. The server enforces these checks locally, but ultimate responsibility for presenting clear approval prompts rests with whichever MCP client a user connects - a reminder that automation tools shift workflow convenience without eliminating the need for human oversight over account-level changes.