DEV Community: Francisco Perez

The App That Remembers Your Doctor's Appointment and Forgets Your Name

Francisco Perez — Wed, 30 Sep 2026 16:41:44 +0000

If you're hunting for a business idea, listen: this one could be worth as much as ten million dollars a year. The good news for you is that almost every app chasing it is built around the same blind spot.

Is this a real business, or is it smoke? Let's find out.

I'm Onald Grump. I tear apart business ideas, one a week. This week I went through thirteen research pages, six Reddit communities, and a keyword growing 12,000%, so you don't have to. Here's the plan: I'll show you what the product does, who pays, and how much. Then I'll show you the one part the pitch would rather you skipped.

Meet Daniel

His father, Ray, tells the same story every visit: his first job, a bakery, four in the morning, flour up to the elbows.

Daniel records some of it. Voice memos named New Recording 12, New Recording 13. Then the phone gets replaced, and the memos are somewhere Daniel can no longer find.

Daniel's plan was to sort them this weekend. Daniel has been sorting them this weekend for a very long time.

The recordings exist. The love exists. The folder does not.

Why now

Dementia care apps are projected to grow 13–16.5% a year, and the U.S. market alone goes from $1.5B to $4.2B by 2033. Those are the research's own figures, not mine, so treat them as estimates.

Look at what exists. Apps like CareZone track medications, appointments, and symptoms. Then they stop. Who the person is, their stories, their voice — all of that lives outside the care stack. Very few tools even try to combine daily orientation, comfort, and story capture.

And people are already searching next door. "FamilySearch family tree": 165,000 searches a month, up 12,592%. "Search family history": 33,000, up 4,497%. Those are genealogy searches, not dementia searches, so call it adjacent demand. My own theory: "clean up iPhone storage," up 410%. The phone is full, and the stories are in there.

And this is what gets me: these apps know a medication schedule down to the minute. They know Tuesday's appointment. They do not know what he called the street he grew up on. Every one of these products remembers the appointment and forgets the person.

The product

It's called Keepsong. That's the name on the front page of the research, though the sub-pages call it Memory Keeper — I'm going with Keepsong.

Every morning, a check-in shows the date, the weather, and photos of family with their names and how they're connected. Then a prompt — tell me about your wedding — and the answer is a voice recording. Those recordings sort themselves into a family timeline by decade and topic. The adult kids end up with a growing library of a parent's voice and life.

Version one is an iPhone app with voice recording and photo upload, and 20 beta families to learn which prompts get the richest answers. Two screens: one for the person living with memory loss, one for the family member who sets everything up. That split is the core design problem, by the research's own admission — we'll come back to that.

The bigger swings come later: printed memoir books made from the recordings, and voice cloning, so late in the illness a family could still hear a parent speak. I have thoughts on that one. Also later.

Who pays

Adult children, roughly 35–60, juggling a job and a parent. Not the person with dementia — the person who is afraid of losing the recordings.

Do they exist? Reddit's r/Genealogy has 201,000 members. r/Ancestry, 25,000. r/cogsci, 108,000. And r/Alzheimers — the community that actually lives this? 5,000. The hobbyists are huge. The people with the problem are small, or somewhere else. The research also lists caregiver Facebook groups, sizes unknown.

The research projects a customer acquisition cost of $15–25 and churn under 5%. Those are projections. And under 5% is doing a lot of work.

The money

Now the money. A free trial to get you in. $9.99/month for basic: daily orientation, prompts, simple recording. $19.99 for the enhanced tier, with personalized prompts and more storage. $29.99/month for the family collaboration hub.

And the backend: a $5,000 annual license for memory care centers. My math, not theirs: one license is about 42 basic subscribers paying for a full year. That's the real B2B door.

The research puts the revenue potential at $1–10 million a year. That's an estimate, not a promise. I have seen many estimates make that same confident face.

The catch

The competitor named in the research is CareZone, and it doesn't do this. The bigger threat is the established elder-care apps that can bolt on a story feature quickly. And next door sit FamilySearch, Ancestry, and MyHeritage, who already own the family-story audience. Nobody here is empty. They just haven't looked over.

The value equation scores this a 6/10. Dream outcome: 8. Likelihood: 6. Time delay: 6. Effort: 5. Effort is the number to stare at.

Here's the thing I said we'd come back to: the person on the memory-loss side has to open this every morning, on their own, and the whole app depends on it being simple enough to use alone. The research lists older-user engagement as a risk. That's the entire business in one sentence.

And the material is medical and deeply personal. Encryption from day one, the research says, and it should. Add voice cloning of a parent and the question isn't can you build it. It's who agreed, and to what. That's not a feature question. That's a trust question, and trust is the product.

The scorecard

Problem — 9 Willingness to pay — 6 Ease to build — 6 Ease to get customers — 7 Competition — 7 Solo-founder fit — 5

Feasibility is a 6/10, and the research wants a technical founder with a $10–50K budget.

Verdict: Business

$9.99 a month to keep a voice. But only if it opens on its own, and a family can trust it with a parent's story.

—

Every week I tear apart one business idea like this — the research, the numbers, the part the pitch would rather you skipped. If this one was useful, the full breakdown (with all the receipts) is on YouTube: https://youtu.be/yTyAqjbZ4OA

Address Space Exhaustion in Production

Francisco Perez — Mon, 28 Sep 2026 14:55:16 +0000

I went looking for why none of our registered users were using the product. I found something worse: for most of them, the product had simply stopped working. Address space exhaustion had been quietly breaking mailbox creation for weeks, and not one of our monitoring tools said so. One of them actively told us the opposite.

This is the writeup of that outage. The bug itself is almost embarrassingly simple — a combinatorial space that filled up because nothing ever left it. The interesting part is the twenty minutes I spent believing my instruments over my arithmetic, and what that says about how these failures hide.

A generator with 36,000 possible outputs

We hand out disposable email addresses. They're meant to be readable and quotable over a phone call, so they aren't random hashes — they're adjective-noun-NN@domain. The generator was about as simple as it looks:

_ADJECTIVES = ["mango", "coral", "verde", "plata", ...]  # 20 entries
_NOUNS       = ["panda", "tigre", "koala", "llama", ...]  # 20 entries

def generate_friendly_address(domain: str) -> str:
    """
    Genera una direccion amigable del tipo 'mango-panda-42@dominio.com'.    Hay 20x20x90 = 36 000 combinaciones posibles.
    Si hay colision en DB, el router reintenta (max 5 veces).
    """
    adjective = random.choice(_ADJECTIVES)
    noun = random.choice(_NOUNS)
    number = random.randint(10, 99)
    return f"{adjective}-{noun}-{number}@{domain}"```
{% endraw %}
Note the docstring. Past me did the multiplication correctly — 20 x 20 x 90 = 36,000 — wrote it down, and shipped it anyway. The number was never hidden. It was sitting in the source, in Spanish, three lines above the code that would eventually take the service down.

The creation endpoint handled collisions the obvious way: generate a candidate, check whether it exists, and if it does, try again up to five times.
{% raw %}


```python
for attempt in range(_MAX_ADDRESS_RETRIES):   # 5
    address = generate_friendly_address(settings.domain)
    existing = await db.execute(
        select(Mailbox.id).where(Mailbox.address == address)
    )
    if existing.scalar_one_or_none() is None:
        # ... insert and break
        break

if mailbox is None:
    raise HTTPException(status_code=503, detail="No se pudo generar una direccion unica.")

Five attempts is plenty when the space is 5% full. It is not plenty at 93%.

Why address space exhaustion is invisible until it isn't

Here is the shape of this class of bug, and why it gives you no warning.

The probability that a single request fails is the probability that all five candidates collide: occupancy^5. At 50% occupancy that's 3%. At 80%, still only 33%. At 90% it's 59%. At 93.3% — where we actually were, with 33,590 of 36,000 addresses taken — it's:

0.933^5 = 0.707  ->  ~70% of requests should fail

That curve is the whole story. For months the failure rate is a rounding error, then it goes vertical. There is no gentle degradation to alert on, no slow climb anyone notices in a weekly review. The system is fine, fine, fine, and then it is 70% broken.

And when I measured it live against production — just firing ten requests at the endpoint — nine of ten came back 503.

Lie #1: the analytics said 18 errors

Our frontend emits a funnel_error event when a step fails. Querying it for the whole history returned 18 errors of this type, spread over six weeks. Eighteen is a number you look at and move on from. Eighteen is noise.

The API had returned hundreds of 503s over the same period.

The gap wasn't a bug in the event pipeline. It was that funnel_error only fires on certain frontend paths — the ones where a component was wired to report it. Anything that failed outside those paths (API clients, the MCP server, the retry that happened before the component mounted) failed silently as far as analytics was concerned.

This is the lesson I'd generalize: product analytics measures what you instrumented, which is a subset of what your users did, which is a subset of what your system did. It is a fine tool for asking "did people click this?" It is not a health signal, and the moment you treat it as one you've built a monitor whose blind spots exactly match the code paths nobody thought about.

Lie #2: the container logs said 4%

Analytics undercounting is at least an honest kind of wrong — it never claimed to be complete. The second tool was worse, because it gave me a confident, specific, wrong answer.

I pulled the request log out of the container and counted status codes:

docker logs uct_app --tail 100000 2>&1 | grep "POST /api/v1/mailboxes" \
  | grep -oE "(503|201)" | sort | uniq -c

13451 201
  314 503

A 2.3% failure rate. I narrowed to the most recent requests — last 3000, last 1000, last 200 — and got 3.7%, 4.7%, 4%. Consistent, plausible, and completely wrong. The real rate at that moment was around 90%.

What happened is that --tail N did not return the actual tail. With log rotation in play, the window I was slicing wasn't the window I thought I was slicing, so the lines I was confidently calling "the last 200 requests" were nothing of the sort.

I want to be precise about the failure mode here, because "logs lied" is too glib. The log file wasn't corrupt. Every line in it was true. The command returned a real slice of real data — it just wasn't the slice I asked for, and nothing in the output said so. A tool that returns plausible wrong data with no error is far more dangerous than one that fails loudly.

Trusting the instrument over the arithmetic

Here's the part I got wrong, and it cost me most of the debugging time.

I had two sources. One was a simulation: I pulled every occupied address out of the database, generated 20,000 candidate addresses using the exact production generator, and applied the exact five-retry logic.

ocupadas en DB: 33590
espacio total : 36000
libres        : 2410
fallo simulado: 70.4% de 20000 peticiones (5 reintentos)

The other was the log, saying 4%.

These cannot both be true, and I spent a long stretch assuming the simulation was the thing that must be wrong. I re-checked the word lists. I diffed the deployed generator against my local copy in case the container was running older code. I checked whether multiple domains were splitting the namespace. I verified the enum of every adjective and noun actually present in the database. All of it came back confirming the model: 36,000 slots, 33,590 taken, 2,410 free.

I was interrogating the calculation because the calculation was the thing I could inspect. The log was just... output. It felt like data in a way the model didn't.

That instinct was backwards. The arithmetic was four lines long and independently verifiable. The log was the output of a distributed system, a container runtime, a rotation policy, and a CLI flag whose semantics I had never actually read. The simple, checkable thing was the trustworthy one. When a model and a measurement disagree, "which of these has more moving parts I haven't verified?" is a better question than "which of these feels more like a fact?"

What finally settled it was refusing to arbitrate between the two and going to get a third source: ten real HTTP requests against production. Nine failed. The model had been right the whole time.

The root cause: nothing was ever released

Filling 93% of a 36,000-address space requires either enormous traffic or a leak. It was a leak.

Mailboxes are disposable. They expire — most within an hour. A background loop handled expiry like this:

async def _expire_mailboxes() -> int:
    """Marca is_active=False en buzones expirados."""
    now = datetime.now(timezone.utc)
    async with AsyncSessionLocal() as db:
        result = await db.execute(
            update(Mailbox)
            .where(Mailbox.expires_at <= now, Mailbox.is_active == True)
            .values(is_active=False)
        )
        await db.commit()
        return result.rowcount

It marks. It never deletes.

Meanwhile the uniqueness check in the creation path was:

select(Mailbox.id).where(Mailbox.address == address)

No is_active filter — and correctly so, because an address that was used an hour ago shouldn't be reissued to a different person while mail might still arrive for it. But the consequence is that an address is consumed permanently the first time it's handed out. Expiry freed the mailbox. It never freed the name.

The numbers made this vivid once I looked: of 33,590 mailboxes in the table, 5 were alive. The other 33,585 were expired, inert, and still holding their address hostage. The oldest had expired on March 2nd — six months earlier.

There was also a human cost sitting in the data. One user registered, tried to create a mailbox 38 seconds later, got a 503, tried again with a different TTL, got another 503, and never came back. That's the entire lifetime of that account: sign up, hit a wall twice, leave.

The fix

Three changes, in order of how much they matter:

Purge expired mailboxes. This is the actual fix; everything else buys time. A retention window — 72 hours, long enough that a user who wanders back can still read their mail — after which the row is deleted and the address returns to the pool.

MAILBOX_RETENTION_HOURS = int(os.getenv("MAILBOX_RETENTION_HOURS", "72"))

async def _purge_expired_mailboxes() -> int:
    cutoff = datetime.now(timezone.utc) - timedelta(hours=MAILBOX_RETENTION_HOURS)
    async with AsyncSessionLocal() as db:
        result = await db.execute(
            delete(Mailbox).where(
                Mailbox.is_active == False,
                Mailbox.expires_at < cutoff,
            )
        )
        await db.commit()
        return result.rowcount

Widen the space. The numeric suffix went from two digits to four: 20 x 20 x 9,000 = 3,600,000 combinations, a 100x increase for a one-line change and no loss of readability (suave-delfin-1608 reads exactly as well as suave-delfin-16).

Raise the retry ceiling from 5 to 10. Cheap insurance that does nothing on its own — at 93% occupancy, ten retries still fails half the time. Widening the space without purging would have bought about ten days at our traffic. Purging without widening would have worked, but with no headroom for a traffic spike. Both together give a steady state around 10,000 occupied addresses: 0.3% of the new space.

We also ran a one-off purge of the backlog: 33,596 mailboxes deleted, cascading to 12,982 messages, all of them long expired. Occupancy went from 93.3% to 0.005%, and a burst of 30 creation requests came back 30 for 30.

Address space exhaustion is not an email problem

Any system that hands out human-readable identifiers from a finite pool has this bug latent in it. Invite codes. URL slugs. Short links. Room codes for a video call. Coupon codes. Anything where somebody chose a format because it reads well, computed the combination count once, and wrote it in a comment.

Three things make it dangerous:

The failure curve is a cliff, not a slope. With k retries, the failure rate is occupancy^k, which is negligible right up until it isn't. There's no gradual signal to alert on.
The pool usually leaks. Soft-deletes, tombstones, audit requirements, and "we might need it later" all mean identifiers get retired without being released. Check whether your uniqueness constraint and your lifecycle agree about when an ID is free — ours disagreed for six months.
Generic error codes hide it. A 503 from an exhausted namespace looks identical to a 503 from a database hiccup. Ours said "No se pudo generar una direccion unica" in the response body and nobody was reading response bodies.

If you have such a pool, two things are worth doing this week: compute your current occupancy as a percentage, and confirm that something actually deletes retired identifiers. Both are ten-minute queries. Ours would have caught this in March.

What I'd take away

The bug was trivial and the arithmetic was in a docstring from day one. What made it an outage was that every instrument pointed away from it — analytics because it only measured instrumented paths, container logs because a flag didn't mean what I assumed, and my own judgment because I trusted output that looked like data over a calculation I could verify in four lines.

The habit I'm keeping from this one is cheap: when two sources disagree, don't arbitrate between them. Go get a third that touches the real system. Ten curl requests settled in thirty seconds what I'd spent twenty minutes reasoning about, and they'd have settled it on day one just as well.

If you want to see what the service actually does when it isn't returning 503s, it's at uncorreotemporal.com.

Email Verification Bots with Playwright

Francisco Perez — Thu, 16 Jul 2026 04:00:54 +0000

If you've ever tried to test your own signup flow, provision a demo account, or sign up for a vendor's API on behalf of your one-person company, you've hit the same wall every solo founder hits: the form submits fine, and then the service says "check your email to verify your account." Now a human has to open an inbox, find the code or the link, and come back to finish the job. That single step is why so many "fully automated" onboarding tests still have a person babysitting them.

You don't need to be an engineer to fix this. This guide shows how to build a registration bot with Claude Code — the AI coding agent — where Playwright handles the browser and email verification is solved by a temporary inbox the bot owns. You describe what you want in plain English; Claude Code writes and runs the Playwright automation and the email lookups for you. No prior coding experience required, no manual "please check your inbox" step left in the loop.

Why email verification breaks no-code registration bots

Most no-code and low-code automation tools are genuinely good at the mechanical parts of signing up for something: filling a name field, generating a password, clicking submit. Where they consistently fall apart is the moment the target service says "we sent you an email."

Three things go wrong when solo founders try to work around this without dedicated infrastructure:

Your personal inbox becomes the bottleneck. If the bot uses your real email address, you have to manually forward or copy the OTP every single time. That's not automation — that's you, with extra steps.

Shared or reused addresses get flagged. Many signup forms silently reject addresses that look reused, disposable, or machine-generated. If your bot reuses test@yourdomain.com for every run, some services will start bouncing it after a few signups.

Reading a real inbox by code is a project of its own. Wiring up Gmail or Outlook programmatically means OAuth, token refresh, and app permissions — a serious side quest if all you wanted was to test a signup form.

The fix that professional QA teams use is the same one that works for a solo founder with no engineering background: give the bot a fresh, disposable inbox for every run, one it can create and read on its own. That's what turns "check your email" from a manual step into something Claude Code can just... do.

How Claude Code drives Playwright for email verification

Here's the mental model, without any code required on your end.

Playwright is the browser automation engine. It's what actually opens a Chromium browser, navigates to the signup page, types into form fields, and clicks buttons — the same way a human would, just faster and unattended. You never touch Playwright directly; you describe the task, and Claude Code writes and runs the Playwright script behind the scenes.

The temporary email layer is what closes the loop that Playwright alone can't handle. Playwright can click "Create account," but it has no way to open an inbox and read a verification code — browsers don't have mailboxes. That's the job of the UnCorreoTemporal MCP server, which gives Claude Code a set of tools purpose-built for exactly this handoff: create_signup_inbox, wait_for_verification_email, extract_otp_code, extract_verification_link, and complete_signup_flow.

Put together, the architecture looks like this:

You describe the task in plain English
        ↓
Claude Code creates a disposable inbox (create_signup_inbox)
        ↓
Claude Code drives Playwright to fill and submit the signup form
        ↓
Claude Code waits for the verification email (wait_for_verification_email)
        ↓
Claude Code extracts the OTP or link (extract_otp_code / extract_verification_link)
        ↓
Claude Code drives Playwright to enter the code or open the link
        ↓
Account verified — inbox expires automatically

The two pieces — Playwright for the browser, MCP for the inbox — never need to know about each other's internals. Claude Code is the one thing coordinating both, which is exactly why you can describe the whole flow in a sentence instead of writing an integration between two separate systems.

Setting it up (one command, no code)

You need two things installed once: Claude Code itself, and the email MCP server. The second one is a single terminal command — you paste it in once and never think about it again:

claude mcp add uncorreotemporal \
  -e UCT_API_KEY=uct_your_key_here \
  -- uvx uncorreotemporal-mcp

Grab your API key from uncorreotemporal.com first — the free plan is enough to build and test a registration bot end to end. Once the server is registered, restart Claude Code and you're ready. No package installs, no config files to hand-edit.

Inside a Playwright email verification run

You don't have to write the Playwright code, but seeing what Claude Code actually produces makes it much easier to trust — and to ask for changes when something isn't quite right.

When you tell Claude Code something like "Sign up for app.example.com using a temporary email, then verify the account," it first asks the email MCP server for an inbox:

Tool: create_signup_inbox
Input:  { "service_name": "app.example.com" }
Output: {
  "inbox_id": "mx_abc123@mail.uncorreotemporal.com",
  "email":    "mx_abc123@mail.uncorreotemporal.com",
  "expires_at": "2026-07-15T11:30:00Z"
}

Then it writes and runs a short Playwright script to fill out the actual form — this is the part happening in the browser, invisible to you unless you ask for a screenshot:

test('register with temporary inbox', async ({ page }) => {
  await page.goto('https://app.example.com/signup');
  await page.fill('#email', 'mx_abc123@mail.uncorreotemporal.com');
  await page.fill('#name', 'Alex Founder');
  await page.fill('#password', 'TempP@ss2026!');
  await page.click('button[type="submit"]');
});

With the form submitted, Claude Code switches back to the email tools and waits — this call blocks internally until the email shows up, so nothing is polling in a loop burning your time or budget:

Tool: wait_for_verification_email
Input:  { "inbox_id": "mx_abc123@mail.uncorreotemporal.com", "timeout_seconds": 90 }
Output: { "status": "received", "message_id": "msg_9x2p1q", "subject": "Verify your account" }

Then it pulls the code or link out of that email:

Tool: extract_otp_code
Input:  { "message_id": "msg_9x2p1q", "inbox_id": "mx_abc123@mail.uncorreotemporal.com" }
Output: { "otp_code": "847291" }

And finishes the loop by having Playwright type that code into the verification field and submit it. From the moment you typed your instruction to a verified account, nothing required you to open an inbox, copy a code, or paste anything by hand.

For the common case — one signup, one verification email — you don't even need the individual steps above. Claude Code can call a single combined tool, complete_signup_flow, that creates the inbox, waits for the email, and extracts both the OTP and the link in one shot. Ask for the simple version first; only ask for the step-by-step breakdown if you need to filter by subject line or debug why an email isn't showing up.

Real business uses for a registration bot

This isn't just a party trick — it solves real, recurring friction for a one-person company.

Testing your own signup flow after every change. If you're building a SaaS product yourself (with AI-assisted coding, no-code tools, or a mix), you change your signup form more often than you'd like to admit. A registration bot lets you verify — in under a minute — that new users can still sign up and verify their account, without you manually creating and deleting test accounts all day.

Provisioning demo or sandbox accounts for vendors. Almost every API, payment processor, or B2B tool you evaluate as a solo founder requires its own signed-up, email-verified account. When you're comparing five vendors, that's five signup forms and five inboxes to babysit. The bot does all five while you do something else.

Onboarding QA before a launch or a marketing push. Before you send traffic to a new landing page or signup flow, you want confidence the whole path — form, email, verification — actually works. Running the bot a few times against a staging environment catches broken links or slow email delivery before your first real user does.

Recurring checks without a QA team. You don't have engineers on staff to write and maintain end-to-end tests. Describing the flow to Claude Code once, then re-running it whenever you ship a change, gets you most of the benefit of a QA process without hiring for it.

In every case, the pattern is the same: Playwright handles "act like a person filling out a form," the temporary inbox handles "receive and read the email a person would have opened," and Claude Code is the one thing tying the two together based on what you asked for in plain language.

A quick note on responsible use

This kind of bot is built for testing your own product, evaluating vendors, and running QA — not for creating accounts to bypass a service's free-trial limits or terms of service. Use a short-lived inbox for the specific task you're testing, not to spin up dozens of accounts on someone else's platform.

Email verification used to be the one step in a registration flow that forced a human to sit and wait. With Claude Code driving Playwright on one side and a disposable inbox on the other, that step disappears — you describe the signup once, and the bot handles the browser, the wait, and the inbox itself. If you want to try it on your own signup flow, uncorreotemporal.com has a free tier that's enough to build and run your first registration bot today.

Originally published at uncorreotemporal.com/blog/playwright-email-verification-registration-bot

Vibe coding y email: el muro invisible

Francisco Perez — Tue, 23 Jun 2026 01:01:37 +0000

El momento exacto en que todo se detiene

"Vibe coding" fue la palabra del año 2026 según Collins Dictionary. El mercado de plataformas para construir con IA vale 4.7 billones de dólares y se proyecta a 12.3 billones en 2027. El 46% de todo el código nuevo ya lo genera una IA.

Y la semana del 15 al 19 de junio, miles de personas terminaron el curso gratuito "AI Agents Vibe Coding" de Google y Kaggle. Muchos de ellos intentaron construir su primer agente esa misma semana.

La mayoría llegó al mismo muro.

Llevas dos horas con Claude Code o Cursor. La app funciona. El agente navega pantallas, rellena formularios, llama APIs. Estás en modo vibe coding puro - describes lo que quieres, el agente lo hace.

Hasta que llega este momento.

El agente necesita registrarse en algún servicio - un proveedor de datos, una API de terceros, una plataforma de pagos en modo sandbox. Rellena el formulario. Hace clic en "Crear cuenta". Y después... nada.

El servicio envió un correo de verificación. Tu agente no tiene buzón de email. No puede recibirlo. No puede continuar.

Este es el muro invisible que paraliza a casi todo agente de vibe coding en algún momento. No es un bug de tu código. No es un error del modelo. Es infraestructura que falta.

Por qué el agente no puede manejar esto solo

Cuando un servicio envía un correo de verificación, está haciendo algo que va fuera del flujo sincrónico normal:

Tu agente hace una petición HTTP - el servicio responde con "te enviamos un email"
El email llega a un buzón (cuál buzón? el agente no tiene ninguno)
Dentro del email hay un enlace o código que hay que usar antes de que expire

El agente puede razonar sobre pasos 1 y 3 sin problema. El paso 2 es el bloqueo: necesita un buzón de email real que pueda crear, monitorear y leer programáticamente.

No puedes usar tu email personal (contaminas tu inbox, además de que el agente no puede acceder a él). No puedes inventarte una dirección (el email nunca llega). Y si usas siempre la misma dirección temporal de algún servicio web, el agente no sabe cómo consultar si llegó el email ni cómo extraer el enlace.

La solución es un buzón temporal creado por código, que el agente pueda crear, esperar a que llegue el email, y leer el contenido - todo vía API o MCP.

La solución: UnCorreoTemporal + MCP

UnCorreoTemporal es exactamente eso: una API para crear buzones temporales y leer los emails que llegan. Tiene dos formas de usarlo desde un agente:

Opción A - Servidor MCP (recomendada para Claude Code/Cursor): El agente tiene herramientas nativas para crear buzones y leer emails. Sin código extra.

Opción B - REST API directa: Si tu agente está en Python, n8n, o cualquier entorno que pueda hacer peticiones HTTP.

Empezamos con la opción MCP porque es la más rápida de configurar.

Tutorial: MCP en Claude Code (5 minutos)

Paso 1 - Consigue tu API key

Ve a uncorreotemporal.com, crea una cuenta y copia tu API key. Tiene el formato uct_xxxxxxxx.

El plan gratuito incluye 100 buzones por mes - suficiente para la mayoría de side-projects y primeros experimentos. Los planes de pago arrancan en precios pensados para proyectos pequeños, no para empresas: si estás probando tu primera idea de vibe coding, no necesitas gastar más de lo que cuesta un café.

Paso 2 - Registra el servidor MCP

En tu terminal, una sola línea:

claude mcp add uncorreotemporal \
  -e UCT_API_KEY=uct_tu_key_aqui \
  -- uvx uncorreotemporal-mcp

Esto le dice a Claude Code que al arrancar, levante el servidor MCP de UnCorreoTemporal. No tienes que instalar nada más - uvx descarga y ejecuta el servidor automáticamente en un entorno aislado.

Si prefieres editar el JSON directamente, el bloque equivalente en ~/.claude/claude_desktop_config.json es:

{
  "mcpServers": {
    "uncorreotemporal": {
      "command": "uvx",
      "args": ["uncorreotemporal-mcp"],
      "env": {
        "UCT_API_KEY": "uct_tu_key_aqui"
      }
    }
  }
}

Paso 3 - Reinicia Claude Code

Cierra y vuelve a abrir Claude Code. A partir de aquí, el agente tiene acceso a estas herramientas:

create_signup_inbox - crea un buzón temporal con una dirección de email real
wait_for_verification_email - espera hasta que llegue el email
extract_verification_link - extrae el enlace de verificación del email recibido
extract_otp_code - extrae el código numérico si el servicio usa OTP en lugar de enlace

Paso 4 - Dale instrucciones al agente

Ahora puedes decirle a Claude Code algo como:

"Necesito que te registres en [servicio]. Usa UnCorreoTemporal para crear un buzón temporal, completa el registro con esa dirección, espera el email de verificación y completa el proceso."

El agente sabe qué herramientas usar. Crea el buzón, usa la dirección en el formulario de registro, espera el email, extrae el enlace y lo abre - todo solo.

Tutorial: REST API directa (para cualquier agente o script)

Si no usas Claude Code o prefieres control total, la API es igual de sencilla.

Crear un buzón

curl -X POST https://uncorreotemporal.com/api/v1/mailboxes \
  -H "Authorization: Bearer uct_tu_key_aqui"

Respuesta:

{
  "address": "aguila-veloz-42@uncorreotemporal.com",
  "inbox_id": "mbx_abc123",
  "expires_at": "2026-06-22T23:00:00Z"
}

Usa address como email en el formulario de registro del servicio que quieres automatizar.

Esperar y leer el email

Después de enviar el formulario, consulta el buzón hasta que llegue algo:

import time
import requests

API_KEY = "uct_tu_key_aqui"
ADDRESS = "aguila-veloz-42@uncorreotemporal.com"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}

# Polling simple - espera hasta 90 segundos
for _ in range(18):
    r = requests.get(
        f"https://uncorreotemporal.com/api/v1/mailboxes/{ADDRESS}/messages",
        headers=HEADERS
    )
    messages = r.json()
    if messages:
        msg_id = messages[0]["id"]
        break
    time.sleep(5)

# Leer el cuerpo completo del primer email
email = requests.get(
    f"https://uncorreotemporal.com/api/v1/mailboxes/{ADDRESS}/messages/{msg_id}",
    headers=HEADERS
).json()

print(email["body_text"])  # o email["body_html"]

Desde aquí, extraes el enlace o código con un regex o diciéndole al LLM que lo busque.

El flujo completo en un vistazo

Agente describe la tarea
       |
create_signup_inbox()  ->  dirección@uncorreotemporal.com
       |
Agente rellena el formulario con esa dirección
       |
wait_for_verification_email()  ->  espera hasta 90s
       |
extract_verification_link()  ->  https://servicio.com/verify?token=...
       |
Agente abre el enlace -> cuenta activada
       |
El buzón expira automáticamente (sin basura en tu inbox)

El email nunca llega a ningún buzón personal. El buzón temporal se borra solo cuando expira. No hay rastro.

Cuándo usar esto (y cuándo no)

Úsalo cuando:

Tu agente necesita registrarse en servicios de terceros para testing o automatización
Estás construyendo flows de QA que incluyen verificación por email
Tu agente hace onboarding de prueba en múltiples plataformas
Quieres que un script de CI/CD complete un registro real sin intervención humana

No lo uses para:

Crear cuentas con intención de eludir restricciones de servicios
Registros masivos en plataformas que prohíben el email temporal en sus términos de servicio
Producción donde necesitas un buzón permanente (para eso usa tu propio dominio)

Un ejemplo real de la vida vibe coder

Imagina que estás construyendo un agente que tiene que probar la integración de tu app con cinco proveedores de pagos distintos. Cada uno requiere una cuenta de sandbox con email verificado.

Sin UnCorreoTemporal: registras manualmente cada cuenta, verificas cinco emails, copias las credenciales. 20 minutos mínimo.

Con UnCorreoTemporal: el agente crea cinco buzones, completa los cinco registros, extrae los cinco enlaces de verificación y almacena las credenciales en un archivo. Tú estás mirando cómo lo hace.

Eso es vibe coding funcionando de verdad.

Para empezar, ve a uncorreotemporal.com, consigue tu API key y ejecuta claude mcp add. El agente hace el resto.

Registration Bot: Claude Code + Temporary Email

Francisco Perez — Tue, 12 May 2026 17:19:14 +0000

Registration Bot: Claude Code + Temporary Email

Your agent fills the name field, generates a password, clicks "Create account" — and hits the wall: Check your inbox to verify your email. No API to poll. No webhook to register. The verification code is sitting in an inbox only a human can reach, and the agent loop dies.

The fix is mechanical: give Claude Code a disposable inbox it owns and can query. This walkthrough covers the full flow — inbox creation, form submission, email polling, OTP and link extraction — using the UnCorreoTemporal MCP server.

Why registration automation needs a real inbox

Three failure modes appear reliably when teams try to hardcode or share email addresses in registration bots.

Parallel run contamination. A shared qa@company.com inbox receives OTPs from ten concurrent test jobs at once. There is no reliable way to attribute a code to the run that triggered it. Flaky tests follow.

Silent rejection. Many services validate the email domain at signup and reject known free providers, catch-all addresses, and addresses that pattern-match as machine-generated. A hardcoded address either works everywhere or gets blocked with no recovery path.

Credential management overhead. Reading a real inbox programmatically requires OAuth 2.0, token refresh, scoped permissions, and ongoing maintenance. That cost is disproportionate for a CI job that runs every commit.

Per-flow inboxes created on demand via create_signup_inbox eliminate all three. Each run gets a fresh address that lives for the duration of the flow. No shared state, no credential setup.

Prerequisites

This guide assumes you have:

Claude Code installed (npm install -g @anthropic-ai/claude-code)
uv installed for running the MCP server
The UCT MCP server already configured — full setup at uncorreotemporal.com/en/docs/mcp/

The one-line setup command:

claude mcp add uncorreotemporal \
  -e UCT_API_KEY=uct_your_key_here \
  -- uvx uncorreotemporal-mcp

Confirm it loaded by running /tools in a new Claude Code session. You should see create_signup_inbox, wait_for_verification_email, extract_otp_code, extract_verification_link, and complete_signup_flow in the list.

Step 1 — Create a temporary inbox via MCP

Before touching the signup form, the agent creates a dedicated inbox. This is always the first tool call:

Tool: create_signup_inbox
Input: {
  "service_name": "app.example.com"
}
Output: {
  "inbox_id":     "mx_abc123@mail.uncorreotemporal.com",
  "email":        "mx_abc123@mail.uncorreotemporal.com",
  "expires_at":   "2026-05-12T11:30:00Z",
  "service_name": "app.example.com"
}

service_name is a label for your reference — it doesn't affect routing, but it makes debugging easier when running multiple flows. The returned email is the address to use in the registration form. The inbox is live immediately after this call; no propagation delay.

Default TTL is 30 minutes. A complete registration loop runs in under 60 seconds — more than enough headroom.

Step 2 — Navigate to the signup form and fill fields

With the inbox address in context, Claude Code fills the registration form. The exact mechanism depends on the target — browser automation, API call, whatever fits — but the prompt structure is consistent:

Register a free account on app.example.com using:
- Email: mx_abc123@mail.uncorreotemporal.com
- Name: Alex Developer
- Password: TempP@ss2026!

Fill all required fields and submit the form. Stop after submitting.
Do not proceed to email verification yet.

Keep registration and email-polling as separate instructions. When registration fails, you want a clean stopping point — not an agent already polling an inbox that will never receive email.

Step 3 — Submit the form and wait for the verification email

Once the form is submitted, the agent waits for the incoming email with a single blocking call:

Tool: wait_for_verification_email
Input: {
  "inbox_id":        "mx_abc123@mail.uncorreotemporal.com",
  "timeout_seconds": 90
}

// Email arrived:
Output: {
  "status":       "received",
  "message_id":   "msg_9x2p1q",
  "subject":      "Verify your account",
  "from_address": "noreply@app.example.com",
  "received_at":  "2026-05-12T11:01:34Z"
}

// Timeout:
Output: {
  "status":          "timeout",
  "timeout_seconds": 90
}

The tool polls internally every 3 seconds. From Claude Code's perspective it is a single call — no repeated invocations consuming context budget. 90 seconds covers the vast majority of transactional email delivery.

If the target service sends multiple emails at signup, filter to get the right one:

{
  "inbox_id":         "mx_abc123@mail.uncorreotemporal.com",
  "timeout_seconds":   90,
  "subject_contains": "verify",
  "from_contains":    "noreply@app.example.com"
}

Step 4 — Extract the confirmation link/OTP and complete registration

Pass the message_id from the previous step to the appropriate extraction tool.

For OTP codes:

Tool: extract_otp_code
Input: {
  "message_id": "msg_9x2p1q",
  "inbox_id":   "mx_abc123@mail.uncorreotemporal.com"
}
Output: {
  "otp_code":   "847291",
  "candidates": ["847291"]
}

For magic links:

Tool: extract_verification_link
Input: {
  "message_id":        "msg_9x2p1q",
  "inbox_id":          "mx_abc123@mail.uncorreotemporal.com",
  "preferred_domains": ["app.example.com"]
}
Output: {
  "verification_link": "https://app.example.com/verify?token=eyJhbGci...",
  "candidates": [
    "https://app.example.com/verify?token=eyJhbGci...",
    "https://app.example.com/unsubscribe?email=..."
  ]
}

preferred_domains filters out unsubscribe links and tracking URLs that appear in most HTML email. candidates exposes every URL found — useful when debugging extraction failures.

Feed the result back to Claude Code with a straightforward instruction: "The OTP is 847291. Submit it in the verification form." or "Navigate to this URL to confirm the account." The registration is complete. No human touched it.

Error handling patterns (slow email delivery, retry logic, timeouts)

Email never arrives (status: timeout). Common causes: slow SMTP relay on the target service, the email filtered as spam before delivery, or a silent rejection at the registration form. Mitigation: increase timeout_seconds to 120-180 for known slow senders. After a timeout, call get_latest_email against the inbox — sometimes the email arrives just after the window closes and you can extract the token without re-running the signup.

OTP expired before submission. Most OTPs expire in 10 minutes. A complete loop runs in well under 60 seconds, so expiry is rarely the issue. If your browser automation is slow and you're hitting this consistently, request a new code from the service before submitting rather than re-running the full flow.

Service blocks the email domain. Some platforms maintain blocklists of known disposable providers. If the registration form returns "Please use a valid email address," the domain is blocked at the service level. Paid plans support custom domains so the agent receives email at agent@yourdomain.com instead of the default UCT domain — that bypasses most domain-level blocklists.

Making the agent resilient in production

Instruct the agent to stop on failure, not retry automatically. A retry spiral burns API quota and can trigger rate limits on the target service. Adding "If any step returns an error or unexpected result, report what happened and stop" to your agent prompt costs nothing and prevents a class of runaway loops.

Use complete_signup_flow for straightforward cases. If the target service sends exactly one verification email and you need the OTP or link, skip the individual tool chain:

Tool: complete_signup_flow
Input: {
  "service_name":    "app.example.com",
  "timeout_seconds": 90
}
Output: {
  "email":             "mx_abc123@mail.uncorreotemporal.com",
  "otp_code":          "847291",
  "verification_link": "https://app.example.com/verify?token=...",
  "status":            "received"
}

This creates the inbox, waits for the email, and runs both extraction tools in a single call. Use the individual tools when you need subject or sender filtering, multi-email flows, or explicit debugging breakpoints between steps.

Size the TTL to the flow. For flows that span multiple emails — activation link, then API key delivery — extend ttl_minutes at creation time. The default 30 minutes is enough for single-email flows; multi-step flows that take longer need more runway.

For the complete tool parameter reference and additional patterns for CI pipelines, see the MCP tool reference.

The email verification wall is a solved problem. Try UnCorreoTemporal free — no credit card required, and the full agent loop runs in under a minute once the MCP server is configured. The free tier is enough to wire up and validate a complete registration flow before committing it to production.

MCP vs REST API for AI Agent Email: When to Use Each

Francisco Perez — Fri, 08 May 2026 22:02:18 +0000

You want your AI agent to receive emails — OTP codes, verification links, signup confirmations. You have two options: call a REST API directly, or connect an MCP server. Both work. The trade-offs are not obvious until you've implemented both.

For agents running in Claude Code or Cursor, MCP almost always wins. But there are real scenarios where REST is the right answer. This article covers both, honestly.

What's the difference, exactly?

REST API: the agent makes explicit HTTP calls using fetch() or requests. It manages the full flow — constructing URLs, setting headers, polling for responses, parsing JSON. The agent "knows" it's calling an API and writes the glue code accordingly.

MCP server: the agent invokes tools declared by the server — create_inbox(), wait_for_email(), extract_otp() — as if they were native functions. It does not make HTTP calls directly. The host runtime (Claude Code, Cursor) manages the transport layer. The agent reasons about intent, not plumbing.

The distinction matters more than it might appear at first glance.

Latency and round-trips

The number of round-trips differs significantly between the two approaches.

With REST, the agent has to orchestrate everything manually:

POST /inboxes/ → get inbox_id
GET /inboxes/{id}/messages/ in a polling loop (every N seconds)
Parse the email body manually to extract the OTP

With MCP, the agent invokes three tool calls and the server handles the rest:

create_inbox() → inbox_id
wait_for_email(inbox_id, timeout=60) → email object (long-polling managed server-side)
extract_otp(email_id) → numeric code

Here's what that looks like in practice:

# REST approach — agent has to manage polling loop
import time
import re
import httpx

inbox = httpx.post(f"{API_URL}/inboxes/",
                   headers={"X-API-Key": API_KEY}).json()
inbox_id = inbox["id"]

# Poll every 3 seconds, up to 60 seconds
for _ in range(20):
    messages = httpx.get(
        f"{API_URL}/inboxes/{inbox_id}/messages/",
        headers={"X-API-Key": API_KEY}
    ).json()
    if messages:
        # Parse OTP from HTML body manually
        body = messages[0]["body_text"]
        otp = re.search(r'\b\d{6}\b', body).group()
        break
    time.sleep(3)

# MCP approach — agent calls tools, server handles complexity
# Inside the agent loop (Claude Code / Cursor):
# create_inbox() → {"inbox_id": "abc123", "address": "abc123@uct.dev"}
# wait_for_email(inbox_id="abc123", timeout=60) → email object
# extract_otp(email_id="msg_xyz") → "847291"
#
# The agent never writes a polling loop.
# The server handles long-polling, timeouts, and OTP extraction.

The REST version is not complicated — but it requires the agent to reason about polling intervals, handle empty responses, and parse unstructured text. Each of those is a place where something can go wrong.

Tool call ergonomics and context usage

This is the most important MCP advantage for AI agents specifically.

With REST, the agent consumes context tokens describing what URL to call, which headers to include, how to handle the response, and what to do if the request fails. Every step is explicit in the context window.

With MCP, the agent declares intent: create_inbox, wait_for_email. The server implements the details. The agent's context stays focused on the task, not on HTTP plumbing.

For long-running agents with limited context windows, this is not a minor concern. An agent handling a 20-step workflow that includes email verification has a meaningfully smaller context footprint when email is an MCP tool versus a sequence of raw HTTP calls.

Debugging experience

With REST, when something fails the agent sees an HTTP status code and a response body. It has to reason about what to do with a 429 Too Many Requests or a 504 Gateway Timeout — write retry logic, decide when to give up, handle partial failures.

With MCP, errors are returned as structured tool results. The agent runtime handles them uniformly. Retry logic lives in the server, not scattered across agent code.

There's also a tooling advantage: MCP calls are visible in Claude.ai and in the MCP Inspector. You can watch exactly what the agent called and what came back. With REST you need a proxy or server-side logs to get the same visibility.

When REST API wins

Being honest here is what makes this comparison useful. REST is the right choice in several real scenarios.

1. Integration with systems that don't support MCP: n8n, Zapier, GitHub Actions, bash scripts. If your "agent" is an automation workflow, REST is the only practical option. MCP requires a host that speaks the protocol.

2. Multiple languages in the same pipeline: if a Go backend and a Python script need to share the same inbox, REST coordinates that cleanly. MCP is designed for a single agent runtime, not cross-language pipelines.

3. Granular retry logic: if you need custom exponential backoff, dead-letter queues, or specific failure semantics, REST gives you full control. MCP abstracts those decisions to the server.

4. Webhooks and async delivery: if you need to receive emails asynchronously without the agent being active, the answer is a webhook endpoint on your server calling the REST API. MCP doesn't apply to this pattern — it assumes the agent is present and making calls.

When MCP wins

1. The agent runs in Claude Code or Cursor: these hosts have native MCP support. Configuration is a JSON snippet in claude_desktop_config.json. No HTTP code to write.

2. The flow requires waiting for an email: wait_for_email() with server-side long-polling is significantly cleaner than a polling loop in the agent. The server blocks until the email arrives (or the timeout fires), and the agent gets back a clean result.

3. Structured extraction: when the agent needs specific data from an email — OTP codes, verification links, dates — the server can expose targeted tools that return already-parsed values. The agent never touches raw email body text.

4. Less surface area for failure: fewer lines of code in the agent means fewer things that can go wrong. The MCP server owns the implementation complexity; the agent owns the task logic.

Decision matrix

Scenario	Use MCP	Use REST API
Agent runs in Claude Code or Cursor	✅
Automation workflow (n8n, Zapier, GitHub Actions)		✅
Need to wait for an OTP email	✅
Need webhooks (async, server-push)		✅
Multiple languages in same pipeline		✅
Want minimal agent context usage	✅
Need custom retry/backoff logic		✅
Prototyping quickly with Claude Desktop	✅

How to get started with both

MCP: add three lines to your claude_desktop_config.json:

{
  "mcpServers": {
    "uncorreotemporal": {
      "command": "npx",
      "args": ["-y", "@uncorreotemporal/mcp-server"],
      "env": { "UCT_API_KEY": "your_api_key" }
    }
  }
}

Restart Claude Desktop or Cursor. The tools are available immediately — no adapter code required.

REST: base URL is https://uncorreotemporal.com/api/v1/. Full reference at /en/docs/api/.

Both approaches are available on the free plan — create an inbox in under 30 seconds.

Conclusion

For agents in Claude Code or Cursor, MCP is almost always the right answer: less code, less context, cleaner debugging, and the server handles the complexity the agent would otherwise have to manage. For automation pipelines or integrations with systems that don't speak MCP, REST wins — and it's the only option for webhook-based patterns.

The practical upside: you don't have to choose permanently. UnCorreoTemporal supports both interfaces with the same credentials. Start with whichever fits your current stack, and switch when it makes sense.

How to Use Claude Code as an AI Agent with Email Verification

Francisco Perez — Wed, 06 May 2026 13:51:58 +0000

Your agent is moving fast. It navigates to the registration page, fills in the name field, generates a strong password, clicks "Create account" — and then the response comes back: Check your email to verify your address. Dead stop.

There's no API endpoint to poll. No webhook you can register. The verification code is sitting in an inbox that only a human with a browser can reach. So the agent loop breaks, you paste in an OTP manually, and wonder why you're babysitting a process you spent two days automating.

This is the wall that kills most autonomous registration flows. It's not a reasoning failure — Claude Code made all the right decisions. The problem is that standard email inboxes don't have an API. They weren't built for agents.

The UnCorreoTemporal MCP server solves exactly this. It gives Claude Code a set of tools to create disposable inboxes on demand, wait for incoming email, and extract OTPs or verification links — all within the same agent loop, no human in the middle. This guide walks through the full setup.

What You'll Build

By the end of this guide, Claude Code will be able to run this flow completely autonomously:

Claude Code agent loop
  └─► create_signup_inbox()  ──► generates mx_abc123@mail.uncorreotemporal.com
  └─► register at app.example.com using that address
  └─► wait_for_verification_email() ──► blocks until email arrives (up to 90s)
  └─► extract_otp_code() ──► pulls "847291" from the email body
  └─► submit OTP ──► registration complete ✓

Claude Code acts as the autonomous agent. The UnCorreoTemporal MCP server provides the inbox tooling — create_signup_inbox, wait_for_verification_email, extract_otp_code, extract_verification_link, and a convenience wrapper called complete_signup_flow that chains all of them in a single call.

The target service is whatever you're actually automating. In this guide I'll use app.example.com as a generic placeholder, but the same pattern applies to any SaaS trial, developer portal, or API sign-up that gates access behind an email confirmation.

Prerequisites

Claude Code installed: npm install -g @anthropic-ai/claude-code
uv installed (for running the MCP server via uvx): curl -LsSf https://astral.sh/uv/install.sh | sh
An UnCorreoTemporal API key — free tier at uncorreotemporal.com, 100 inboxes/month, no credit card
Python 3.10+ — optional, only needed for the standalone script variant in the extraction section

Step 1 — Configure the MCP Server in claude_desktop_config.json

This is the step most guides skip over. If the MCP server isn't wired up correctly, Claude Code has no email tools and the whole thing is dead before it starts.

The quick way: `claude mcp add`

Claude Code ships with a CLI command for registering MCP servers:

claude mcp add uncorreotemporal \
  -e UCT_API_KEY=uct_your_key_here \
  -- uvx uncorreotemporal-mcp

That's it. Claude Code writes the config for you. If you prefer to edit the JSON directly, the equivalent block in ~/.claude/claude_desktop_config.json looks like this:

{
  "mcpServers": {
    "uncorreotemporal": {
      "command": "uvx",
      "args": ["uncorreotemporal-mcp"],
      "env": {
        "UCT_API_KEY": "uct_your_key_here"
      }
    }
  }
}

What this does

The mcpServers block tells Claude Code which external tool servers to launch when it starts. Each entry specifies a command to run — in this case uvx uncorreotemporal-mcp, which downloads and runs the server from PyPI using uv's isolated environment runner — plus any environment variables the server needs.

The API key goes in env, not hardcoded in args. This keeps it out of shell history, out of version control, and makes it easy to rotate without touching the config structure.

Verify it loaded

Start a new Claude Code session and type /tools. You should see a list that includes:

create_signup_inbox
wait_for_verification_email
get_latest_email
extract_otp_code
extract_verification_link
complete_signup_flow

If the tools don't show up, check that uvx is on your PATH (which uvx). If it's not, uv isn't installed or isn't in your shell's PATH — run source $HOME/.local/bin/env or restart your terminal after installing uv.

The full MCP tool reference is at uncorreotemporal.com/en/docs/mcp/.

Step 2 — Create a Disposable Inbox

Once Claude Code has the tools loaded, creating an inbox is a single tool call. Here's what Claude Code actually sends and receives:

Tool: create_signup_inbox
Input: {
  "service_name": "app.example.com"
}
Output: {
  "inbox_id": "mx_abc123@mail.uncorreotemporal.com",
  "email":    "mx_abc123@mail.uncorreotemporal.com",
  "expires_at": "2026-05-06T10:04:00Z",
  "service_name": "app.example.com"
}

A few things worth noting:

service_name is required. It's a label for your own reference — it doesn't affect routing, but it helps when you're running multiple inboxes and debugging which one belongs to which flow.
inbox_id is the email address. There's no separate opaque ID — the email itself is the identifier you pass to subsequent tool calls.
The inbox is live immediately. No DNS propagation, no warming period. Mail sent to that address is queued within seconds of creation.
Default TTL is 30 minutes, configurable via ttl_minutes. For most signup flows, 30 minutes is more than enough — the whole loop should complete in under 60 seconds.

Claude Code stores the returned email address in its context and uses it for the next step.

Step 3 — Register on the Target Service

Now Claude Code takes that address and uses it to sign up. The prompt you give it controls how it does this — browser automation, API call, form fill, whatever fits the target service. For a typical SaaS registration flow:

Register a free account on app.example.com using the email address from the 
inbox you just created. Fill in all required fields with realistic placeholder 
data. Use the name "Alex Developer" and generate a strong password. Once 
you submit the form, stop and wait for my next instruction.

Claude Code will substitute the generated email address into the registration form. Everything else in the form — name, password, company, timezone — it can fill with plausible placeholder data. The email is the only field that must match the inbox.

This step doesn't require any additional MCP tool calls. Claude Code handles the form interaction through its existing browser automation or API capabilities. The MCP tools come back into play for the next step.

One thing I've learned from running these flows: don't ask Claude Code to wait for the email in the same prompt as the registration. Keep registration and email-waiting as separate steps. It's easier to debug when one fails, and it avoids the agent making assumptions about delivery timing.

Step 4 — Wait for the Verification Email

This is where the flow either works end-to-end or breaks down in a standard setup. With the MCP server, it's a single blocking tool call:

Tool: wait_for_verification_email
Input: {
  "inbox_id": "mx_abc123@mail.uncorreotemporal.com",
  "timeout_seconds": 90
}
Output: {
  "status": "received",
  "message_id": "msg_9x2p1q",
  "subject": "Verify your account",
  "from_address": "noreply@app.example.com",
  "received_at": "2026-05-06T10:01:34Z",
  "timeout_seconds": 90
}

The tool polls the inbox every 3 seconds until a message arrives or the timeout is reached. From Claude Code's perspective this is opaque — it makes one tool call and gets back a result. No retry loop, no repeated tool invocations burning your context budget.

If the timeout fires before anything arrives, you get:

{
  "status": "timeout",
  "timeout_seconds": 90
}

I've found 90 seconds covers the vast majority of transactional email delivery in practice. For services with aggressive rate limiting or slow SMTP relay, you can push it to 120 or 180. For CI pipelines where speed matters more, 60 seconds is usually sufficient.

The response includes message_id and from_address but not the email body — that's intentional. Body retrieval is a separate concern handled by the extraction tools in the next step, which can work from message_id directly without an additional get_latest_email call.

You can also filter by sender or subject if you're dealing with services that send multiple emails on signup:

Tool: wait_for_verification_email
Input: {
  "inbox_id": "mx_abc123@mail.uncorreotemporal.com",
  "timeout_seconds": 90,
  "subject_contains": "verify",
  "from_contains": "noreply@app.example.com"
}

Step 5 — Extract the OTP with Regex

Once wait_for_verification_email returns "status": "received", you have a message_id. Pass it directly to extract_otp_code:

Tool: extract_otp_code
Input: {
  "message_id": "msg_9x2p1q",
  "inbox_id": "mx_abc123@mail.uncorreotemporal.com"
}
Output: {
  "otp_code": "847291",
  "candidates": ["847291"]
}

The tool fetches the message body internally, runs a regex sweep for numeric sequences in the otp_length_min–otp_length_max range (default 4–8 digits), and returns the most likely match as otp_code. If there are multiple numeric sequences, they all appear in candidates — useful when the email body contains things like reference numbers or ZIP codes that could false-positive.

You can narrow the range explicitly:

Tool: extract_otp_code
Input: {
  "message_id": "msg_9x2p1q",
  "inbox_id": "mx_abc123@mail.uncorreotemporal.com",
  "otp_length_min": 6,
  "otp_length_max": 6
}

Doing it yourself in Python

If you're building a script rather than using Claude Code interactively, here's the extraction logic without any SDK dependency:

import re

def extract_otp(text: str, digits: int = 6) -> str | None:
    pattern = rf'\b\d{{{digits}}}\b'
    matches = re.findall(pattern, text)
    return matches[0] if matches else None

# Usage
otp = extract_otp(email_body_text)
# -> "847291"

Common OTP patterns you'll encounter in the wild:

6-digit numeric (most common, e.g. Twilio, Auth0, most SaaS): \b\d{6}\b
8-digit numeric (banking, government): \b\d{8}\b
Alphanumeric codes (e.g. B4K9X2TZ): \b[A-Z0-9]{8}\b
Magic links: handled separately by extract_verification_link (see the next section)

Step 6 — Complete the Registration

You have the OTP. Now Claude Code submits it. The prompt is straightforward:

The OTP extracted from the verification email is 847291. Submit it in the 
verification form on app.example.com. Once submitted, confirm that the 
account dashboard is visible and report whether registration succeeded.

Claude Code navigates back to the verification form, enters the code, and submits. If the service uses a magic link instead of a code, the flow is identical — you just pass the URL from extract_verification_link instead of a 6-digit code.

At this point the agent loop is complete. No human touched it.

Putting It All Together — A Complete Agent Loop Prompt

Here's the prompt I use for end-to-end autonomous registration. Copy it, swap app.example.com for your actual target, and adjust the password and name as needed.

You are an autonomous registration agent. Complete the following workflow 
in order, stopping if any step fails:

1. Call create_signup_inbox with service_name "app.example.com" and store 
   the returned email address.

2. Register a free account on app.example.com using:
   - Email: the address from step 1
   - Name: Alex Developer
   - Password: TempP@ss2026!
   Fill all required fields. Submit the registration form.

3. Call wait_for_verification_email with the inbox_id from step 1 and 
   timeout_seconds 90. Wait for status "received".

4. Call extract_otp_code with the message_id and inbox_id from the 
   previous steps.

5. Submit the extracted OTP code in the verification form on app.example.com.

6. Confirm the account dashboard is accessible, then report:
   - Email address used
   - OTP extracted
   - Whether registration succeeded (yes/no)
   - Any unexpected behavior during the flow

If any step returns an error or unexpected result, report exactly what 
happened and stop. Do not retry automatically.

Why the prompt is structured this way

Numbered steps enforce sequence. Claude Code can parallelize tool calls when it reasons that two actions are independent. An explicit numbered list signals that order matters and each step depends on the previous one.

Explicit tool names in the prompt. Saying "call create_signup_inbox" rather than "create an inbox" removes ambiguity about which MCP tool to use. It also makes the agent's reasoning trace easier to follow when you're debugging.

"Do not retry automatically." This is the most important line. When a step fails — email never arrives, OTP is wrong, form submission errors — you want the agent to stop and report, not loop into a retry spiral that burns API quota and potentially triggers rate limits on the target service.

Structured report at the end. The bulleted output at step 6 gives you something machine-parseable if you're chaining this into a larger pipeline.

Handling Failure Cases

Real-world flows break in predictable ways. Here's how to handle them.

Email never arrives

wait_for_verification_email returns {"status": "timeout"} after the configured seconds. Common causes:

The service's SMTP relay is slow (some providers queue outbound email for 30–60 seconds under load)
The email was delivered but classified as spam and filtered before it reached the inbox
The registration form rejected the address silently and never sent the email

Mitigation: increase timeout_seconds to 120 or 180 for slow senders. If you're seeing consistent timeouts, call get_latest_email after the timeout to check whether anything arrived at all — sometimes the email arrives just after the timeout window closes.

OTP already expired by the time you submit it

Most OTPs expire in 10 minutes. The entire flow — create inbox, register, wait for email, extract OTP, submit — should complete in well under 60 seconds in practice. If your agent is slow (large context, slow browser automation), request a new OTP from the service before submitting.

Service blocks the email domain

Some services — Google, Apple, Stripe, most banking platforms — maintain blocklists of known disposable email providers and reject addresses from those domains at signup. If you hit this, you'll know immediately: the registration form will return an error like "Please use a valid email address."

The UCT dedicated plans include support for custom domains — you can receive email at agent@yourdomain.com instead of the default @mail.uncorreotemporal.com. That bypasses most domain-level blocklists.

Beyond OTPs — Magic Links and Multi-Step Flows

Not every service sends a 6-digit code. Plenty of them send a magic link — a one-time URL that logs you in or confirms your email when you visit it. The MCP server handles this with extract_verification_link:

Tool: extract_verification_link
Input: {
  "message_id": "msg_9x2p1q",
  "inbox_id": "mx_abc123@mail.uncorreotemporal.com",
  "preferred_domains": ["app.example.com"]
}
Output: {
  "verification_link": "https://app.example.com/verify?token=eyJhbGci...",
  "candidates": [
    "https://app.example.com/verify?token=eyJhbGci...",
    "https://app.example.com/unsubscribe?email=..."
  ]
}

preferred_domains nudges the extraction toward links from the service's own domain, filtering out unsubscribe links, tracking pixels, and other noise that appears in most HTML email.

Multi-step flows

The same tool chain composes naturally for flows that span multiple emails. A common pattern in developer-facing SaaS:

Register -> receive email confirmation link -> click it -> account activated
Account activated -> receive welcome email with API key -> extract API key

You don't need to restart the agent or re-create the inbox between steps. The inbox stays live for its full TTL, and wait_for_verification_email can be called multiple times against the same inbox_id. Chain two wait_for_verification_email + extract_* call pairs and you have the whole flow in one agent session.

The `complete_signup_flow` shortcut

If your flow is straightforward — register, wait for one verification email, extract the link or OTP — there's a single tool that wraps all of it:

Tool: complete_signup_flow
Input: {
  "service_name": "app.example.com",
  "timeout_seconds": 90
}
Output: {
  "inbox_id": "mx_abc123@mail.uncorreotemporal.com",
  "email": "mx_abc123@mail.uncorreotemporal.com",
  "otp_code": "847291",
  "verification_link": "https://app.example.com/verify?token=...",
  "message_id": "msg_9x2p1q",
  "status": "received"
}

complete_signup_flow creates the inbox, waits for the email, and runs both OTP and link extraction in sequence. You get everything back in one response. For simple flows this is the cleanest approach; for multi-step or filtered flows, calling the individual tools gives you more control.

Try It Yourself

The fastest path from zero to a working agent loop is:

Sign up at uncorreotemporal.com — no credit card, API key in the dashboard immediately
Run claude mcp add uncorreotemporal -e UCT_API_KEY=uct_your_key_here -- uvx uncorreotemporal-mcp
Open a Claude Code session, type /tools, confirm the six tools are listed
Paste the agent loop prompt from the "Putting It All Together" section, point it at a real service, and watch it run

The free tier gives you 100 inboxes per month, which is enough to wire up and test a full registration flow. If you're running this in CI — automated integration tests, synthetic monitoring, agent-driven QA — the full MCP tool reference covers filtering options, TTL configuration, and the get_latest_email tool for cases where you need the raw message body.

The email verification wall is a solved problem. Your agent loop doesn't have to stop there.

Why Every AI Agent Stack Needs an Email Verification Layer

Francisco Perez — Thu, 30 Apr 2026 19:10:36 +0000

Your agent just submitted a registration form. The third-party service responded with a 200 OK and a message: "Check your inbox for a verification link."

The agent cannot check an inbox. It doesn't have one. It used your dev email address — the one that belongs to a human who is in a different time zone and probably not watching their email right now. The agent is stuck at the wall. The pipeline is stalled. And the frustrating part is that every other step worked.

AI agent email verification is one of the most common hard stops in agentic pipelines. Agents can browse the web, call APIs, fill forms, parse HTML, and chain together dozens of steps — but the moment a service sends a verification email, most of them hit a dead end. This article explains why that happens, what the actual requirements are for email infrastructure that works with agents, and how to wire up a purpose-built MCP email server so it never happens again.

What Changed — From Chatbots to Agents That Actually Do Things

A chatbot suggests. An agent executes.

The distinction matters here. Chatbots operate in a request-response loop with a human at one end. Agents operate in a perceive-reason-act loop that runs autonomously — they navigate UI flows, call external APIs, handle state across steps, and complete tasks without a human approving each action.

The infrastructure that made this practical at scale is Model Context Protocol (MCP), an open standard released by Anthropic and now the de-facto interoperability layer for AI agent tooling. MCP defines a canonical interface for exposing capabilities to agents: a server registers typed tools, and any MCP-compatible runtime — Claude, Copilot, AutoGen, LangGraph, n8n — can discover and call those tools without custom glue code per integration. By 2025-2026, Google, Microsoft, and Amazon had all adopted MCP as a core part of their agent platform strategies.

The practical consequence: an agent without the right tools is just a chatbot with extra steps. Tools are what give agents agency. A browser tool lets the agent navigate. A code execution tool lets it write and run scripts. A search tool lets it query the web. And an email tool — specifically, a purpose-built one that creates real inboxes and reads from them programmatically — is what lets it complete the signup flows, verification steps, and notification-driven workflows that are gated behind email.

Without it, every email-gated flow becomes a manual intervention point. That is the failure mode most teams discover late, usually at 2am when a pipeline that worked in testing falls apart against a real service.

Email Verification Is the Silent Killer of Agentic Flows

Most people underestimate how often email verification appears in real-world automation. Account registration, API key delivery, purchase confirmations, approval workflows, password resets — a significant fraction of services require a working inbox before they grant access to anything.

The problem has four distinct failure modes when you try to handle email without proper infrastructure:

1. The agent must own the inbox before it signs up. You cannot verify an address you do not control. The correct sequence is: create inbox -> get address -> submit form -> wait for email -> extract token. Most agent implementations skip the first step and use the developer's real email address, which collapses the rest of the flow.

2. Using a real email doesn't scale. One inbox shared across all agent runs causes immediate problems: parallel runs contaminate each other's messages, OTP codes from different registrations get mixed up, and your dev account accumulates thousands of verification messages. That is also a privacy and compliance problem — real user email addresses attached to test accounts.

3. Public disposable email services are blocked. Mailinator, YOPmail, and similar consumer tools are blocked by most production services. They also have no API suitable for agents — no authentication, no reliable delivery, no polling interface that code can depend on.

4. IMAP polling is a trap. The approach that seems obvious — connect to Gmail via IMAP, poll for new messages — breaks in an agent context:

# naive approach -- don't do this
import imaplib, time

def wait_for_otp(email, password, timeout=60):
    mail = imaplib.IMAP4_SSL("imap.gmail.com")
    mail.login(email, password)  # your real credentials in agent context
    start = time.time()
    while time.time() - start < timeout:
        mail.select("inbox")
        _, msgs = mail.search(None, "UNSEEN")
        if msgs[0]:
            return parse_otp(msgs[0])  # brittle regex against raw MIME
        time.sleep(5)  # blocking the agent loop for 5 seconds per cycle
    raise TimeoutError("No OTP received")

What's wrong here: real credentials living in the agent's execution context, no inbox isolation between parallel runs, polling blocks the agent loop, IMAP connections are stateful and flaky, and regex against raw MIME breaks on any whitespace change in the email template.

What a Purpose-Built Agent Email Layer Looks Like

The requirements follow directly from how agents work. Missing any one of them creates a failure mode at scale.

Programmatic inbox creation: one API call returns a live email address — no UI, no human step, no waiting.
Scoped TTL: the inbox expires automatically. Thirty minutes is enough for a signup flow. No garbage collection required from the agent.
No polling loops in agent code: the agent calls wait_for_verification_email with a timeout and gets a result when the email arrives.
Native extraction: the tool returns otp_code or verification_link as a structured field. The agent does not write regex or parse MIME.
Inbox isolation: each agent run gets its own inbox. Parallel pipelines do not share state.
MCP-native: the agent uses email as a tool primitive, not a side channel requiring custom adapter code per framework.

The MCP Email Server in Practice

There are two integration paths. You can use the REST API directly from any agent that can make HTTP calls, or the MCP server if your agent runtime supports Model Context Protocol.

Approach A — REST API

import httpx, time

# Step 1: Create a temporary inbox
response = httpx.post(
    "https://uncorreotemporal.com/api/v1/mailboxes",
    headers={"Authorization": "Bearer uct_xxxx"},
    params={"ttl_minutes": 30}
)
inbox = response.json()
email_address = inbox["address"]  # e.g. "mango-panda-42@uncorreotemporal.com"
# inbox also contains: expires_at

# Step 2: Use this address to sign up somewhere
# ... your agent submits the registration form with email_address ...

# Step 3: Poll for the verification email
for _ in range(18):  # up to 90 seconds
    time.sleep(5)
    messages = httpx.get(
        f"https://uncorreotemporal.com/api/v1/mailboxes/{email_address}/messages",
        headers={"Authorization": "Bearer uct_xxxx"},
    ).json()
    # Each message has: id, from_address, subject, received_at, is_read
    unread = [m for m in messages if not m["is_read"]]
    if unread:
        break

# Step 4: Read the full message
msg = httpx.get(
    f"https://uncorreotemporal.com/api/v1/mailboxes/{email_address}/messages/{unread[0]['id']}",
    headers={"Authorization": "Bearer uct_xxxx"},
).json()
# msg contains: body_text, body_html, from_address, subject, received_at

verification_link = extract_url(msg["body_text"])

Approach B — MCP Tools

Add the server to your claude_desktop_config.json:

{
  "mcpServers": {
    "uncorreotemporal": {
      "command": "uvx",
      "args": ["uncorreotemporal-mcp"],
      "env": {
        "UCT_API_KEY": "uct_your_key_here"
      }
    }
  }
}

With the MCP server registered, Claude and other MCP-compatible agents complete the entire verification flow using native tool calls:

# Tool 1: create_signup_inbox
inbox = create_signup_inbox(service_name="github", ttl_minutes=30)
# Returns: {"inbox_id": "mango-panda-42@uncorreotemporal.com",
#           "email": "mango-panda-42@uncorreotemporal.com",
#           "expires_at": "2026-04-30T15:30:00Z"}

# ... agent submits signup form using inbox["email"] ...

# Tool 2: wait_for_verification_email
result = wait_for_verification_email(
    inbox_id=inbox["inbox_id"],
    timeout_seconds=90,
    subject_contains="verify"
)
# Returns: {"status": "received", "message_id": "3f8a1c2b-...",
#           "subject": "Please verify your account"}

# Tool 3a: extract_verification_link
link = extract_verification_link(
    inbox_id=inbox["inbox_id"],
    message_id=result["message_id"]
)
# Returns: {"verification_link": "https://github.com/confirm?token=abc123"}

# Tool 3b: extract_otp_code
otp = extract_otp_code(
    inbox_id=inbox["inbox_id"],
    message_id=result["message_id"]
)
# Returns: {"otp_code": "847291", "candidates": ["847291"]}

Why MCP is cleaner: the agent gets tools as native primitives with typed schemas. No credential management in agent context. No adapter code per framework. There is also a complete_signup_flow tool that wraps the entire sequence in a single call.

Full setup docs: https://uncorreotemporal.com/en/docs/mcp/

Beyond One-Off Testing — Where This Scales

Parallel agent workloads. A pipeline running 50 sub-agents simultaneously needs 50 isolated inboxes, all created programmatically, all expiring on schedule. The Pro plan supports 20 concurrent mailboxes with 2,000 requests/day; the Team plan handles 100 mailboxes at 10,000 req/day. Sized for production agent workloads: https://uncorreotemporal.com/en/pricing/

Privacy by design. Agents acting on behalf of users should never touch real user email addresses. Ephemeral inboxes make this a structural guarantee — the address expires, the data disappears.

Compliance. In regulated industries, test data must not include real PII. An inbox at mango-panda-42@uncorreotemporal.com has no connection to any real person. It expires on schedule. It leaves no trail.

Conclusion

The verification email that stops your agent is not a hard problem — it is a missing infrastructure problem. Add a purpose-built email layer that creates isolated inboxes on demand, waits for delivery without polling loops, and extracts tokens as native tool outputs.

To get started: MCP setup docs at https://uncorreotemporal.com/en/docs/mcp/ — or try the free plan (1 mailbox, 50 req/day) at https://uncorreotemporal.com/en/pricing/

Originally published at uncorreotemporal.com

Agentic Web Email Infrastructure

Francisco Perez — Tue, 28 Apr 2026 20:09:43 +0000

Your agent is three steps away from completing a registration. It filled out the form, submitted it, and got a 200 OK back. The service responds: "Check your inbox for a verification link."

And there the agent stops.

There is no inbox to check. The email address it used was your dev account — the one you use for everything — and that account belongs to a human who is probably asleep. There is no tool the agent can call that returns "the link from the email that just arrived." It has done everything right, and it is stuck.

This is the agentic web email infrastructure problem. Agents can browse pages, call APIs, write code, and run shell commands. But most of them cannot receive email — and an astonishing fraction of real services require email verification before granting any access at all. Until your agent can create an inbox, read from it programmatically, and extract tokens from the messages that arrive, it will keep failing at this wall.

The rest of this article explains why this is architecturally harder than it looks, and what a proper solution requires.

What the Agentic Web Actually Means

The shift happening right now is not about smarter chatbots. It is about systems that follow a complete perceive → reason → act loop without a human approving each step.

In 2026, this is production behavior. GitHub Copilot opens pull requests, runs tests, iterates on reviewer feedback, and merges — end to end without a developer in the loop for each cycle. Google Search can schedule appointments by calling restaurant booking APIs directly. Cloudflare and GoDaddy ship integrations where agents register domains, provision DNS records, and deploy edge workers autonomously. These are not demos. These are workflows that previously required a person sitting at a computer.

The interoperability layer making all of this possible is Model Context Protocol (MCP), an open standard released by Anthropic and now adopted across the industry. MCP defines how agents discover and invoke external tools: a schema-annotated registry of capabilities that any MCP-compatible runtime — Claude, Cursor, AutoGen, LangGraph, n8n — can use without writing custom adapter code for each integration. An agent registers a server, gets a list of typed tools back, and can call them the same way it calls any other capability.

As agents take on more real-world tasks — account provisioning, API access registration, subscription management, collecting data from services that require login — they increasingly hit the same structural blocker. Email-gated flows are not a fringe edge case. They sit at the entrance to most services on the internet, and the agentic web email infrastructure needed to get past them is almost always missing from the stack.

The Email Verification Wall

Email verification is the most common blocker for autonomous agents because the standard flow makes three assumptions that break the moment an agent is involved.

The inbox exists before the signup. A human has an email address before they visit the registration page. An agent must create the inbox first, get the address back, then use that address in the form. The sequence matters: you cannot verify an address you do not already control.

A human is monitoring the inbox. OTP codes expire in minutes. Verification links sometimes expire in hours. The standard UX — sign up, switch to email, click the link — assumes continuous human availability. An agent needs a programmatic flow: create inbox, submit form, poll for the message, extract the token, complete the flow. No human hand-off.

The email address is stable and personal. Using your own dev email for agent-driven signups pollutes your inbox with thousands of verification messages from test runs. It also creates a real privacy risk: your email is now attached to every service account the agent created, forever.

The naive workaround looks like this:

# What most teams try first — and why it fails
import time, requests

EMAIL = "my-dev-account@gmail.com"  # shared across all runs, pollutes inbox

# Submit the signup form
requests.post("https://someservice.com/register", json={"email": EMAIL})

# Wait and hope
time.sleep(30)  # no feedback, brittle in CI/CD, timing is a guess

# No programmatic access to Gmail without a full OAuth setup
# The agent is stuck. The only option is asking a human to check.
print("Please verify manually")  # defeats the purpose entirely

This fails in CI because there is no API to read the inbox. It fails across parallel runs because multiple agents share the same address. It fails against services with short OTP TTLs. And it creates a compliance problem every time a real user email ends up attached to a test account.

What Proper Email Infrastructure Looks Like for an Agent

A production-grade AI agent email solution needs to satisfy six requirements. Missing any one of them creates a failure mode at scale.

1. Programmatic inbox creation. The agent must be able to call an API or MCP tool to create a fresh inbox and get back a live email address. Not a UI, not a manual step — a single function call that returns an address ready to receive SMTP traffic.

2. Configurable TTL. Inboxes should expire automatically. Thirty minutes for a signup flow, twenty-four hours for a batch pipeline. The agent declares intent; the infrastructure enforces cleanup. No garbage collection required from the agent.

3. Sub-200ms delivery notification. An agent polling with a five-second sleep introduces up to five seconds of latency per email retrieval. Real pub/sub delivery — or at minimum a polling endpoint with fresh-data guarantees — is what keeps pipelines fast enough to be useful in CI/CD.

4. OTP and link extraction as native primitives. The agent should not be writing regex against raw email bodies. OTP extraction and verification link extraction should be first-class tool calls that return structured fields — otp_code, verification_link — not raw strings the agent has to parse itself.

5. No shared inboxes. Each agent, each run, each task should own its inbox exclusively. A shared inbox leaks tokens between runs, creates race conditions in parallel pipelines, and mixes data between agents operating at different trust levels.

6. API key scoping. Per-key quotas and team plan rate limits prevent a runaway agent from exhausting the inbox budget for the entire organization. The key belongs to the agent system, not to an individual developer account.

These requirements are what separate infrastructure designed for autonomous agents from a consumer-grade disposable email service that someone hacked into a pipeline.

UnCorreoTemporal in Practice — A Real Agent Flow

UnCorreoTemporal provides an MCP server built specifically for autonomous agent signup flows. Five tools cover the complete flow. Here is a working Python example using the real tool names and field names from the codebase:

import asyncio, json
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
import requests

server_params = StdioServerParameters(
    command="uvx",
    args=["uncorreotemporal-mcp"],
    env={"UCT_API_KEY": "uct_your_api_key_here"}
)

async def complete_signup(service_url: str) -> None:
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()

            # Step 1: Create a temporary inbox (TTL: 30 minutes)
            r = await session.call_tool("create_signup_inbox", {
                "service_name": "example-service",
                "ttl_minutes": 30
            })
            inbox = json.loads(r.content[0].text)
            email    = inbox["email"]      # e.g. "mango-panda-42@uncorreotemporal.com"
            inbox_id = inbox["inbox_id"]   # same value; used to poll for messages

            # Step 2: Submit the signup form with the temporary address
            requests.post(f"{service_url}/register", json={"email": email})

            # Step 3: Wait for the verification email (polls automatically)
            r = await session.call_tool("wait_for_verification_email", {
                "inbox_id": inbox_id,
                "timeout_seconds": 90,
                "subject_contains": "verify"
            })
            waited = json.loads(r.content[0].text)

            if waited.get("status") != "received":
                raise RuntimeError("Verification email did not arrive within timeout")

            message_id = waited["message_id"]

            # Step 4a: Extract OTP code (if the service uses numeric codes)
            r = await session.call_tool("extract_otp_code", {
                "inbox_id": inbox_id,
                "message_id": message_id
            })
            otp_result = json.loads(r.content[0].text)
            otp = otp_result.get("otp_code")  # e.g. "847291"

            # Step 4b: Or extract verification link (if the service uses click-to-verify)
            r = await session.call_tool("extract_verification_link", {
                "inbox_id": inbox_id,
                "message_id": message_id
            })
            link_result = json.loads(r.content[0].text)
            link = link_result.get("verification_link")

            # Step 5: Complete the flow
            if otp:
                requests.post(f"{service_url}/verify", json={"otp": otp})
            elif link:
                requests.get(link)

asyncio.run(complete_signup("https://someservice.com"))

The MCP server handles all the infrastructure: creating the mailbox via POST https://uncorreotemporal.com/api/v1/mailboxes, polling for delivery, and extracting structured tokens from the raw email body. The agent just calls tools.

Why This Matters Beyond Testing

The most obvious use case is CI/CD: integration tests that need a fresh inbox per run, per test case, with zero shared state. But the same infrastructure applies to production agent architectures.

Multi-agent pipelines. A research agent, a scheduling agent, and a delivery agent in the same pipeline may each need separate accounts on different services. Each gets its own inbox, its own identity. No cross-contamination between tasks.

Privacy-preserving agent architectures. An agent acting on behalf of a user should never expose that user's real email address to third-party services. Temporary inboxes decouple the user's identity from the agent's operational identity.

Regulatory compliance. Agents that register accounts using real user emails attach PII to every service they touch. Using ephemeral inboxes keeps PII out of third-party data stores — directly relevant to GDPR, CCPA, and any compliance framework that tracks where user data flows.

Scale. One hundred parallel agents each completing a signup flow simultaneously need one hundred isolated inboxes, created and expired programmatically. There is no manual coordination approach that works at that scale.

Conclusion

The agentic web email infrastructure problem is not going away — it is growing proportionally with agent capability. The five MCP tools covered here — create_signup_inbox, wait_for_verification_email, get_latest_email, extract_otp_code, extract_verification_link — cover the majority of real agent email workflows without requiring the agent to manage SMTP, parse raw message formats, or write custom extraction logic.

Get the MCP server running in minutes at uncorreotemporal.com/en/docs/mcp/, or start with a free plan at uncorreotemporal.com/en/pricing/.

Originally published at uncorreotemporal.com/blog/agentic-web-autonomous-agents-email-infrastructure

Why AI Agents in n8n Fail on Real-World Workflows (and How to Fix It)

Francisco Perez — Sun, 19 Apr 2026 13:38:04 +0000

The Gap Between the Demo and the Real World

The demo always works. You wire up an LLM node in n8n, chain a few HTTP requests, and the agent navigates through a multi-step workflow without a hitch. Then you point it at something real — a signup flow, a SaaS trial, a service that requires email verification — and the workflow halts.

Not because the reasoning was wrong. The agent chose the right action. It decided to create an account. It selected the right form fields. It even generated a valid request.

It failed because the service sent a verification email and the agent had no way to receive it.

This is the pattern that breaks most real-world n8n agent pipelines: they are designed for deterministic, synchronous systems, but the real web is asynchronous and email-dependent.

The Promise of n8n + AI Agents

n8n is a genuinely strong orchestration layer. It handles node chaining, branching, retries, credential management, and webhook ingestion cleanly. When you connect it to an LLM via the AI Agent node, you get a workflow that can reason about inputs, call external APIs, and decide what to do next.

This combination works well for:

Scraping structured data and transforming it
Calling APIs with conditional logic
Generating content from templates or user inputs
Classifying and routing incoming data

The LLM handles ambiguity. n8n handles orchestration. For many workflows, this is enough.

The problem surfaces when the workflow leaves the API-accessible world and enters real-world system interactions — specifically, anything that routes through email.

Where Things Break

Email verification is the most common hard wall. Consider any of the following:

Account registration on a third-party service that requires email confirmation before the account is active
OTP-based login where a time-limited code arrives in an inbox
Magic link authentication, where the session token is delivered via email
Trial onboarding flows that gate API key generation behind an email confirmation step

These are not edge cases. They are standard authentication patterns across most of the web. An agent that cannot handle them cannot operate autonomously in real environments.

The deeper problem is structural. Email delivery is asynchronous. The time between a signup request and the arrival of a verification email is non-deterministic — it could be two seconds or forty-five. There is no webhook you can register. There is no polling endpoint you can call against the sender. The email arrives at an inbox, and something needs to be watching that inbox.

In a standard n8n workflow, there is nothing watching.

A Concrete Example: Agent Gets Stuck

Imagine an n8n workflow where an AI agent is tasked with registering a trial account on a data API service to test a new integration:

[AI Agent Node]
  -> decides: "I need to create a test account on api.someservice.com"
  -> calls: POST /api/v1/signup  { email: ???, name: "Test Agent" }
  -> receives: { status: "pending", message: "Check your email to verify" }
  -> next step: ???

The agent needs an email address to register. If you hardcode your personal inbox, the verification email lands in a human mailbox — someone has to click the link manually. The workflow is no longer autonomous.

The typical workarounds developers try:

# Option 1: Use a static dummy address
# -> verification never arrives, account stays unconfirmed

# Option 2: Use a public throwaway service (Guerrilla Mail, temp-mail.org)
# -> no API, browser-only, no way to read messages programmatically

# Option 3: Use Gmail + polling via OAuth
# -> requires OAuth setup, scopes, token refresh, high latency,
#   and you're mixing test email with real email

# Option 4: Give up and inject a pre-verified account
# -> the workflow is no longer testing what it claims to test

None of these are real solutions. They either break automation or introduce manual steps that defeat the purpose of the agent.

Root Cause Analysis

The failure has four technical causes:

1. Async delivery with no callback. Email follows a push model — the sender's SMTP server delivers to a recipient's MX record. There is no mechanism for the receiving side to signal "I got it" back to the sender in a structured way. The gap between send and receive is real and variable.

2. Polling requires infrastructure. To poll an inbox programmatically, you need a mailbox that exposes a REST interface. Standard IMAP is available for personal accounts, but requires OAuth flows, credential management, and careful scope handling. It is not agent-friendly.

3. Unstructured content. Even when you can receive an email, extracting the OTP or verification link requires parsing free-form text or HTML. Services do not follow a standard. One sends Your code is: 482910. Another buries the link in three layers of tracking redirects inside <a> tags. You need extraction logic per-sender or a general-purpose parser.

4. No ephemeral inbox primitive. Agents need disposable, programmatically-controlled inboxes that can be created on demand, pointed at a specific signup flow, read via API, and discarded. No standard infrastructure provides this at the level of a simple REST call.

The Fix: Programmable Inboxes With Structured Extraction

The conceptual fix has three parts:

Create an inbox on demand — an address that is real (routes actual SMTP traffic) and accessible via REST API without OAuth or manual setup
Wait for email with a timeout — poll the inbox until a message arrives or a deadline is reached
Extract structured data — pull the OTP or verification link from the body in a way the next workflow node can consume

This turns an asynchronous, infrastructure-heavy problem into a synchronous, API-driven one. From the perspective of the n8n workflow, email becomes just another HTTP call.

Practical Implementation

Here is how this works end-to-end using the uncorreotemporal.com API, which exposes real SMTP inboxes over REST.

Step 1 — Create an inbox:

curl -X POST "https://uncorreotemporal.com/api/v1/mailboxes?ttl_minutes=30"

Response:

{
  "address": "mango-panda-42@uncorreotemporal.com",
  "expires_at": "2026-04-18T23:04:00.000000+00:00",
  "session_token": "q7Qq...long_token...1Q"
}

Use address as the email in your signup request. The session_token is what authenticates subsequent reads.

Step 2 — Poll for the verification email:

import re
import time
import requests
from urllib.parse import unquote

BASE = "https://uncorreotemporal.com/api/v1"
address = "mango-panda-42@uncorreotemporal.com"
headers = {"X-Session-Token": "q7Qq...long_token...1Q"}

# Poll until a matching message arrives (up to ~150 seconds)
msg_id = None
for _ in range(30):
    r = requests.get(
        f"{BASE}/mailboxes/{address}/messages",
        headers=headers,
        params={"limit": 20},
    )
    r.raise_for_status()

    target = next(
        (m for m in r.json() if "verify" in (m.get("subject") or "").lower()),
        None,
    )
    if target:
        msg_id = target["id"]
        break

    time.sleep(5)

if not msg_id:
    raise RuntimeError("Verification email did not arrive within timeout")

Step 3 — Extract the link or OTP:

# Fetch the full message
r = requests.get(f"{BASE}/mailboxes/{address}/messages/{msg_id}", headers=headers)
r.raise_for_status()
body = r.json()

content = (body.get("body_text") or "") + "\n" + (body.get("body_html") or "")

# Extract verification link
url_match = re.search(r"https?://[^\s\"'<>]+confirm[^\s\"'<>]*", unquote(content))

# Or extract OTP
otp_match = re.search(r"\b\d{4,8}\b", content)

verification_url = url_match.group(0) if url_match else None
otp_code = otp_match.group(0) if otp_match else None

In n8n, this maps directly to:

An HTTP Request node to create the inbox and get address + session_token
A Loop + Wait pattern with an IF node checking for incoming messages
A Code node doing the regex extraction
The next node consuming verification_url or otp_code

The workflow stays headless. No human inbox involved.

The Real Problem Is Not Reasoning

There is a tendency to attribute agent failures to model quality. The agent "hallucinated," it "misunderstood" the task, it "made a wrong decision."

In the cases described above, the model is not at fault. It reasoned correctly. It identified the right action. It issued the right API call. What failed was the absence of infrastructure to complete that action.

AI agents fail on real-world workflows not because of bad reasoning, but because the interfaces they need to interact with — email inboxes, async callbacks, unstructured content — do not expose a clean, synchronous API. The agent cannot be smarter than the tools it has access to.

Fixing this means treating email as a first-class infrastructure primitive in agent workflows, the same way you treat databases, HTTP APIs, or queues. It requires real inboxes, real SMTP delivery, and a REST interface that agents can call without human intermediaries.

Conclusion

Most gaps in real-world agent performance trace back to the same root: the world is not fully API-accessible. Email is the most common example, but the pattern applies anywhere a workflow depends on an asynchronous external event that the agent cannot observe directly.

The good news is that the infrastructure problem is solvable. Once email becomes a programmable, API-accessible layer, a whole class of workflows — account registration, OTP retrieval, verification flows — becomes automatable without manual intervention.

The more interesting question is: what other asynchronous interfaces are your agents currently hitting a wall on, and is the bottleneck the model or the missing infrastructure?

If you want to explore programmable email for your agent workflows, the REST API is documented at uncorreotemporal.com.

AI Agents Need Real Email Infrastructure

Francisco Perez — Fri, 17 Apr 2026 03:17:18 +0000

The Paradox at the Heart of AI Automation

An AI agent can browse the web, write code, summarize a 300-page PDF, and call APIs on your behalf. It can reason through multi-step problems and generate plans that would take a human hours to produce.

Ask it to create an account on a SaaS platform and it stalls. Not because the task is complex — but because the platform sends a confirmation email, and the agent has no inbox.

This is the gap nobody talks about. AI agents are getting smarter every week, but they still can't complete one of the most basic flows in modern software: email-gated account creation. The intelligence is there. The infrastructure is missing.

The Real Problem: Email Is a Gate, Not a Feature

Email verification is not optional in production systems. It is the primary identity checkpoint for:

Account creation — nearly every SaaS platform requires a confirmed email before granting access
OTP verification — two-factor authentication, magic link login, password reset flows
Transactional onboarding — license keys, trial activation, API credential delivery
Subscription confirmation — billing platforms send confirmation links before activating accounts

When an AI agent needs to interact with any of these systems autonomously, it faces a structural problem. It lacks:

Identity — agents don't have their own email address by default. They borrow one, which creates collisions when running parallel tasks or test suites.

Inboxes — even if you hand an agent an email address, it needs programmatic access to read what arrives. Human inboxes (Gmail, Outlook) require OAuth flows and UI scraping. Neither is designed for machines.

Persistence — the agent needs to know when the email arrives, not just poll indefinitely. Real-time notification matters. Polling with backoff on a consumer webmail service is fragile at best.

Without these three things, any agent that touches email-gated systems is blocked at the first gate.

Current Workarounds (And Why They Fail)

Developers have been improvising solutions for years. None of them are production-grade.

Mocks and stubs skip email delivery entirely in tests. They pass locally and fail in staging because no real SMTP path is exercised. You ship a broken confirmation flow and find out when a user reports it.

Shared inboxes (a team Gmail or a catch-all alias) work for manual testing. They break immediately when multiple agents or test workers run in parallel. Message routing is ambiguous — you cannot guarantee which worker reads which email. And shared inboxes accumulate thousands of messages that have to be manually pruned.

Consumer disposable email services like Mailinator or Guerrilla Mail have no real API. They expose a web UI. To automate them, you need a scraper on top of a scraper — fragile, rate-limited, and frequently blocked by platforms as known spam domains.

Manual flows don't scale. If your CI pipeline needs to verify email-based signup 50 times a day, you cannot have a human in the loop.

The pattern is always the same: workaround works locally, breaks under load, breaks under parallelism, breaks when the target platform updates its UI.

Key Insight: Email Is Not UI. It's Infrastructure.

This is the framing shift that matters.

Most developers treat email verification as part of the user experience — a UI concern, something to mock in tests and tolerate in production. But email is a protocol. SMTP has been running since 1982. It is infrastructure in the same sense that DNS or TCP/IP is infrastructure.

When you need to interact with a system that uses email as a control plane — and virtually every SaaS platform does — you need an email layer that behaves like infrastructure:

Addressable: you can create and destroy addresses on demand
Observable: you can receive events when mail arrives, not just poll
Authenticated: access is controlled per inbox, not shared
Ephemeral: addresses expire cleanly so you don't accumulate noise
Programmable: the entire lifecycle is driven by an API, not a browser

Consumer disposable email services are none of these things. A real temporary email API is all of them.

How uncorreotemporal.com Solves This

uncorreotemporal.com is a programmable disposable email API built as infrastructure from the ground up. The architecture has four layers that work together:

SMTP ingestion — a real SMTP server built on aiosmtpd that receives actual email on port 25. Not a webhook relay, not a polling scraper. When a platform sends a confirmation email, it lands via standard SMTP delivery.

FastAPI backend — an async REST API (FastAPI + SQLAlchemy 2.0 async + PostgreSQL) that manages mailbox lifecycle. You create, read, and delete mailboxes through HTTP endpoints. Mailboxes are per-owner, quota-enforced by plan, and isolated from each other.

Real-time WebSocket stream — when mail arrives, a Redis pub/sub event is published to the channel mailbox:{address}. Any client subscribed to WS /ws/inbox/{address} receives a {"event": "new_message", "message_id": "uuid"} notification immediately. No polling required.

Background expiry loop — core/expiry.py runs an async loop every 60 seconds that marks expired mailboxes is_active=False. Expiration is deterministic: you set the TTL when you create the inbox, and it expires on schedule.

MCP server — an MCP server (FastMCP) that wraps the entire email flow as tools for AI agents. Tools include create_signup_inbox, wait_for_verification_email, get_latest_email, extract_otp_code, extract_verification_link, and complete_signup_flow. An agent can complete the entire verification cycle in one tool call.

A Real Example: AI Agent Completing an Email Signup Flow

Here is a working Python example using the REST API directly. This is the same flow the MCP complete_signup_flow tool executes internally.

import time
import httpx
import re

BASE_URL = "https://uncorreotemporal.com"
API_KEY = "your-uct-api-key"

headers = {"Authorization": f"Bearer {API_KEY}"}

# Step 1: Create a temporary inbox
resp = httpx.post(f"{BASE_URL}/api/v1/mailboxes", headers=headers)
resp.raise_for_status()
mailbox = resp.json()

email = mailbox["address"]
expires_at = mailbox["expires_at"]
print(f"Inbox created: {email} (expires: {expires_at})")

# Step 2: Use this address to sign up somewhere
print(f"Using {email} to sign up on the target platform...")

# Step 3: Poll for the verification email
message_id = None
for attempt in range(30):  # 90 seconds max
    time.sleep(3)
    resp = httpx.get(
        f"{BASE_URL}/api/v1/mailboxes/{email}/messages",
        headers=headers,
    )
    messages = resp.json()
    if messages:
        message_id = messages[0]["id"]
        print(f"Email arrived: {messages[0]['subject']}")
        break

if not message_id:
    raise RuntimeError("Verification email did not arrive within timeout")

# Step 4: Read the full message
resp = httpx.get(
    f"{BASE_URL}/api/v1/mailboxes/{email}/messages/{message_id}",
    headers=headers,
)
message = resp.json()
body = message.get("body_text") or message.get("body_html") or ""

# Step 5: Extract OTP or confirmation link
otp_match = re.search(r"\b(\d{4,8})\b", body)
link_match = re.search(r"https?://[^\s"'<>]+confirm[^\s"'<>]+", body)

if otp_match:
    print(f"OTP extracted: {otp_match.group(1)}")
if link_match:
    print(f"Verification link: {link_match.group(0)}")

# Step 6: Clean up
httpx.delete(f"{BASE_URL}/api/v1/mailboxes/{email}", headers=headers)
print("Inbox deleted.")

This is a full, copy-paste ready implementation. The same logic runs inside the MCP complete_signup_flow tool — but from the agent's perspective, the entire flow collapses to a single tool call:

# Via MCP (for Claude, GPT-4 tools, or any MCP-compatible agent)
result = await mcp.complete_signup_flow(
    service_name="github",
    timeout_seconds=90,
)

print(result["email"])              # the inbox address used
print(result["verification_link"])  # extracted confirmation URL
print(result["otp_code"])           # extracted numeric code if present

The MCP tool handles inbox creation, waiting, reading, extraction, and returns a structured result. The agent never touches the email protocol directly.

Why This Matters for AI Agents Specifically

The shift toward autonomous AI agents changes what infrastructure means.

When a human uses a SaaS tool, they provide their identity: their email, their phone, their browser session. The system is designed for a single authenticated human interacting over time.

When an AI agent uses a SaaS tool, it needs to provision identity on demand. It may need to sign up for ten accounts in parallel, verify each one, complete onboarding, and then discard the accounts. It may need to run this flow in CI every night. None of this maps to a human identity model.

Email gives agents an identity layer that is:

Ephemeral by design — temporary inboxes expire automatically, leaving no permanent footprint
Parallel-safe — each run gets its own isolated inbox with its own authentication token
Programmatically observable — the agent can subscribe to real-time events instead of polling
Compatible with real systems — because it uses standard SMTP, every platform that sends email will work

This is not about teaching agents to use email like a human. It is about giving agents access to email as infrastructure — the same way they have access to HTTP clients, databases, and file systems.

Developer Use Cases

The immediate applications are practical and concrete.

CI/CD email testing — your pipeline creates a real inbox, triggers a signup flow on staging, reads the confirmation email, and asserts on the link format or OTP structure. No shared accounts, no mocked delivery. The test exercises the real SMTP path.

End-to-end testing with Playwright or Selenium — browser automation scripts that need to complete signup flows can receive real emails. The test gets a fresh inbox per run, uses the address in the form, reads the verification email, and clicks the link.

AI agent onboarding flows — an agent tasked with "create an account on platform X and retrieve the API key" can complete the full flow autonomously: inbox creation, signup form submission, email reading, OTP entry, API key extraction.

Automated scraping with auth — data collection pipelines that require account creation at each target site. Each run gets a fresh identity and a fresh inbox.

Parallel test isolation — multiple test workers run simultaneously without shared state. Each worker creates its own mailbox, verifies against it, and deletes it. No race conditions, no message routing ambiguity.

Agent-assisted QA — QA automation agents that verify transactional email content (formatting, links, subject lines) as part of a deployment gate. Every deploy triggers a full email lifecycle check.

Conclusion

The current conversation about AI agents focuses almost entirely on reasoning capability: how well the model understands instructions, how reliably it uses tools, how it handles ambiguity. That is the right conversation to have — but it is incomplete.

Agents fail not just because they reason poorly. They fail because they cannot interface with real-world systems that require an identity to function. Email verification is not an edge case. It is the default access control mechanism for virtually every SaaS platform on the internet.

The solution is not to mock it away or build brittle scrapers on top of consumer disposable email services. The solution is to treat email as infrastructure — addressable, observable, authenticated, and ephemeral — and expose it through an API that agents can call directly.

AI agents do not need more intelligence to complete an email signup flow. They need a real inbox.

uncorreotemporal.com is that inbox.

How to Test Email Signup Flows in CI/CD Pipelines

Francisco Perez — Mon, 30 Mar 2026 22:19:52 +0000

The Pain Every CI Pipeline Knows

It works locally. The signup form submits, the confirmation email arrives in your inbox, you paste the OTP, it verifies. Ship it.

Then CI runs. The test sends the signup request, polls... and times out. Or worse: it passes because you mocked the email sender and never actually tested that the email arrives, renders correctly, or contains a working code.

Email signup flows break in CI for a handful of predictable reasons:

Shared inboxes — two parallel test runs both register and poll the same address. Whichever test gets the email first passes; the other times out.
Mocked senders — you assert that send_email() was called, not that an email was received. Template bugs, SMTP credential expiry, and malformed links all pass through silently.
Brittle fixtures — hardcoded email addresses that accumulate stale messages across runs.
No isolation — there's no API to create a fresh inbox per test run, so you bolt on a shared test account and cross your fingers.

The fix is not a better mock. It's a real, isolated, programmable inbox that your test owns for its lifetime.

Quick Start

All examples in this article are from the temporary-email-api-examples repo. The python-example/ folder is a single-file script that demonstrates the full flow with plain requests — no extra libraries required.

Set two environment variables before running:

export UCT_API_BASE_URL="https://uncorreotemporal.com/api/v1"
export UCT_EMAIL_API_KEY="your_api_key_here"

Then:

git clone https://github.com/francofuji/temporary-email-api-examples
cd temporary-email-api-examples/python-example
pip install requests
python main.py

You will see a temporary inbox created, a polling loop start, and — once you trigger a real email to the address — an OTP extracted and printed.

The Flow: Create Inbox - Wait for Email - Extract OTP

The pattern is three steps. Here is how the example implements each one.

1. Create the Inbox

import os, requests

API_BASE_URL = os.getenv("UCT_API_BASE_URL")
API_KEY = os.getenv("UCT_EMAIL_API_KEY")
HEADERS = {"X-API-Key": API_KEY}

create_resp = requests.post(f"{API_BASE_URL}/inboxes", headers=HEADERS, timeout=10)
create_resp.raise_for_status()

inbox = create_resp.json()
inbox_id = inbox.get("id")

One POST, one inbox. No signup flow, no shared state. The inbox_id is the key you use for the next two steps.

2. Poll for Messages

import time, re

pattern = re.compile(r"\b(\d{6})\b")
start_time = time.time()

while True:
    if time.time() - start_time > 60:
        raise SystemExit("Timed out waiting for OTP")

    try:
        msg_resp = requests.get(
            f"{API_BASE_URL}/inboxes/{inbox_id}/messages",
            headers=HEADERS,
            timeout=10,
        )
        if msg_resp.status_code >= 500:
            time.sleep(3)
            continue
        msg_resp.raise_for_status()
        messages = msg_resp.json()
    except requests.RequestException as exc:
        print(f"Request failed: {exc}. Retrying...")
        time.sleep(3)
        continue

    if not messages:
        time.sleep(3)
        continue

The loop handles three distinct cases: server errors (5xx, which you retry), request failures (network blips), and an empty inbox (normal while waiting). Separating these is what makes polling reliable in CI — you don't bail on transient failures.

3. Extract the OTP

    body = messages[0].get("body", "")
    match = pattern.search(body)
    if match:
        otp = match.group(1)
        print(f"OTP found: {otp}")
        break

The regex \b(\d{6})\b matches any standalone 6-digit sequence. Adjust the pattern to match your application's format.

CI/CD Tips

Set an explicit timeout and fail loudly. The example uses 60 seconds. In CI, an infinite loop or a silently hanging test is worse than a hard failure. If the email doesn't arrive in 60 seconds, something upstream is broken — raise, don't sleep forever.

Use fixed poll intervals, not adaptive backoff. Poll every 3 seconds. Predictable timing makes failures easier to diagnose.

Handle 5xx separately from 4xx. A 500 from the messages endpoint is probably transient. A 401 or 404 means your credentials or inbox ID are wrong — retrying won't help. The example retries 5xx and raises immediately on 4xx via raise_for_status().

Don't share inbox IDs across test cases. Create one inbox per test run.

Store credentials in CI secrets, not in code.

# GitHub Actions
env:
  UCT_API_BASE_URL: ${{ vars.UCT_API_BASE_URL }}
  UCT_EMAIL_API_KEY: ${{ secrets.UCT_EMAIL_API_KEY }}

Why This Works in CI

Most email testing approaches fail in CI because they depend on something external: a shared inbox, a stubbed SMTP server, or a hardcoded test account that accumulates state across runs.

This approach is stateless from the pipeline's perspective. Each run calls POST /inboxes, gets a fresh address and ID back, and owns that inbox exclusively until the test exits or the TTL expires. There's nothing to clean up, nothing to coordinate between parallel jobs, and no leftover messages from a previous run to confuse the polling logic.

The inbox also receives real SMTP delivery — the same delivery path your production email goes through. If your email provider is down, your template is broken, or your SMTP credentials expired, the test will fail. That's the point. A test that can't catch those failures isn't testing email; it's testing whether your mock function was called.

Conclusion

Email signup testing is broken in most CI pipelines not because it's technically hard but because the default tools — mocks, shared inboxes, SMTP dev servers — don't give you the properties you need: isolation, real delivery, and an API to read the result programmatically.

The pattern in this article is straightforward: create a dedicated inbox per test, poll for the message with a hard timeout, extract the OTP or link, and proceed. The Python example is a working implementation you can drop into any pipeline today.

Next steps:

Browse the full temporary-email-api-examples repo for Node.js, shell/cURL, Playwright, and pytest examples
Get your API key at uncorreotemporal.com
Wrap the flow in a pytest fixture for per-test inbox isolation in larger test suites

DEV Community: Francisco Perez

The App That Remembers Your Doctor's Appointment and Forgets Your Name

Address Space Exhaustion in Production

A generator with 36,000 possible outputs

Why address space exhaustion is invisible until it isn't

Lie #1: the analytics said 18 errors

Lie #2: the container logs said 4%

Trusting the instrument over the arithmetic

The root cause: nothing was ever released

The fix

Address space exhaustion is not an email problem

What I'd take away

Email Verification Bots with Playwright

Why email verification breaks no-code registration bots

How Claude Code drives Playwright for email verification

Setting it up (one command, no code)

Inside a Playwright email verification run

Real business uses for a registration bot

A quick note on responsible use

Vibe coding y email: el muro invisible

El momento exacto en que todo se detiene

Por qué el agente no puede manejar esto solo

La solución: UnCorreoTemporal + MCP

Tutorial: MCP en Claude Code (5 minutos)

Paso 1 - Consigue tu API key

Paso 2 - Registra el servidor MCP

Paso 3 - Reinicia Claude Code

Paso 4 - Dale instrucciones al agente

Tutorial: REST API directa (para cualquier agente o script)

Crear un buzón

Esperar y leer el email

El flujo completo en un vistazo

Cuándo usar esto (y cuándo no)

Un ejemplo real de la vida vibe coder

Registration Bot: Claude Code + Temporary Email

Registration Bot: Claude Code + Temporary Email

Why registration automation needs a real inbox

Prerequisites

Step 1 — Create a temporary inbox via MCP

Step 2 — Navigate to the signup form and fill fields

Step 3 — Submit the form and wait for the verification email

Step 4 — Extract the confirmation link/OTP and complete registration

Error handling patterns (slow email delivery, retry logic, timeouts)

Making the agent resilient in production

MCP vs REST API for AI Agent Email: When to Use Each

What's the difference, exactly?

Latency and round-trips

Tool call ergonomics and context usage

Debugging experience

When REST API wins

When MCP wins

Decision matrix

How to get started with both

Conclusion

How to Use Claude Code as an AI Agent with Email Verification

What You'll Build

Prerequisites

Step 1 — Configure the MCP Server in claude_desktop_config.json

The quick way: claude mcp add

What this does

Verify it loaded

Step 2 — Create a Disposable Inbox

Step 3 — Register on the Target Service

Step 4 — Wait for the Verification Email

Step 5 — Extract the OTP with Regex

Doing it yourself in Python

Step 6 — Complete the Registration

Putting It All Together — A Complete Agent Loop Prompt

Why the prompt is structured this way

Handling Failure Cases

Email never arrives

OTP already expired by the time you submit it

Service blocks the email domain

Beyond OTPs — Magic Links and Multi-Step Flows

Multi-step flows

The complete_signup_flow shortcut

Try It Yourself

Why Every AI Agent Stack Needs an Email Verification Layer

What Changed — From Chatbots to Agents That Actually Do Things

Email Verification Is the Silent Killer of Agentic Flows

The quick way: `claude mcp add`

The `complete_signup_flow` shortcut