Consider a concrete task: triaging a support inbox. An assistant with mailbox access can search the mailbox, summarize the threads, and leave drafts waiting for review. No integration code, no API glue. Just a server URL and a sign-in.
That server is the new LetMeSend.Email MCP server, and this post is the practical walkthrough: what it exposes, how auth works, how to connect it, and the workflows I've found genuinely useful.
What the server exposes
One Streamable HTTP endpoint - https://mcp.letmesend.email - serves 35 tools across four areas:
-
Mailboxes (
mailboxes-list,mailbox-messages-search,mailbox-messages-thread,mailbox-messages-reply,mailbox-messages-action,mailbox-drafts-create, …) - read, search, thread, reply, forward, archive, and draft. -
Transactional email (
emails-send,emails-list,emails-get) - send through verified domains, inspect past sends. -
Domains (
domains-list,domains-verify,domain-health-check,domain-health-history,email-verification-check) - DNS verification, deliverability health and history, single-address validation. -
Marketing (
contacts-create,contacts-list,campaigns-create,campaigns-schedule,campaigns-send,campaigns-cancel) - contacts and full campaign lifecycle.
Every call runs under the same rules as the dashboard: the agent only sees mailboxes assigned to it, scoped to ability tiers (mailbox:read, mailbox:write, mailbox:send).
Authentication: OAuth first, API key for headless
The recommended path is OAuth - the client opens a browser sign-in where you log in with your LetMeSend.Email account and approve the mailbox abilities the agent gets. Nothing to copy into config files.
For headless setups (CI, servers, cron jobs), create a dashboard API key and send it as a Bearer token instead. Same tools, same guardrails, no browser involved.
Setup with OpenCode
This is the flow from the OpenCode setup guide:
opencode mcp add
# Choose remote, name it lmse, and enter https://mcp.letmesend.email
opencode mcp auth lmse
The auth command walks you through sign-in, including picking mailbox ability tiers. Then confirm the connection with a first prompt:
List my mailboxes using the LetMeSend.Email tools.
If it answers with your real mailboxes (that's mailboxes-list under the hood), you're connected. Prerequisites: a LetMeSend.Email account, and a verified domain before anything is allowed to send. The same pattern - remote URL plus OAuth or Bearer - applies to the other documented clients: Claude, Cursor, Copilot, Codex, Gemini, Warp, Zed, and more.
Workflow 1: Summarize threads, draft follow-ups
A useful bounded task for an agent:
Search the support mailbox for threads from the last two days, summarize each one, and draft a follow-up message for each - don't send anything.
The agent chains mailbox-messages-search → mailbox-messages-thread → mailbox-drafts-create. One permission note: searching and summarizing run fine on mailbox:read, but creating drafts requires write access - so this workflow needs the agent to hold both. Two things to know about that last step: mailbox-drafts-create saves a standalone draft (recipients, subject, body) - it takes no thread reference, so treat its output as a follow-up draft to review, not an in-thread reply. Actual in-thread replies go through mailbox-messages-reply, which sends immediately from the mailbox's primary address - only invoke that one with explicit approval. The boundary is structural: creating a draft and sending an email are different tools, so "don't send anything" means there's simply no send call in the chain.
Workflow 2: Check domain health in one question
Is example.com healthy? Check DNS, read the current deliverability score, and flag anything I should fix.
Behind that sentence: domains-verify for the DNS records, domain-health-get for the current score with findings and recommendations, domain-health-history for the trend. (domain-health-check triggers a fresh scan instead - it's rate-limited, so reach for it only when you need new data, not for routine reads.) What used to be several dashboard tabs and some DNS-tab archaeology becomes a single answer with a fix list.
Workflow 3: Prepare a campaign, review before it flies
Create a draft campaign for Friday's newsletter. Show me its audience and content for review. Don't schedule or send it.
campaigns-create stages the campaign and stops there. Note the deliberate omission: scheduling authorizes a future send, so it belongs after review, not before it. Once you've approved the draft, scheduling (campaigns-schedule) and sending (campaigns-send) are separate explicit steps. The pattern across all three workflows is the same: the agent does the assembly, you keep the trigger.
The draft/send boundary, stated plainly
Worth repeating because it's the whole safety model: draft creation does not send; sending tools deliver immediately, while scheduling authorizes a future send. Start new agents on mailbox:read - noting that read still permits organizing actions like archiving - and graduate to send access once you've seen the drafts it produces.
What's next, and where to start
On the roadmap (planned, not shipped): a short walkthrough video of the server end-to-end, and an n8n plugin for workflow automation. I'll update this post when they land.
Read announcement blog post to learn more about MCP server.
To try it now: create an account, verify a domain, point your agent at https://mcp.letmesend.email, and start with "list my mailboxes." Full reference lives at letmesend.email/docs/mcp/overview - and if you wire up a workflow I haven't thought of, I'd genuinely like to hear about it in the comments.
Top comments (1)
Mailbox MCP is powerful and risky in the same breath. Worth treating inbox tools as high-privilege: narrow scopes, clear permissions, and a result the operator can verify after each action.