MCP server

@atrix-mail/mcp exposes 41 tools over the same API key you already use. It is a thin adapter over this REST API — every tool is one call, and the key's scopes decide what the assistant can reach. Connect it to Claude, Claude Code, Cursor, or anything else that speaks MCP.

Connect over stdio

The usual setup for a desktop client: the server runs as a subprocess with your key in its environment.

{
  "mcpServers": {
    "atrix-mail": {
      "command": "npx",
      "args": ["-y", "@atrix-mail/mcp"],
      "env": { "ATRIX_MAIL_API_KEY": "am_live_..." }
    }
  }
}

In Claude Code, one command does it:

claude mcp add atrix-mail --env ATRIX_MAIL_API_KEY=am_live_... -- npx -y @atrix-mail/mcp

Connect over HTTP

For clients that take a URL rather than a command, the hosted endpoint accepts your key as a bearer token:

POST https://mcp.mail.atrix.dev/mcp
Authorization: Bearer am_live_...

The endpoint holds no key of its own — every request is served under the key it carries, so nothing crosses between organizations, and a request without one is refused with 401.

What it can do

• Send — send_email with attachments, templates, scheduling and idempotency keys; then get_email for the delivery timeline.
• Domains — add a domain, read back exactly which DNS record is still wrong, and trigger a re-check.
• Mailboxes — create mailboxes and forwarding aliases on a verified domain, and read back the IMAP/SMTP settings to hand a mail client.
• Audiences — create lists, import up to 1000 contacts at a time, page through them.
• Broadcasts — draft a campaign, send or schedule it, watch opens and clicks land.
• Templates — manage the {{variable}} templates that send_email renders.
• Webhooks — register endpoints, fire a test event, and read delivery attempts to diagnose one that stopped firing.
• Analytics — 30-day deliverability, and a searchable message log for “did this person get our email”.

Scopes

Each tool needs its scope on the key, so the key is the real permission boundary. Issue one under Settings → API keys with only what the integration needs; a tool called without its scope returns a forbidden error naming the missing scope.

* grants all of them, and only org admins and owners can create a key with it.

Keeping it safe

An assistant with a sending key can mail real people, and mail cannot be recalled. Three guardrails sit on top of the scopes.

Irreversible actions need explicit confirmation

send_broadcast mails an entire audience; delete_mailbox destroys someone's stored mail. Both schemas require confirm: true, so the model has to set it deliberately, and the server's instructions tell it to get your approval for that specific action first. Have it create_broadcast as a draft and show you the recipient count before you approve, and prefer suspending a mailbox with update_mailbox over deleting it.

Mailbox passwords cannot be changed through a key

create_mailbox sets a mailbox's first password, but no API key can change an existing one — update_mailbox rejects a password field rather than ignoring it, and password resets stay in the dashboard. Otherwise a leaked key could take over a mailbox and read its mail.

Read-only mode

Set ATRIX_MAIL_READ_ONLY=1 and only the read tools are registered — the write ones do not exist to be called at all. Pair it with a read-scoped key for an assistant that should inspect the account but never change it.

Rate limits

The platform surface is metered per key: 60 writes and 600 reads per minute, on separate windows so polling a domain verification cannot starve a write. Over the limit you get 429 rate_limited with a Retry-After header, which the tools surface as a readable delay. Sending has its own plan-derived budget — see rate limits.

Configuration