Your AI agent can fill in a signup form. It can't read the verification email

Недавно столкнулся с классической проблемой: попросил Claude или Codex заполнить форму регистрации — без проблем. Но как только дошли до верификации почты — капут. «Проверьте почту и введите код», — пишет сервис. А у агента нет ни inbox, ни руки, чтобы скопировать код. В итоге AI-бот сдается и просит меня вмешаться.

Это типичная боль при интеграции AI-агентов в реальные флоу с двухфакторной аутентификацией или подтверждением email. Разобрался, как можно автоматизировать этот этап с помощью MCP-сервера — и что важно учесть при проектировании инструментов для LLM, чтобы они не сливались на простом ожидании почты.

Где затык: AI может заполнить форму, но не проверить почту

Если попросить Claude, Cursor или Codex зарегистрироваться на сайте, они без вопросов заполнят поля, кликнут «Submit» и даже прочитают ответ от сервера. Но дальше — «Мы отправили код на email» — и всё. Агенты не умеют мониторить почтовый ящик, даже если это их собственный.

Отсюда две очевидные задачи:

Создать временный почтовый ящик, куда придёт письмо.
Автоматически прочитать письмо, вытащить код и завершить регистрацию.

Пункты 2 и 4 (заполнение формы и ввод кода) LLM обычно берут на себя. А вот создание почты и чтение писем требуют специальных тулов.

MCP-сервер как мост между AI и почтой

MoeMail — open-source сервис временной почты с MCP-сервером в npm-пакете @moemail/mcp. Его можно запускать локально через npx, никаких лишних деплоев и инфраструктуры.

MCP (Meta-Command Protocol) — это протокол, который позволяет LLM вызывать внешние инструменты как команды с JSON-интерфейсом, получать данные и контролировать поток.

Для Claude Desktop, Cursor и Windsurf конфиг одинаков:

{
  "mcpServers": {
    "moemail": {
      "command": "npx",
      "args": ["-y", "@moemail/mcp"],
      "env": {
        "MOEMAIL_API_KEY": "mk_••••••••••••"
      }
    }
  }
}

В Claude Code всё проще — одна команда:

claude mcp add moemail -e MOEMAIL_API_KEY=mk_•••••••••••• -- npx -y @moemail/mcp

MoeMail MCP регистрирует набор инструментов:

create_email — создать ящик
wait_for_email — ждать письмо с таймаутом
list_messages — список писем
read_message — читать письмо
delete_message и delete_email — удалять письма и ящик
send_email — отправить письмо (редко нужно в таком сценарии)
list_emails — посмотреть список ящиков

Практический кейс: регистрация с проверкой кода

Представим, что мы хотим, чтобы агент зарегистрировался на example.com, получил код из письма и ввел его.

Сценарий:

Агент вызывает:

create_email { "expiry": "1h" }

Получает:

{ "id": "k3f…", "address": "x7q2m9@moemail.app", "expiresAt": "…" }

Вставляет адрес x7q2m9@moemail.app в форму, отправляет.

Ждет письмо:

wait_for_email { "emailId": "k3f…", "timeoutSec": 90 }

После 12 секунд приходит:

{ "status": "received", "elapsedSec": 12,
  "message": { "messageId": "m81…", "from": "no-reply@example.com",
               "subject": "Your code is 482913", "receivedAt": "…" } }

Читает письмо, парсит код 482913, вводит его в форму.
Удаляет почту:
```
delete_email { "emailId": "k3f…" }
```

Все просто, но ключевой момент — инструмент wait_for_email. Не стоит делать его немедленным чекером почты, который либо пуст, либо нет. LLM не умеют ждать и терпеть — они либо сдаются, либо начинают фантазировать, почему письмо не пришло.

wait_for_email блокирует до 90 секунд, периодически опрашивая ящик. Если письмо не пришло, он возвращает не ошибку, а статус "timeout". Это сигнал для агента: «Пока нет, но пробуем еще». Ошибка — это стоп, а timeout — ожидание.

Что важнее багов: дизайн инструментов для LLM

Возникает общий инсайт: инструменты для LLM надо проектировать так, чтобы возвращать ожидаемые ситуации как данные, а не ошибки. Ошибки — для настоящих проблем, типа неправильного API-ключа.

LLM плохо справляются с контролем повторных вызовов, таймаутов и асинхронностью, если только это не явно заложено в протокол. MCP и подобные схемы с JSON-интерфейсом и статусами помогают сгладить этот момент.

CLI для тех, кто не в чате

MoeMail CLI — инструмент для shell и CI, где каждый вызов возвращает JSON. Это удобно для скриптов:

npm i -g @moemail/cli
moemail config set api-key mk_••••••••••••

moemail create --expiry 1h --json
# возвращает JSON с адресом

moemail wait --email-id k3f… --timeout 120 --json
moemail read --email-id k3f… --message-id m81… --json
moemail delete --email-id k3f…

Коды выхода — 1 для runtime ошибок (включая таймаут ожидания), 2 — для конфигов и авторизации. Это даже удобнее, чем парсить вывод.

Кейс в продакшене: агентный QA и тестирование

Этот паттерн отлично подходит для:

Автоматического тестирования регистрации и онбординга после деплоя.
QA-сценариев с подтверждением почты, сбросом пароля, сменой email.
Экспериментов с новыми сервисами без риска спамить свой основной почтовый ящик.

Но не стоит воспринимать это как способ фармить бесплатные аккаунты — многие сервисы это запрещают и активно мониторят.

Выводы и что попробовать дальше

Если в вашей работе есть задачи, где AI-агент должен пройти через email-подтверждение — MCP-сервер с MoeMail или аналогом — это рабочее решение.
Ключ к успеху — правильно спроектировать инструменты: возвращать таймауты как статус, а не ошибку.
CLI-обертка полезна для интеграции в CI/CD, где нет UI.
Бесплатный тариф MoeMail не включает API-вызовы, так что планируйте бюджет на polling.
При желании можно поднять свой MCP-сервер на Cloudflare Workers, чтобы не зависеть от сторонних сервисов.

Пробуйте встроить этот подход в свои agentic workflows, чтобы AI перестал тормозить на почте и стал действительно автономным в реальных сценариях регистрации и верификации.

Попробуй сам: Cursor — AI-редактор для разработчиков.

Источник: https://dev.to/beilunyang/your-ai-agent-can-fill-in-a-signup-form-it-cant-read-the-verification-email-54o0