AutoGPT today is mostly the AutoGPT Platform: you build an agent as a graph of blocks, where each block does one thing and passes its outputs along wires. The original command-line agent still lives in the repository's classic directory. This post covers the Platform, where there are two ways to give an agent a Lumbox inbox: the MCP Tool block and the Send Web Request block.

Which one fits depends on who decides the steps. A signup flow always runs the same sequence (make an address, submit a form, wait for a code, clean up), so a fixed chain of HTTP blocks is the predictable choice. An agent that should decide for itself when to check mail is a better fit for MCP.

Path 1: a fixed chain of Send Web Request blocks

The Send Web Request block takes a URL, a method, headers and a body, and it has separate outputs for a successful response, a client_error (any 4xx), a server_error (5xx) and a general error. That split is what makes it work well with the Lumbox API, because a timeout on a long poll comes back as a 4xx.

These are the four calls the chain makes, written out as raw HTTP:

# 1. Create an inbox (201)
POST https://api.lumbox.co/v1/inboxes
X-API-Key: ak_your_key
Content-Type: application/json

{}

# -> {"id": "inb_...", "address": "agent_...@trylumbox.com", "status": "ACTIVE", ...}

# 2. Wait up to 60 seconds for a code from the service (200 or 408)
GET https://api.lumbox.co/v1/inboxes/{inbox_id}/otp?from=example.com&timeout=60
X-API-Key: ak_your_key

# -> {"code": "847291", "all_codes": ["847291"], "from": "...", "subject": "...",
#     "expires": null, "email_id": "eml_..."}

# 3. Or, for services that verify by link, list what has arrived
GET https://api.lumbox.co/v1/inboxes/{inbox_id}/emails?from=example.com
X-API-Key: ak_your_key

# 4. Delete the inbox when the run is over
DELETE https://api.lumbox.co/v1/inboxes/{inbox_id}
X-API-Key: ak_your_key

In the builder, that becomes:

  1. Send Web Request, method POST, JSON body {}, header X-API-Key. Wire response into two Find In Dictionary blocks that pull out id and address. If your version passes the body through as text, put a JSON Decoder block in between.
  2. Your signup step, whatever fills the form, receives address.
  3. Fill Text Template builds the /otp URL from the inbox id, then a second Send Web Request does the GET. response goes to another Find In Dictionary for code.
  4. A final Send Web Request with method DELETE removes the inbox.

What the waiting call actually does

GET /v1/inboxes/:id/otp is a long poll. The server holds the request open and checks the inbox once a second. It returns as soon as it finds an email that arrived in the last five minutes, is categorised as verification, matches the from substring, and contains a code. If none turns up before timeout seconds (default 30, maximum 120), it returns HTTP 408 with {"error": "No OTP found", "timeout": 60}.

In the block graph, that 408 leaves through client_error, not response, so the blocks wired to response do not run. Connect client_error to something: a retry after a "resend code" click, or an Agent Output that reports the failure. Keep timeout at 60 or below unless you know your AutoGPT deployment allows longer outbound requests; the Lumbox side accepts up to 120.

The five minute lookback helps here. The form submission and the /otp call do not need to be perfectly ordered, because an email that landed a few seconds before the call is still found. It also means one inbox should serve one signup: a second signup into the same inbox within five minutes can pick up the first service's code.

Production extraction finds digit-only codes of 4 to 8 characters in the subject and plain-text body. Services that send a link, or a code with letters in it, need step 3 instead: the email list returns full emails, newest first, with parsed.verification_links and the text body.

Path 2: the MCP Tool block

The MCP Tool block connects to any MCP server by URL. It sends initialize and tools/list to discover the tools and their input schemas, then calls one with tools/call. Its inputs are server_url, selected_tool and tool_arguments.

server_url:     https://mcp.lumbox.co/mcp
selected_tool:  get_otp
tool_arguments: {"inbox_id": "inb_...", "from": "example.com", "timeout": 60}

The hosted Lumbox server exposes more than 80 tools, including create_inbox, get_otp, wait_for_email, list_emails and send_email. Authentication is where the two sides need to meet. AutoGPT's block handles protected servers with an OAuth 2.0 flow rather than a static header. Lumbox answers initialize and tools/list without a key, returns 401 on tool calls with a WWW-Authenticate header pointing at its OAuth metadata, and supports dynamic client registration with PKCE. This pairing has not been tested end to end, so if the connect step fails in your AutoGPT version, Path 1 needs nothing but the API key header.

For an agent that picks its own steps, the Orchestrator block lets an LLM choose which connected blocks to call and feeds the results back to it. That suits reading and triaging mail. For the signup sequence above, the fixed chain avoids paying for an LLM decision at every step.

Sending

Sending is one more Send Web Request block: POST to /v1/inboxes/{inbox_id}/send with a JSON body of to, subject and text. A successful send returns 201 with email_id, thread_id and message_id. The free plan allows 3 sends a minute and 100 a month, and a new free account without a verified domain can send 5 in its first hour; going over returns 429, which also leaves through client_error.

A note on untrusted mail

An inbox that an agent reads is an input channel anyone can write to. Lumbox wraps text_body in an untrusted-content marker and strips scripts, event handlers and iframes from html_body. That labels the content; it does not stop a model from following instructions written in it. If your graph acts on email content (a digest agent, or one that takes task requests by email), filter on the sender before anything reaches an LLM block, and call GET /v1/emails/:id/safety for a prompt-injection and phishing score on messages you are unsure about. The parsed fields such as code and verification_links are short regex extractions rather than free text, which leaves far less room for injected instructions. A link still points wherever the sender chose, so check its domain before a browser block opens it.

The full list of endpoints and fields is in the API reference, and the MCP docs cover connecting other clients to the same server.