A disposable address you click into, a REST API your test suite asserts on, and a clean tool surface for your AI agent. Same ingestion, same parsed message, same tenancy.
Every surface resolves the same address, writes through the same persistence path, and reads the same parsed message. What changes is who is holding it and how they authenticate.
“I need an email address for the next four minutes.”
“My test suite needs to assert on a real verification email.”
“Verify the signup flow works end to end.”
UC-1 is not a separate system — it is a dashboard front end over the ephemeral inbox UC-2 already provides. UC-3 is not a separate API — it is /v1 with agent-shaped ergonomics and tighter credentials. One ingestion path, one parser, one tenancy model.
One-off and manual by definition. Writing a test would cost more than doing it by hand — so the whole surface is tuned for the fifteen seconds between “I need an address” and “here is my code”.
One click generates a pronounceable local part on your project's namespace — brisk-otter-41@acme-staging.mailhulk.net — shown large, with a copy button and a QR code. Overwrite it with something typeable if you prefer.
10 minutes · 1 hour · 24 hours · 7 days, capped by your plan's retention. Add a note — “Figma trial” — so tomorrow's you knows what it was for.
The inbox view streams. “Waiting for mail…” becomes the message itself, with no refresh and no polling loop of your own.
The viewer shows sender, subject, time, rendered HTML, a text toggle, attachments, raw source — and the extracted links and codes with a copy button beside each one.
The address expires on its own and releases its inbox slot. Nothing to clean up, no cron job, no leftover state.
There is no anonymous public inbox. On a temp-mail site the address is the credential — anyone who guesses it reads your mail. Here a disposable address is readable only by members of its project, so there is no enumeration surface, no anonymous flood to rate-limit by IP, and abuse always has a team attached. It also means your teammates can pick up the same inbox.
Receive-only — no sending, replying, or forwarding to a real mailbox from a disposable address; a relay is an abuse surface. No aliases or routing rules. No reserved local parts such as postmaster@ or abuse@ — platform mail must not be interceptable.
The commercial core. A fresh inbox per test case, a blocking wait instead of a sleep, and content that arrives already parsed — because MIME handling in test code is where the brittleness used to live.
Create an inbox, trigger your app, block until the mail lands, assert on the parsed content, and let the TTL clean up after you — even if the test crashes before it can delete anything.
Cross-project access returns 404, never 403, so resource existence never leaks. Per-key rate limiting answers with 429 and a Retry-After you can actually back off against. And v1 is additive-only — the integration does not break under you.
Your coding agent already drives the browser and reads your repo. What it cannot do is receive email. That is the part MailHulk hands over — bounded, labelled, and safe to put in a model's context.
Not to draft a scenario, not to judge an email, not to explain a failure. This is a product boundary, not a phase. The agent in UC-3 is yours — MailHulk ships none of its own, and message content never enters an AI provider on our side. When your agent reads a body, that content enters your provider account under your agreement. There is no consent screen because there is nothing to consent to.
Today a human explores a flow by hand, then writes a script so CI can run it forever. In UC-3 the agent does the exploring and the writing; the human reviews the artifact.
No scenario authored in advance. The agent creates an inbox, drives the app, reads the mail, asserts, reports, and tears down.
The MCP server is configured once, with a project-scoped credential in the server's own environment. It is never in a prompt and never appears in a tool result.
The agent opens a session. Everything it creates is tagged to that session, and release_session frees all of it in one call.
create_inbox declares its side-effect class, so the harness can gate it. Idempotency is automatic — a transport retry cannot leave an orphan inbox.
wait_for_message returns {status: "pending", poll_token} at the cap rather than erroring. The agent never blocks a long tool call and never busy-loops.
The body arrives truncated to a token budget, with the full length and a part reference for explicit retrieval. A 2 MB marketing email cannot blow the context window.
Where the real leverage is. The agent's most valuable output is not a one-off passing check — it is a published, immutable scenario version.
The agent writes the flow it just performed as a schema-typed scenario definition: create inbox → trigger the endpoint → wait for mail → extract the code → verify → assert.
It calls validate, which returns structured errors with field paths and codes. The agent fixes and re-validates until clean.
It publishes an immutable version. The definition is hashed; the permissions it needs are derived at publish, not asserted by the author.
A human reviews the published JSON — a reviewable artifact, exactly as they would review a test PR.
CI runs that version from then on, with no agent and no model. Deterministic assertions own pass/fail; evidence is captured on every run.
The agent is now off the critical path. It was the author, not a runtime dependency — the only arrangement under which a model-driven QA workflow is safe to put in CI.
Each row is a way agent integrations actually fail.
An agent reading email is, by construction, feeding attacker-controlled text into a model. Anyone can send mail to a MailHulk address, so a message body is a direct injection channel — and MailHulk is the component that hands it over. So we enforce containment at the serialization boundary: every body, header set and payload is wrapped in an explicit untrusted-content envelope, and instruction-shaped framing is neutralized before it leaves MailHulk. Normal extraction still works — codes[0] is still 123456. This cannot make your agent safe on its own; your harness still has to gate mutations, which is why every tool declares its side-effect class. But MailHulk must not be the component that hands over live ammunition unlabelled.
Because the disposable inbox requires an account, it is not acquisition — it is the first useful thing you do after signing up, and the cheapest demonstration that capture works. Doing the task twice by hand suggests automating it the third time.
We publish this because a use-case page that quietly implies everything is finished is a use-case page you can't trust.