Introducing the MailSandbox MCP server: email testing inside your AI editor

You send a test email from your app, then you leave your editor, open a dashboard in another browser tab, hunt for the message in a list, and squint at the HTML to check it rendered. The MailSandbox MCP server removes that round trip. Your AI coding agent talks to your sandbox inbox directly, so it can send a test message, pull it back, and check it for spam or broken rendering without you ever touching a browser.

If you already use Cursor, Claude Code, or another AI agent to write your app, this keeps email testing in the same window as everything else. Here's what it does, how it stays safe, and how to wire it up in a couple of minutes.

The dashboard tab you keep forgetting about

Testing transactional email usually goes like this. You point your app's SMTP settings at a sandbox so nothing hits real users. You trigger a password reset, an order confirmation, or a welcome email. Then you switch to a browser, log into a dashboard, find the message in a list, open it, and read the HTML preview to confirm it looks right. If you spot a broken link or a spam trigger, you flip back to your editor, fix the template, and run the whole loop again. None of this is hard. It's just slow, and every pass drags you out of the place where you're actually writing code. Do it twenty times while you're building a new email flow and the tab-switching adds up.

What MCP is, in two sentences

Model Context Protocol, or MCP, is a standard way for AI agents to call external tools. Rather than building a one-off integration for every service, your agent connects to an MCP server that exposes a set of actions it's allowed to run for you, things like sending an email or reading one back. MailSandbox ships one of these servers.

What the MailSandbox MCP server gives your agent

The MailSandbox MCP server gives your agent five tools. It chooses whichever one fits what you asked for in plain language, so you describe the outcome and it makes the calls.

• send-email: sends a test message into your sandbox inbox, with whatever subject, body, and HTML you describe.
• list-messages: returns the messages sitting in your inbox so the agent can find the one it just sent, or an older one.
• get-message: pulls the full content of a single message, including headers, plain text, HTML, and attachments.
• analyze-message: runs a spam score plus an HTML-client compatibility check, so you learn whether the email will land in spam or break in Outlook before it ships.
• delete-message: clears a message out of the inbox once you're done with it.

That covers the full loop: create a message, find it, read it, check it, and clean up. Your agent chains these together on its own when a request needs more than one step.

Nothing reaches a real person

Every message your agent sends through send-email lands in your sandbox inbox and stops there. Nothing is delivered onward, so there's no chance of a test welcome email reaching a real customer because someone left a live address in a fixture. That's the entire reason a sandbox exists, and it holds no matter whether the mail comes from your app's SMTP config or straight from your agent through the MCP.

You only ever see your own inbox

The MCP authenticates with your inbox's own API key. That key scopes the agent to exactly one inbox: yours. When it calls list-messages or get-message, it only ever sees mail from the inbox tied to that key, so you're never staring at another developer's test data and nobody else can read yours. Running several projects at once? Give each one its own inbox and its own key. The agent connected to a given project only touches that project's mail, which keeps environments from bleeding into each other.

Setting it up in Cursor

First, grab your key. Open the inbox you want to test against, find the panel labelled 'Connect to Cursor & Claude (MCP)', and copy the API key it shows. Then add this to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "mailsandbox": {
      "url": "https://mailsandbox.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_INBOX_API_KEY"
      }
    }
  }
}

Restart Cursor and the five tools appear for your agent automatically. Some clients only speak stdio and can't reach a remote MCP URL on their own. For those, run the connection through mcp-remote, which bridges a local stdio process to the remote server:

{
  "mcpServers": {
    "mailsandbox": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mailsandbox.com/mcp",
        "--header",
        "Authorization: Bearer YOUR_INBOX_API_KEY"
      ]
    }
  }
}

Swap in your real key, and you get the same five tools, just proxied through a local process instead of a direct HTTP connection.

A real example, start to finish

Here's the whole thing in one request. Tell your agent: send a test welcome email, then check it for spam issues. Behind the scenes, the agent calls send-email with the subject and body it drafted, which drops the message into your sandbox inbox. Next it calls analyze-message on that same message and reads back two things: the spam score and the HTML-client compatibility report. Then it summarises in the chat: the email sent fine, it scored well under the spam threshold, and one CSS property won't render in Outlook. You never left the editor, and you caught the Outlook issue before a single real recipient could have seen it.

Any MCP client works

The setup above uses Cursor because its config file is the one people ask about most, but none of this is tied to Cursor. Claude Code, VS Code with an MCP extension, and any other MCP-capable client connect the same way: point them at the MailSandbox MCP URL, pass your inbox key, and the same five tools are there. Use whichever editor you already spend your day in.