Mailtrap catches mail in a safe sandbox and also sends in production. MCPmailer is where an agent holds a conversation for real.
Transactional email APIs · Mailtrap claims checked July 2026
Mailtrap started as the email sandbox everyone used to keep staging mail away from real people, and has grown a sending platform alongside it, so testing, sending, and inbound live in one account.
For development and staging, an email sandbox is the correct tool and we are not one. Point your non-production environments at Mailtrap so a half-finished agent cannot email a customer at 2am.
A sandbox is exactly the wrong shape for production agents, and the sending side is a conventional transactional API. Neither gives the agent a persistent identity, a thread it can reason over, or a place for the human who is accountable to read what happened.
A sandbox exists to guarantee mail reaches nobody. An agent mailbox exists to guarantee it reaches exactly one person and that the reply lands back in the same conversation. Everything downstream follows from that: a sandbox needs no sending reputation, no suppression list, and no warm domain, while a production agent needs all three from its first message.
Sandbox inboxes belong to environments, and one project usually has one. Agents need identities: one address each, one revocable key each, their own audit trail, and no visibility into the other agents in the workspace. When an agent misbehaves you want to switch off that agent, not that environment.
get_thread, wait_for_reply, search_inbox, and remember_about_contact answer "what is going on with this person". A test inbox answers "did a message arrive and does its body match", which is the right question for CI and useless to an agent deciding what to say next.
Every row is a claim we could defend with their documentation open beside it. Where they are ahead, the row says so.
This is the rare comparison where the answer is genuinely both.
Local and staging
Mailtrap sandbox, so nothing escapes while you iterate on prompts.
Production agents
Real addresses here, on your own subdomain.
The switch between them
One environment variable, since both are configured by endpoint and key.
Yes. Keep agent mail out of real inboxes until you mean it, then switch the endpoint and key for production.
No sandbox. The nearest thing is a separate free workspace on its own subdomain, which is genuinely not as good for CI.
Its sending product can send. You would still build threading, per-agent identity, and oversight yourself.
Point staging at a sandbox, and give the agent a workspace whose contacts are all internal. Our cold-send quotas also gate first contact with a stranger, which catches the case where a prompt invents a recipient.
For the send path, yes: you can assert on what it wrote. What a sandbox cannot rehearse is the half that matters most, which is what happens when a real person replies three days later and the agent has to pick the thread back up with the right context.
A separate free workspace on its own subdomain, which is honestly weaker than a sandbox for CI. Use Mailtrap there and keep this for mail that reaches real people.
Keep your transactional sender for the mail your product sends. This is for the addresses your agents converse from, which is a different job with different failure modes.
The free tier is 3,000 emails a month across three agent inboxes, no card, with receiving, threading, and search included. Enough to watch a real conversation happen before you decide.
More Transactional email APIs