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 (0)