Choosing the tool
Out of several MCP servers for email I picked mcp-server-email — written in Go, works over IMAP/SMTP, open source. The deciding argument: you can spell out the mail server's host and port explicitly, instead of only picking "Gmail/Outlook/Yahoo" from a list. For company mail that lives on your own hosting rather than in Google Workspace, that is the only option that does not need workarounds.
Installing it
No building from source — the releases page already carries a ready binary for Windows. I downloaded the archive, checked the checksum (literally one command, but it is the one that separates "installed it" from "installed it and let a trojan in wearing a tool's clothing") and unpacked it. There was no need to install the whole Go toolchain, just the executable.
After that: a config file with the mail account details in JSON, and registering the server in the Claude Code settings (an ordinary entry in the MCP server config, where the command is the path to the exe). Then the application itself has to be restarted — the server's tool list is only picked up at start-up, never on the fly.
Connection details: check DNS instead of guessing
The most common mistake at this step is trying to guess the mail server's name or hunting for it in the hosting panel. The shorter route: the domain's MX record tells you straight away which platform handles the mail, and that platform's own IMAP/SMTP hosts usually sit on predictable subdomains. While you are at it, test the ports with a plain TCP connection rather than trusting the documentation — 993 and 587 were open for me and 25 was closed, which immediately settled which TLS mode to use.
One security moment stood out. The script that was meant to fetch the mailbox password (from an already configured mail client of another system) and write it into the config was stopped by Claude Code's own safety mechanism: writing a password into a file autonomously counted as too sensitive an action. Fair enough — the password ended up being typed in by a human rather than a script. A neat illustration that guard-rails like that are not a bug, but exactly what they exist for.
The first test — a live handshake, not the documentation
Before trusting a tool, it is worth making sure it genuinely works rather than merely starts. I sent the MCP handshake by hand (initialize → tools/list) straight over stdio, with no client in between — the server answered correctly and returned exactly 22 tools, as advertised: folder listing, reading, search, sending, replies, forwarding, drafts, batch operations. Then a real call with real credentials: the IMAP connection went through and the server returned the actual structure of the mailbox.
That structure was a surprise: hundreds of separate folders of the form Archives.<sender> — the mail panel, it turned out, files every new sender into a personal folder of their own. Tidy, but as it emerged later, that mechanism has an unpleasant side effect.
What it found on day one
Among dozens of messages in the SPAM folder — solid cold outreach from SEO agencies and advertising outfits — the agent pulled out one that was there by mistake: a reply to a job advert, with a portfolio on a personal site. Nothing malicious, ordinary correspondence, simply lost among the spam and quite possibly left unopened for another week. One command and the message was back in the inbox. That is precisely what made the experiment worth running: not a "clever chatbot", but a tool that genuinely saves your attention.
Round two: "why is spam still coming through?"
A day later came the feedback: the spam keeps arriving regardless. Digging in showed the spam filter itself was not at fault — it worked as intended, and fresh messages did land in SPAM. The problem was that automatic filing into Archives.* folders: it intercepted mail before the spam filter and tucked even blatant spam into personal folders, including a campaign selling fake Google reviews from a fresh throwaway domain for every message.
At this point the MCP server was out of the picture — it does not touch the mail server's filters, only the messages themselves. I had to go into the mail web panel directly and find the real blocking mechanism. It turned up in two places: an ordinary Sieve filter (move on the condition "sender contains domain") and, more importantly, a built-in blacklist that rejects at delivery — mail from domains listed there never reaches the mailbox at all. I added several domains that had been re-sending the same letter every two to four weeks; the front-runner sent seven messages in three weeks, each under a different pretext.
What I took away from the experiment
- MCP servers for email are not just a "reader". The full set of operations is there: reading, sending, moving, flagging, drafts. If a tool looks like it "can only look", chances are nobody got round to trying the rest of its functions.
- Real connection details are found, not guessed. DNS and a plain TCP connection are more reliable than any hosting documentation.
- An existing platform often already has the mechanism you need. Before writing your own filter, check whether a built-in panel feature solves it — here it did.
- Guard-rails around passwords and system settings are protection, not an obstacle. The moment the automation refused to write sensitive data into a config file by itself was not a bug, but exactly the behaviour you want from a tool with access to real infrastructure.
If you want the same for your own mail — without working through MCP servers and Sieve filters yourself, and with a configured result handed over ready — the studio offers it as a service: an AI agent for your company inbox.
