Email for Codex.
A TOML block in Codex's config and the 54 Drin tools join its toolbox — useful in an interactive session, sharper in a script that triages mail while you review diffs.
Free sandbox to integrate · Production from $3/month
One block, then ask.
Codex reads MCP servers from its config.toml. Add the block with a scoped key and the next session exposes the full Drin surface as tools.
Full setup guide →[mcp_servers.drin] command = "npx" args = ["-y", "@drin00/mcp"] [mcp_servers.drin.env] DRIN_API_KEY = "drin_k_…" # next codex session lists the drin tools.
Paste one of these first.
Three real tasks, end to end — copy a prompt and watch it run the tools.
With the drin tools: create an inbox support@mydomain.com and a webhook to https://myapp.com/inbound, simulate one inbound email, and print the parsed payload.
Send a test email from hello@mydomain.com to my address with subject "Codex wired up", wait for the delivery event, and report the trail.
Draft a campaign to the NEWS topic announcing the release and route it for approval — stop there; a human reply launches it.
Asked about Codex.
Where does the config live?+
~/.codex/config.toml — the [mcp_servers.drin] table plus its env sub-table. Codex picks it up on the next run; no flags needed.
Will Codex's own approval prompts get in the way?+
They compose. Codex asks before running tools in its safer modes; Drin's approve-by-reply guards the blast itself. Routine sends run clean once you allow the tools.
Can I use this headless, in CI?+
Yes — and for pure scripting the Drin CLI is often simpler: drin send, drin threads list, exit codes and JSON output. The MCP route shines when Codex is reasoning about what to send.
What key should I give it?+
A scoped key from the dashboard — sandbox while you wire it up, production when the flow is proven. Rotate or revoke from the dashboard at any time.