Introduction
After setting up my OpenClaw briefings, the next step was email.
I wanted to forward newsletters to the agent so the morning and evening summaries would include the sources I actually read, not just public feeds.
On paper this sounded simple. In practice it became a sequence of wrong assumptions, useful dead ends, and one solution that finally worked.
Why I Did Not Use Regular Email Providers
My first step was checking common providers like Gmail and similar options.
The more I looked into it, the less I liked the risk profile for this use case. Some providers are strict about automated agent-style access, and I did not want to build this on top of behavior that could violate terms or get an account restricted later.
That pushed me to look for an email provider built specifically for agent workflows.
Choosing Agentmail
I ended up choosing Agentmail.
Creating the mailbox, generating the API key, and getting the basic account setup done was straightforward. No real friction there.
The real issue appeared right after that.
The IMAP Rabbit Hole
I expected to connect through IMAP and started wiring things up that way.
I was using Himalaya on my EC2 instance to give the agent access to the mailbox. The UI showed existing emails (17 messages), but my client could not fetch them.
At that point I assumed I had a configuration bug, so I did the usual debugging cycle:
- Rechecked credentials and host settings
- Retried with different client configs
- Tested directly on the EC2 instance with an IMAP client
- Compared what the UI showed versus what the client returned
I spent about three hours on this before reaching out.
What Broke: IMAP Not Supported (Yet)
I contacted the Agentmail team on Discord.
They confirmed that IMAP was not supported yet (but will be soon). The founder also got back to me on discord and said they will work on a CLI version this weekend and that there is a MCP version available.
That explained everything and also ended the debugging loop immediately. It was frustrating, but at least the failure mode was now clear.
Attempt Two: MCP via Mcporter
After that, I looked for alternatives and found that Agent Mail offers an MCP service.
I remembered Mcporter by Peter Steinberger, which can bridge MCP capabilities into CLI tools. That looked like a good path for my setup, so I tried to get it running (with help from Claude for faster iteration).
I got close, but hit a dependency mismatch between the Agent Mail MCP service and Mcporter.
At that point, continuing to force the integration did not look like the fastest path.
Final Approach: Build a Small CLI Wrapper
So I switched strategy and built my own CLI wrapper around the Agentmail SDK.
This ended up being the cleanest option for my workflow. It was quick to build, easy to reason about, and gave me direct control over how mailbox data is fetched and passed into the briefing pipeline.
I also published it as:
- An npm package: agentmail-cli on GitHub
- A skill on Claw Hub: agentmail-mcp-cli on ClawHub
That way the integration is reusable and not locked into one local setup.
What I Learned
The biggest lesson was simple: validate protocol assumptions early.
If I had confirmed IMAP support first, I would have skipped hours of unnecessary debugging.
The second lesson is that when an integration path gets blocked by dependency conflicts, a small purpose-built wrapper can be faster and more reliable than trying to force compatibility layers.
For this project, that tradeoff was worth it.