Your agent can fill any form.
Then the email arrives.

AI agents drive browsers, call APIs, and write whole test suites — and then a signup flow says “we've sent you a verification code” and the run is over, because the email went somewhere no agent can reach. This guide is about removing that wall: what people try first, and what it looks like when the agent simply has an inbox of its own.

Where agent runs die today

Email verification is deliberately a wall — it exists to prove there's a real mailbox behind a form. Agents hit it constantly: exploratory QA on a signup flow, an end-to-end check after a deploy, authoring a regression test that needs one real pass to be trustworthy. The workarounds all reintroduce the thing the agent was supposed to remove:

• A human pastes the code. The agent stops, someone alt-tabs to a mailbox, reads a six-digit number, types it into the chat. The autonomous run now has a person in the middle of it — and isn't autonomous, repeatable, or schedulable.
• The agent screen-scrapes a webmail UI. Now a language model holds credentials to a real mailbox, drives a UI built to resist automation, and breaks whenever the provider A/B-tests a layout. Everything in that mailbox — not just the OTP — is in the agent's reach.
• IMAP against a shared test account. Parallel runs collide in one mailbox, yesterday's verification email matches today's search, and an IMAP password sits in the agent's environment. This is the same shared-mutable-state flake that kills OTP tests in CI, wearing an agent costume.

The shape of the fix: the inbox is a tool

MCP — the Model Context Protocol — is how agents get capabilities: a client like Claude Code connects to a server, and the server's tools become things the agent can just do. mailfixture is a remote MCP server, so “receive email” becomes a tool call. The agent mints a fresh address for the run, uses it in the form it's testing, and then waits on the inbox the same way your test suite does — server-side, no polling loop, no sleeps:

> verify the signup flow on staging works end to end

create_inbox(ttl_seconds=900)
  → q7v3n0x2k9@mxsink.sh
… agent fills the signup form with that address …
wait_for_otp(inbox_id=…, timeout_seconds=45)
  → { best: "482913" }   # held open until the email lands
… agent types the code, asserts the account is live …
delete_inbox(inbox_id=…)   ✓ teardown

Three details carry the weight here. The address is real — a live MX-routed domain, so it works against staging, production, or anything else that can send mail; nothing in the app under test is mocked or rewired. The wait is a single tool call — wait_for_otp, wait_for_link, and wait_for_message long-poll on the server and return the extracted result, so the agent never writes a retry loop or parses an email body with a regex. And every run is isolated — a fresh inbox per attempt, with a TTL so abandoned runs clean up after themselves.

Setup is one command per the MCP quickstart; the agent authenticates with a normal API key you can revoke any time.

MCP or the SDK? Both — at different moments

The MCP tools are for work the agent does with its own hands: exploratory QA, a one-off “does signup still work?” check, reproducing a bug report that involves an email. The SDKs are for the tests the agent leaves behind: when the job is “add a regression test for the OTP flow,” a good agent writes a Playwright or pytest test against the SDK — code your CI runs forever — and can use its own MCP tools while authoring to confirm the flow actually behaves the way the test assumes. Same inboxes, same extraction, same long-poll semantics; the only question is whether the caller is a model or your test runner.

The boundary, stated plainly

All of this assumes the flow being verified is your own product's. Our terms draw the same line for agents as for test suites: registering accounts on services you don't control is prohibited; testing what you own is the point. An agent that mass-registers accounts around the web with programmatic inboxes is the abuse case we design against — and the account-and-key attribution behind every inbox means it isn't an anonymous one.