# I Connected My AI Agent to My Inbox with MCP - Here's How It Works > Source: > Published: 2026-09-18 21:47:20+00:00 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.