Make Your AI Agent Receive Email

By Denis · Published 2026-09-11.

Most agent workflows hit the same wall: the agent can fill in a signup form, but the verification code lands in an inbox only you can read. So you end up as the human middleware, watching your own inbox, copying six digits, pasting them back into the chat. There is a cleaner split: give the agent an inbox of its own, one it can read but never abuse. Tempx ships exactly that as a scoped MCP server, and this guide wires it up end to end.

What you will end up with

Your agent gets eight tools, list_inboxes, get_inbox, list_emails, get_email, search_emails and wait_for_email for reading, plus send_email and create_smtp_credential when you grant the optional send permission, scoped to one disposable inbox. It can watch for a code, read the message, and hand you the link. With the default permissions it cannot send anything; if you grant send, composed mail is captured in the same inbox for testing (sandbox SMTP style) and never delivered, and it still cannot delete anything, touch your other inboxes, or spend a cent. If you are new to why an agent should have an inbox at all, start with Give Your Email to Your AI Agent; this article is the hands-on version.

Step 1. Create the inbox

Open the Tempx mail app and generate an address. No signup, no password, the inbox exists the moment you load the page. This is the address your agent will use for signups from now on. Send it a test email if you want to watch messages arrive in real time.

Step 2. Keep it (claim it to an account)

A raw inbox lives in your browser and expires with it. Press Keep this inbox and sign in with Google: the inbox is claimed to your account, survives across devices, and becomes something you can grant API access to. Claiming is one click and needs no password, the Google flow is enough.

Step 3. Create an MCP connection

On your account page, scroll to MCP Connections and create one for the inbox you kept. Two things happen: you pick a scope and expiry, and the server mints a token like tmcp_…. The token is shown exactly once, only a hash of it is stored server-side, so a screenshot now saves regret later. Each connection is limited to a single inbox, so a token for your agent's inbox can never read your personal one.

Step 4. Point your client at it

Tempx speaks MCP over streamable HTTP with Bearer auth, which every current client understands. Drop this into your client's MCP config, replacing the placeholder with your token:

{
 "mcpServers": {
 "tempx": {
 "url": "https://tempx.uk/mcp",
 "headers": { "Authorization": "Bearer tmcp_YOUR_TOKEN_HERE" }
 }
 }
}

Reload the client and the tempx tools appear next to your others. That is the entire installation.

Step 5. Let the agent wait for mail

The tool that changes workflows is wait_for_email: it long-polls server-side and returns the moment a matching message arrives, instead of spamming refresh. Try a prompt like:

Sign up on example.com using the tempx inbox, then call wait_for_email for a message from example.com and read me the verification code.

The agent fills the form, waits, reads the code, and continues, no human in the loop. You can narrow the wait with from_contains or subject_contains, and set timeout_seconds (5–175) so a missing email fails fast instead of hanging.

What the agent can and cannot do

• Can: list its inbox, read messages and attachments, search by sender or subject, and wait for new mail.
• Cannot: send or reply, delete or edit anything, see any other inbox, or create tokens. There is no write path to abuse.
• Always: rate-limited per token, expiring on the schedule you chose, revocable in one click from the account page.

Keeping it tidy

Treat the connection like the inbox itself: disposable. Give a short-lived token to a one-off automation, revoke it when the task is done, and mint a fresh one next time. Verification mail is exactly the kind of message that should die young, the inbox auto-deletes on its retention schedule, and the token's hash dies with the connection.

Wiring patterns for non-Claude clients

The pairing flow is the premium path, but the token path makes the same server reachable from anything that can send an HTTP header. The static-header configuration works for custom agents, CI scripts, and hobby automations alike: POST https://tempx.uk/mcp, JSON-RPC 2.0, Authorization: Bearer tmcp_…. Because the protocol is stateless (every request carries its own authorization) clients can be scripts that start and exit, serverless functions, or a cron job with curl; nothing holds a session open.

For teams that already standardize on OpenAI-compatible tool calling, a thin shim is a day's work: expose the eight MCP tools as function definitions, forward calls as JSON-RPC, return the structured results. The tool surface is deliberately small and stable (list, get, search, wait, plus the two send-permission tools) which is what makes shims cheap to maintain.

Waiting, timing, and the polite poll

The tool that changes agent architecture is wait_for_email: a server-side block for 5 to 175 seconds, filtered by sender or subject, returning the instant a match lands. Agents built on it spend their idle time free, no sleep-retry loops, no token burn on empty checks, no rate-limit pressure from anxious polling. The design constraint to respect: one wait at a time per inbox, and a timeout ceiling of under three minutes, which covers real delivery variance comfortably.

For workflows that watch longer than one wait window (a standing automation waiting for a rare mail) chain waits (each up to the ceiling) rather than inventing client-side polling, and key actions on message id for exactly-once behavior across the chain. The same discipline that makes the single wait cheap makes the long watch reliable.

Revocation, expiry, and the tidy end-state

Every agent grant should end, and the product is built so endings are automatic. Inboxes age out on their retention clock; connections carry their own expiry chosen at creation; tokens revoke in one click from the account page, effective at once. An automation you abandoned last month should have left nothing but its own logs behind, verify that once and you trust the default forever.

The audit that keeps the setup honest is a one-liner: list active connections, confirm each maps to a live purpose, kill the rest. The failure mode worth guarding against is not the revoked credential but the forgotten one, an integration that still reads an inbox nobody remembers granting. Scoped-to-one-inbox design caps the damage any single forgotten grant can do, which is the quiet reason the scope exists at all.

A note on idempotency keys

Every pattern above eventually whispers the same implementation detail: key your actions on the message id, not on arrival. Waits can chain, retries can re-read, and a watcher restarted mid-message will see the same mail twice, the id is the only coordinate that stays stable across all of those. One deduplication set (a table, a cache, even a log with a grep) keyed on id converts "at least once" delivery into "effectively exactly once" actions, and it is the difference between an automation that reacts and one that double-reacts.

The same key disciplines your assertions in tests: expected message ids per scenario make "the code I extracted belongs to this run" a lookup rather than a hope. Small habit, disproportionate share of the reliability.

Give your agent an inbox

Inbox, account, token, working agent, about five minutes, all free.

Create an inbox