OpenMail gives agents an address over an API and CLI. MCPmailer adds MCP-native tools, a supervision dashboard, and workspace memory.
Agent inbox APIs · OpenMail claims checked July 2026
OpenMail provisions dedicated email addresses for agents through an API and a CLI, sends and receives in real time, and parses attachments automatically. Its argument is that email infrastructure for agents should be trivial to reach for, and the CLI makes that true.
If you want something you can pipe into a shell script and learn in one sitting, OpenMail is a clean fit. Automatic attachment parsing is a genuine convenience when inbound files are the point of the workflow.
We are aiming at the part after the first send. Which agent said what to whom, what it knows about the person it is talking to, what happens when a bounce rate climbs, and who can read the thread afterwards. That is a bigger surface than an address, and it is reached over MCP rather than through an SDK you adapt.
Any MCP client points at connect.mcpmailer.com/mcp with a bearer key and immediately has the whole tool set. There is no client library to keep in step with your agent framework, and no glue layer that has to be rewritten when the framework changes its tool interface.
When an agent emails a customer, somebody eventually has to answer for what it said. Every thread is readable in the dashboard, and a human can take one over and reply as themselves mid-conversation. That is a product surface, and it is not something a CLI-shaped tool tends to grow.
A contact book the agent writes facts into, shared notes, and an encrypted vault for the credentials it needs, all reachable as tools. The mail is the channel; the workspace is what makes the agent competent on the twentieth conversation rather than the first.
Every row is a claim we could defend with their documentation open beside it. Where they are ahead, the row says so.
Same shape of product, so the cutover is short.
Create an agent per address
Each one gets a handle, an address, and a key scoped to it alone.
Swap the CLI for tools, or keep a CLI
`npm install -g @mcpmailer/cli` gives you mcpmailer mail:list and friends, every command with --json, if scripting is what you liked.
Move the domain when you are ready
The instant subdomain works from the first minute; verify your own subdomain once the agent behaves.
If you like the per-agent address and want MCP as the native interface plus a place for a human to watch, yes. If the CLI-first workflow is what sold you, ours exists but it is not the centre of the product.
Yes. npm install -g @mcpmailer/cli, then commands like mcpmailer mail:list, all with --json, and a refused send exits non-zero with the reason.
read_message lists them and get_attachment fetches one by filename. Outbound attachments go as base64 on send_email.
No. Your workspace gets you.mcpmailer.email immediately, and you can verify agents.yourcompany.com later without changing any agent code.
If you are choosing between agent inbox APIs, the deciding question is usually where the conversation state lives. Ours lives in the mailbox, and your agent reaches it with tools instead of with a schema you maintain.
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 Agent inbox APIs