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.
One Streamable HTTP endpoint - https://mcp.letmesend.email - serves 35 tools across four areas:
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.emails-send, emails-list, emails-get) - send through verified domains, inspect past sends. domains-list, domains-verify, domain-health-check, domain-health-history, email-verification-check) - DNS verification, deliverability health and history, single-address validation.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).
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.
This is the flow from the OpenCode setup guide:
opencode mcp add
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.
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.
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.
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.
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.
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.