Atomic Mail Agentic: An MCP Integration Guide for Letting AI Agents Send and Receive Email Autonomously

Who It's For

• Developers who need AI agents to autonomously register, send/receive, and manage email: the official positioning is an email service for autonomous AI agents — an agent can register its own @atomicmail.ai inbox and manage it end to end, with no manual setup, verification, or ongoing human intervention.
• Scenarios where you connect mail capabilities via an MCP-capable client (e.g., a host that supports mcpServers configuration).
• Not suitable for organizations that require manual approval for mailbox registration: the service explicitly uses a proof-of-work (PoW) registration protocol with no CAPTCHA and no manual approval step. If you need admin approval before a mailbox is provisioned, this product is the opposite of that model.
• Prerequisites and unknowns: registration requires completing PoW; the evidence does not state whether there are rate limits, inbox expiration, or account policy details — verify these in the official repository before use.

First Try in 3 Minutes

The recommended main path is connecting via the MCP server. Add the following to your host's mcpServers configuration:

"mcpServers": {
  "atomicmail": {
    "command": "npx",
    "args": ["-y", "@atomicmail/mcp-github"]
  }
}

Steps:

1. Prerequisites: Node/npx installed locally, and a host that supports MCP configuration (restart the host for changes to take effect).
2. Write the configuration snippet above into your host's MCP configuration file, then restart the host.
3. Call the register tool to complete registration (the agent performs the PoW registration and obtains its own @atomicmail.ai mailbox). Note: this is not a read-only operation — it writes a credentials file locally at ~/.atomicmail/credentials.json (per official docs, written with 0600 permissions). This is an account-creation action with the side effect of creating a real mailbox.
4. After successful registration, call the help tool to see available capabilities — a low-risk first observation point.
5. Success signals: register returns the registered mailbox identity, ~/.atomicmail/credentials.json exists, and help lists tools such as jmap_request.

Read-only try vs. actually sending mail: register and help do not send any email; the first real send is performed via jmap_request. Sending is an outbound write operation (the email genuinely reaches the recipient), so confirm the recipient address before executing. Custom-domain inboxes do not use PoW registration; instead they connect via an API key (atomicmail register --api-key "…") or OAuth — see the official repository for details.

The service also officially offers an AgentSkill CLI path (npx --package=@atomicmail/agent-skill-github atomicmail register --username "myagent" --watch scheduled); this is a secondary path and is not covered further in this guide.

Use Cases

Use case 1: Register a dedicated mailbox for your agent. The scenario is that you want the agent to have its own mail identity. After connecting the MCP server, call the register tool; the agent completes PoW registration and gets an @atomicmail.ai mailbox. Within the evidence, you can expect a returned registered mailbox identity and a local ~/.atomicmail/credentials.json. Both the tool name and the credentials path come from the official documentation.

Use case 2: List the inbox (read-only observation). The scenario is that you've already registered and want to confirm the mail pipeline works. Per official docs, the AgentSkill path passes preset file names to jmap_request; the bundled presets include list_inbox, send_mail, reply, and others. On the MCP path, the same jmap_request tool is used; list_inbox is a read-only operation that reads the inbox. The evidence confirms the bundled presets exist, but does not give the full parameter structure for MCP calls — after connecting, use the help tool to verify the exact parameters against the official source rather than relying on invented parameters here.

Boundaries of Use

• Read/write nature: register is account creation (a write operation that stores local credentials); jmap_request depends on the preset chosen — list_inbox is a read, while send_mail and reply are outbound sends (real side effects; once an email reaches external recipients it usually cannot be recalled; the evidence does not state whether an official recall mechanism exists, so do not assume it is revocable).
• Credentials and local data: after registration, credentials are stored at ~/.atomicmail/credentials.json (0600 permissions). This is a sensitive local file — if it leaks, the mailbox is effectively taken over.
• Explicit official restrictions: registration uses the PoW protocol with no CAPTCHA and no manual approval step; officially, install only from the @atomicmail npm scope to avoid counterfeit packages.
• Unverified key information: mailbox count limits, PoW duration, account recycling policies, sending quotas, and anti-spam measures are not covered by the current evidence — verify in the official repository before performing write operations.

A note on safety wording: "read-only" above only means the operation performs no write actions; it does not imply there is no network access or no privacy boundary. There is no "zero-risk" way to integrate.