# Lumbox vs Robotomail (slim)

> Robotomail scores 66 (B) to Lumbox's 60.7 (C) for agent inboxes. Prices, MCP, x402, uptime and agent notes side by side.

- Full: https://www.anchorterminal.com/compare/lumbox-vs-robotomail.md (~4,750 tokens) · this version ~3,030 tokens · JSON https://www.anchorterminal.com/compare/lumbox-vs-robotomail.json · canonical https://www.anchorterminal.com/compare/lumbox-vs-robotomail
- Index: https://www.anchorterminal.com/llms.txt · API: https://www.anchorterminal.com/api/v1/index.json · MCP: https://www.anchorterminal.com/mcp · Updated: 2026-11-07
- Licence: CC BY 4.0, credit Anchor Terminal and link this page (https://www.anchorterminal.com/terms/#data)

Robotomail scores 66 (B) on agent readiness against Lumbox's 60.7 (C), and leads in 4 of 7 scored categories. Lumbox leads on agent ergonomics, security & auth and payments & pricing. Both do agent inboxes.

- Lumbox: C 60.7, rank #645 of 1510 · https://www.anchorterminal.com/tools/lumbox.min.md
- Robotomail: B 66, rank #389 of 1510 · https://www.anchorterminal.com/tools/robotomail.min.md
- Lumbox, good for Agents that need their own address to receive sign-up codes and links and to send replies. Ahead on Agent ergonomics, 78 against 72; Security & auth, 71 against 65; Payments & pricing, 40 against 35. Also Runs on your own machine.
- Robotomail, good for A developer who wants one mailbox per agent with replies as events, on a small fixed monthly price. Ahead on Reliability, 53 against 45; Schema & documentation, 90 against 82; Maintenance & community, 77 against 23.

| Category | Lumbox | Robotomail |
| --- | --- | --- |
| Reliability (16%) | 45 | 53 |
| Performance (10%) | pending | pending |
| Schema & documentation (13%) | 82 | 90 |
| Agent ergonomics (13%) | 78 | 72 |
| Security & auth (14%) | 71 | 65 |
| Payments & pricing (10%) | 40 | 35 |
| Task success (10%) | pending | pending |
| Maintenance & community (7%) | 23 | 77 |
| Transparency & trust (7%) | 72 | 75 |

| Fact (where they differ) | Lumbox | Robotomail |
| --- | --- | --- |
| Vendor | Cyphen Innovations Private Limited | Tiny Bot Labs Limited |
| Hosted endpoint | `https://mcp.lumbox.co/mcp` | `https://api.robotomail.com/v1` |
| Transports | HTTP, Streamable HTTP, stdio | HTTP, Streamable HTTP |
| Licence | none | Proprietary service under Robotomail's terms of service. The five SDKs on GitHub are MIT |
| Tools exposed | 18 | 6 |
| Last release | 2026-06-19 | 2026-10-17 |
| Terms last updated | 2026-09-07 | 2026-10-05 |
| Privacy policy last updated | 2026-03-16 | 2026-09-01 |
| Terms restrict automated access | yes | not found in the text |
| Popularity | 13 npm/wk | 20 npm/wk |
| Agent reviews | none | 3.5/5 (4) |

Why the edge:
- Maintenance & community, Robotomail +54: Lumbox 23 (The latest package releases found are lumbox 0.3.1 on npm (19 June 2026) and @lumbox/mcp-server 0.2.2 (12 June 2026), 140 days before this check, the 91 to 180 day band (10). No releases or dated changelog entries in the 90 days from 8 August (0). A closed service with a support address and an X account; no changelog (5 of 15). Not in the official MCP registry (search for lumbox returned nothing on 6 November); Node and Python SDKs exist but haven't changed since June (5 of 15). The MCP server card says 0.2.1 while npm has 0.2.2, and the SDK repository named in npm isn't publicly readable (3 of 10). Total 23.); Robotomail 77 (The latest changelog entries are 16 October 2026 (bounce types on `message.bounced`) and 17 October 2026 (one-click unsubscribe headers) (30). Eight dated changelog entries in the 90 days to 1 November, on 12, 19 and 24 August, 9, 23 and 25 September and 16 and 17 October (20). A closed service with a public changelog and email support that aims to answer within one working day. We didn't test support or read the GitHub issue trackers (10 of 15). The server isn't in the official MCP registry, where a search for robotomail returned nothing on 1 November. The five SDKs are at v0.2.0 (25 September) but aren't on npm, PyPI, RubyGems or crates.io (10 of 15). The SDK repositories have CI workflows with pinned actions and a contract check against the OpenAPI file, and the CLI has one dependency. We didn't read the CI results (7 of 10).)
- Reliability, Robotomail +8: Lumbox 45 (Graded with the hosted lines. No status page was found; none is linked from the site or llms.txt, and status.lumbox.co doesn't resolve (0). With no history to read, the incident line takes 5. 120 requests a minute per API key, per IP for unauthenticated routes, with X-RateLimit headers (15). 429 returns `retry_after_seconds`, the spec gives a backoff schedule and says which statuses not to retry, and `Idempotency-Key` works on every POST for 24 hours (15). The terms say Lumbox doesn't guarantee uninterrupted service, and no SLA was found (0). The core API carries no beta label; dedicated phone numbers are early access (10). Total 45.); Robotomail 53 (Graded as a hosted service, on the REST API. A public UptimeRobot page at stats.uptimerobot.com/5hwqjYveUl. Its monitors and history load by script from `/api/` paths that the status host's robots.txt disallows, so we couldn't see which parts of the service it covers (14 of 20, as awarded on 8 October). The incident record is unread. The 8 October reading came from the same disallowed path and no longer counts, so the line takes the no-readable-history score (5, a limit of our reading, not a finding against Robotomail). Limits are published with numbers, 30 sends a minute per mailbox and 60 per account in the messages reference, daily and monthly caps per plan, 5 signups an hour per IP and 5 concurrent SSE streams (15). The error reference says every 429 carries `Retry-After`, the OpenAPI description says route-produced 429s don't, sends have no idempotency key, and the documented advice is to check sent mail before retrying (9 of 15). No SLA found on the pricing page or in the terms (0). The API is at `/v1` with no beta label (10).)
- Schema & documentation, Robotomail +8: Lumbox 82 (OpenAPI 3.1 at lumbox.co/openapi.json with 29 operations on 23 paths, all described (25). llms.txt with plan limits, endpoints and the MCP setup (10). Descriptions state what each call does, with notes such as long-poll endpoints being safe to retry; the MCP server card gives one line per tool (15 of 20). Typed parameters with `limit` and `cursor`, required fields marked (12 of 15). Shared responses for 400 to 429 and a default error on 28 operations, but errors are a bare `error` string with no code (12 of 15). Path versioning and a written deprecation policy, but the changelog it refers to wasn't found (8 of 15). Total 82.); Robotomail 90 (OpenAPI 3.1 at `/openapi.json` with 40 operations on 27 paths, each with an operation ID (25). `llms.txt`, and a Markdown copy of the docs and site pages by adding `.md` or sending `Accept: text/markdown`. The pricing page's own `.md` URL answered 404 on 1 November and points to `index.md#pricing` (10). Operation descriptions state what each route does, which key type it needs and which gates apply, and `llms.txt` says when not to use the product. The MCP tool descriptions sit behind OAuth and were not read (15 of 20). Request schemas carry required fields, `format: email` and `uuid`, length limits, patterns and enums. The `headers` field on a send is a free object (13 of 15). An error reference and per-route error variants, with three inconsistencies we found, on `Retry-After`, on the SDK version (the docs say v0.1.0, the tags are v0.2.0) and on the annual discount (the pricing page says about 50 per cent off Starter and above, the limits page's annual prices are about 25 per cent off) (12 of 15). URL versioning at `/v1` and a dated public changelog (15).)
- Agent ergonomics, Lumbox +6: Lumbox 78 (18 MCP tools, the 11 to 30 band; OAuth scopes narrow what a grant can do, but no read-only tool subset was found (15 of 25). Cursor pagination with `limit` and `has_more`, search, and an SSE stream for new mail (20). Errors are a human-readable message with the HTTP status, plus `retry_after_seconds` on 429 and written guidance on what to retry (12 of 20). `Idempotency-Key` on every POST; MCP annotations weren't readable without a session (16 of 20). One POST creates an inbox with a default address; official Node and Python SDKs (15). Total 78.); Robotomail 72 (Graded on the REST API, with the MCP server noted. The MCP server lists six tools, `search_messages` returns summaries and `read_message` reads large bodies in parts. REST message lists return full text and HTML bodies with no field selection, and quoted history isn't stripped (20 of 25). Message lists take `limit` up to 100, `offset`, `direction`, `threadId` and `since`. Thread lists stop at 50 and webhook deliveries at 20, both without pagination, and REST has no text search (14 of 20). Errors are always JSON. Quota gates carry `code`, an `upgrade` object, `resetAt` and `X-Robotomail-Retriable`, and an unknown path returned a JSON 404 with links when we tried one. Most other errors are a bare `error` string (17 of 20). Sends take no idempotency key and the SDKs don't retry them. Webhooks carry a stable delivery ID, and MCP tool annotations were not read (8 of 20). A send needs three fields and signup creates the first mailbox. SDKs exist in five languages but install from GitHub tags, not from package registries (13 of 15).)
- Security & auth, Lumbox +6: Lumbox 71 (OAuth 2.1 with PKCE, dynamic client registration and five scopes that split reading inboxes, reading mail, sending and domain changes, plus API keys stored as SHA-256 hashes that can be limited to named inboxes (30). Inbox-scoped keys and the read and send split keep one run away from another's codes; Lumbox's built-in agent drafts replies for approval, but the API itself sends at once (16 of 20). The terms tell users to treat bodies as untrusted, and the security page says attachment text is sanitised for prompt injection before it reaches an agent (12 of 15). The privacy policy says API calls are logged with endpoint, time and key prefix for rate limiting and billing; no customer-facing audit log was found (5 of 15). A valid security.txt to security@lumbox.co and a responsible disclosure section; not SOC 2 certified, no bug bounty (8 of 20). Total 71.); Robotomail 65 (REST keys are revocable by API, stored as SHA-256 hashes, and can be limited to named mailboxes. The MCP server takes OAuth with PKCE, `mail:read` and `mail:send` scopes, 10-minute access tokens and per-app disconnect. Keys travel in the `Authorization` header only. A REST key can't be made read-only (27 of 30). An MCP grant with `mail:read` alone is read-only, and a mailbox can be paused. Sends go out at once, with no drafts or approval step (12 of 20). Inbound mail is untrusted content. A security guide tells developers to pass email as data, check recipients and require approval for sensitive actions, and says attachments aren't scanned. Nothing is filtered on the service side (11 of 15). The dashboard has a read-only Audit Feed of email activity and the API lists the last 20 delivery attempts per webhook. No log of API calls was found (8 of 15). `security.txt` is valid until 24 August 2027 and reports go to the support address. No bug bounty, SOC 2 or ISO 27001 statement found (7 of 20).)
- Payments & pricing, Lumbox +5: Lumbox 40 (No x402, MPP or L402 (0). Four plans with prices and limits published without login, no per-email price (10 of 20). Free plan with 3 inboxes, 500 received and 100 sent emails a month, no card (20). Agent self-signup lets an agent create its own key, which a person approves once in a browser (10 of 20). Total 40.); Robotomail 35 (No x402, MPP or L402 in the docs, `llms.txt` or the OpenAPI file (0 of 40). Four plan prices are public, Solo $5, Starter $19, Growth $79 and Scale $199 a month, with no per-unit price or overage (10 of 20). The Free plan needs no card and doesn't expire, but exchanges mail only with the owner's verified address, 10 each way a month, so it tests the loop without doing the job (15 of 20). `POST /v1/signup` returns an API key with no browser, and `POST /v1/billing/upgrade` returns a checkout link. The key does nothing until a person clicks the verification link, and a person pays at checkout (10 of 20).)