ZeroDrop

zerodrop-mcp

Email verification for AI agents — an MCP server that gives Claude, Cursor, Claude Code, and any MCP client disposable email inboxes with auto-extracted OTPs and magic links.

Your agent tests your app's signup. The app sends a verification code. Without an inbox it can read, the agent is stuck. With zerodrop-mcp:

Agent: generate_inbox()

→ swift-x7k29ab@zerodrop-sandbox.online

Agent: [fills the signup form with that address]

Agent: wait_for_email(inbox, require_otp: true) → { "otp": "847291", "subject": "Verify your email", ... }

Agent: [enters 847291 — flow complete]

No Docker. No SMTP. No signup to try: without an API key, one sender can reach 5 different inboxes a day. A free key lifts that.

Install

Claude Code

claude mcp add zerodrop -- npx -y zerodrop-mcp

Claude Desktop

Add to claude_desktop_config.json:

{

"mcpServers": { "zerodrop": { "command": "npx", "args": ["-y", "zerodrop-mcp"] } } }

Cursor

Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{

"mcpServers": { "zerodrop": { "command": "npx", "args": ["-y", "zerodrop-mcp"] } } }

Tools

generate_inbox

Creates a disposable email address. Local and instant — no network request.

Returns the inbox address. With a key from zerodrop.dev/keys in ZERODROP_API_KEY, the name starts with your key's prefix (k7x2-myapp-swift-x7k29ab) and only your key can read it. Without one, a prefix whose part before the first hyphen is four letters and digits, at least one of each (app1, app1-web), goes after the adjective instead (swift-app1-web-x7k29ab), so the inbox can't fall under someone's account.

wait_for_email

Blocks until a matching email arrives, then returns it with the OTP and magic link already extracted — the agent never parses HTML or regexes a body.

Returns:

{

"from": "noreply@yourapp.com", "subject": "Your verification code", "received_at": "2026-07-18T12:34:56Z", "otp": "847291", "magic_link": null, "body_preview": "Your code is: 847291..." }

Without an API key, one sender can reach 5 different inboxes a day. If ZeroDrop held the email because its sender passed that, wait_for_email returns at once (0.3.0 or later) with an error instead of waiting for the timeout:

{ "error": "held", "message": "ZeroDrop held an email from yourapp.com to this inbox. The email was not stored. …" }

check_inbox

Non-blocking snapshot of the inbox — recent emails with extracted fields, or an empty list. A notice that ZeroDrop held an email appears as { "held": true, "received_at": "…", "message": "…" }.

What agents use this for

• Testing auth flows end to end — signup → OTP → verified, driven entirely by the agent
• QA automation — Claude Code writing and running Playwright tests that need real inboxes
• Development — "sign up for my own app and tell me if the verification email works"

How it works

Emails sent to a generated inbox are caught at Cloudflare's edge by ZeroDrop's open-source worker. OTPs and magic links are extracted at the edge before your agent reads them. On the free tier, an inbox is deleted 30 minutes after its latest email.

Configuration

Environment variables (set in your MCP client config):

{

"mcpServers": { "zerodrop": { "command": "npx", "args": ["-y", "zerodrop-mcp"], "env": { "ZERODROP_API_KEY": "your-key" } } } }

Writing tests instead?

If you're generating test code rather than driving flows live, use the SDKs directly:

npm · PyPI · Go · RubyGems · Packagist · JitPack · GitHub Action

AI coding assistant context: docs.zerodrop.dev/ai-coding

Security

• The server makes requests only to ZERODROP_BASE_URL (zerodrop.dev by default) — nothing else
• Inbox generation is fully local
• Two runtime dependencies: the official MCP SDK and zod
• Report issues: founder@zerodrop.dev

License

MIT — zerodrop.dev