I Connected My AI Agent to My Inbox with MCP - Here's How It Works

LetMeSend.Email launched an MCP server at mcp.letmesend.email that exposes 35 tools for mailbox management, email sending, domain health, and campaign handling to AI agents. The server supports OAuth browser sign-in or Bearer token authentication for headless setups, with agents scoped to assigned mailboxes and ability tiers like mailbox:read, mailbox:write, and mailbox:send. A developer walkthrough shows agents chaining tools such as mailbox-messages-search and mailbox-drafts-create to triage support inboxes without integration code.

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 https://letmesend.email/docs/mcp/overview , 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 https://letmesend.email/docs/mcp/overview : 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. 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 https://letmesend.email/blog/introducing-the-letmesend-email-mcp-server-give-your-ai-agents-the-power-to-send-email 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 https://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.