AI Agents & MCP

Why agents need email

An agent acting on the web keeps hitting the same wall: every service wants an email address. Sign-up forms, verification links, one-time codes, password resets, receipts. DevInbox gives your agent an inbox it can create in milliseconds and read as structured data — on devinbox.io or on your own verified domain.

Inboxes can be temporary (throwaway, for a single flow) or persistent — so the account your agent registered today still receives its password reset next month.

Connect the MCP server (hosted)

Zero install — point any MCP client at the hosted endpoint and pass your DevInbox API key as a bearer token. With the Claude Code CLI:

claude mcp add --transport http devinbox https://mcp.devinbox.io \
  --header "Authorization: Bearer YOUR_API_KEY"

Or in any MCP client configuration (Claude Desktop, Cursor, LangGraph, CrewAI, ...):

{
  "mcpServers": {
    "devinbox": {
      "type": "http",
      "url": "https://mcp.devinbox.io",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Available tools

The canonical flow: sign up somewhere, unaided

The pattern behind most agent email work — registering for a third-party service and getting past email verification without a human:

1. create_inbox()                                   -> agent-3f9c@devinbox.io
2. [browser fills the signup form with that address]
3. wait_for_email(inbox_key, timeout_s=90)          -> "Your verification code is 482913"
4. create_template("saas-otp",
     body_pattern="Your verification code is {{code}}")
5. get_last_email(inbox_key, template="saas-otp")   -> { "code": "482913" }
6. [agent completes signup]

Steps 4–5 are the interesting part: when the agent meets a sender it has never seen, it defines its own extraction template at runtime — and can dry-run it with test_template before saving.

Sending and replying

Every persistent inbox can send, not just receive. The From address is the inbox's own address ({key}@devinbox.io), so your agent sends as itself over SPF/DKIM-authenticated infrastructure — no separate sending domain to warm up. In MCP it's a single tool, which closes the loop in one place: wait_for_email → act → send_email.

send_email(inbox_key, to=["billing@acme.com"],
           subject="Re: invoice #4021", body="Approved — thanks.",
           in_reply_to=msg_id)                 -> sent from agent-3f9c@devinbox.io, threaded

Pass in_reply_to — the id of a message the inbox previously received — and DevInbox writes real In-Reply-To/References headers so your reply lands in the recipient's existing thread. Over REST it's POST /messages/{key}/send with your API key in the X-Api-Key header; the key must carry the send scope. The body takes to plus optional cc/bcc (50 recipients combined), subject, and text and/or html.

Run locally over stdio

Prefer not to route mail metadata through the hosted bridge? The server also runs locally over stdio, taking its API key from the DEVINBOX_API_KEY environment variable. The devinbox-mcp package is coming soon — contact us for early access. Config shape:

{
  "mcpServers": {
    "devinbox": {
      "command": "devinbox-mcp",
      "args": ["--stdio"],
      "env": { "DEVINBOX_API_KEY": "YOUR_API_KEY" }
    }
  }
}

API key scopes

Agents run unattended, so give them least-privilege keys. Scopes are set per API key in the dashboard; a key can also be confined to a single project so each agent (or fleet) is isolated.

Prefer the raw REST API?

Every MCP tool is a thin wrapper over the public API, so anything an agent can do, your code can do directly: POST /mailboxes, GET /messages/{key}/wait, POST /messages/{key}/send, key-addressed template CRUD, and more.