LLMs can draft text. MultiMail gives them an actual inbox, approval controls, thread awareness, and delivery guarantees — the infrastructure layer real agents need.
Getting an LLM to compose an email is straightforward. Making that agent reliable in production is not. You need inbox access with proper authentication, a way to queue outbound messages for human review before they send, reply threading so responses land in the right conversation, and an audit trail when something goes wrong. Most developers wire these pieces together from scratch — SMTP credentials, a polling loop, a webhook handler, a queue — and end up with brittle glue code that breaks the first time an approval is missed or a reply lands in the wrong thread.
MultiMail is purpose-built email infrastructure for AI agents. You connect once via MCP or REST API, configure an oversight mode that matches your trust level, and get primitives for the full email lifecycle: check_inbox, read_email, get_thread, draft_reply, decide_email, send_email, and list_pending. The gated_send mode lets your agent read and draft autonomously while queuing every outbound message for human approval before delivery — a practical default for new agents that haven't yet earned full send permissions.
Create a mailbox at your own domain or use a @multimail.dev address. Your API key (mm_live_... or mm_test_...) authenticates all requests. Set the oversight mode to gated_send so the agent can read and draft without sending anything unsupervised.
Add MultiMail to your agent's MCP config to expose all 51 tools directly to your LLM runtime, or call the REST API at https://api.multimail.dev with a Bearer token. Both surfaces expose the same primitives: check_inbox, read_email, get_thread, send_email, reply_email, decide_email, and list_pending.
The agent calls check_inbox to discover new messages, then read_email to retrieve full content, and get_thread to load prior conversation history. Thread context is essential — agents that reply without it produce responses that ignore what was already said.
With thread context in hand, the agent drafts a reply and calls reply_email. In gated_send mode the message is queued rather than sent immediately. The human reviewer sees the full draft via the approval webhook or the list_pending endpoint and can approve or reject.
After approval, MultiMail delivers the message and fires a delivery webhook. The agent can poll or listen for bounce events, open tracking, and reply-back notifications to decide its next action — closing the loop without manual intervention.
Pick your platform, copy the prompt, and paste it to your AI agent — it sets up MultiMail and builds the whole flow. Nothing to fill in.
MultiMail handles delivery, bounce handling, DKIM signing, and inbound parsing. Your agent calls check_inbox and read_email — no SMTP credentials, no polling loop, no MX record management.
gated_send mode queues every outbound message before delivery. You get list_pending and decide_email endpoints, plus webhooks — no separate approval service to build and maintain.
get_thread returns the full conversation history in a single call. Replies land in the correct thread with proper In-Reply-To headers, so responses appear correctly in every email client your recipients use.
Every read, draft, approval, and send is logged with agent identity headers. When a message causes a problem, you can trace exactly what the agent saw and when it acted.
Start at gated_send, move to monitored once you trust the agent's judgment, and eventually to autonomous. The oversight mode is a single config change — no code rewrites, no new infrastructure.
Whether you use an MCP client like Claude Desktop or call the REST API directly, you get the same 51 tools with the same behavior. You can prototype in an MCP client and deploy via REST without rewriting logic.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.