# InboxAPI vs Lumbox (slim)

> Lumbox scores 60.7 (C) to InboxAPI's 46.2 (D) for agent inboxes. Prices, MCP, x402, uptime and agent notes side by side.

- Full: https://www.anchorterminal.com/compare/inboxapi-vs-lumbox.md (~4,750 tokens) · this version ~3,080 tokens · JSON https://www.anchorterminal.com/compare/inboxapi-vs-lumbox.json · canonical https://www.anchorterminal.com/compare/inboxapi-vs-lumbox
- 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)

Lumbox scores 60.7 (C) on agent readiness against InboxAPI's 46.2 (D), and leads in 5 of 7 scored categories. InboxAPI leads on payments & pricing and maintenance & community. Both do agent inboxes.

- InboxAPI: D 46.2, rank #1179 of 1510 · https://www.anchorterminal.com/tools/inboxapi.min.md
- Lumbox: C 60.7, rank #645 of 1510 · https://www.anchorterminal.com/tools/lumbox.min.md
- InboxAPI, good for A personal mailbox for one coding agent that needs to exchange mail with its owner and a few contacts at no cost. Ahead on Payments & pricing, 53 against 40; Maintenance & community, 43 against 23. Also No key needed to call it.
- Lumbox, good for Agents that need their own address to receive sign-up codes and links and to send replies. Ahead on Reliability, 45 against 33; Schema & documentation, 82 against 28; Agent ergonomics, 78 against 61; Security & auth, 71 against 57; Transparency & trust, 72 against 54.

| Category | InboxAPI | Lumbox |
| --- | --- | --- |
| Reliability (16%) | 33 | 45 |
| Performance (10%) | pending | pending |
| Schema & documentation (13%) | 28 | 82 |
| Agent ergonomics (13%) | 61 | 78 |
| Security & auth (14%) | 57 | 71 |
| Payments & pricing (10%) | 53 | 40 |
| Task success (10%) | pending | pending |
| Maintenance & community (7%) | 43 | 23 |
| Transparency & trust (7%) | 54 | 72 |

| Fact (where they differ) | InboxAPI | Lumbox |
| --- | --- | --- |
| Kind | MCP server | HTTP API |
| Vendor | Sitka Capital Pty Ltd | Cyphen Innovations Private Limited |
| Hosted endpoint | `https://mcp.inboxapi.ai/mcp` | `https://mcp.lumbox.co/mcp` |
| Transports | stdio, Streamable HTTP | HTTP, Streamable HTTP, stdio |
| Auth | None | OAuth or key |
| Pricing | Free | Freemium |
| Licence | Proprietary hosted service under InboxAPI's terms of service. The CLI on GitHub is MIT | none |
| Tools exposed | 21 | 18 |
| Last release | 2026-09-22 | 2026-06-19 |
| Terms last updated | 2026-09-11 | 2026-09-07 |
| Privacy policy last updated | 2026-09-11 | 2026-03-16 |
| Terms restrict automated access | not found in the text | yes |
| Popularity | 12 stars, 38 npm/wk | 13 npm/wk |

Why the edge:
- Schema & documentation, Lumbox +54: InboxAPI 28 (Graded on the MCP tools. The 9 October contract reading came from an unauthenticated `tools/list` call to the hosted endpoint, a request to the product's own endpoint, and is struck. No published document gives the server's input schemas. The tools reference lists 17 tool names with one-line descriptions, which isn't a contract, and the CLI source defines schemas only for its three local tools (0). `llms.txt` is published (10). The reference's one-liners say what each tool does, and a few say how, such as `get_thread` taking any Message-ID, with nothing on when not to call them (8 of 20). With the schemas struck, no typed inputs, enums or constraints are published (0). The docs show one sample response, for spotlighting, and no error reference (5 of 15). Releases are tagged with empty notes, there is no changelog, and the hosted tools carry no version (5 of 15). 0 + 10 + 8 + 0 + 5 + 5 = 28.); 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.)
- Maintenance & community, InboxAPI +20: InboxAPI 43 (Four versions were tagged on 22 September 2026 and none since (git ls-remote, 4 November). v0.3.20 carries the `archive-email` alias and other CLI changes since v0.3.19 (25 May), so recency is 43 days (20 of 30, 30 on 9 October). The 90-day line counts dated entries from 6 August, v0.3.20 (full), v0.3.21 (a test fix and release-workflow change, packaging-only, half), and v0.3.22 and v0.3.23, tagged on the same commit as v0.3.21 (half each), 2.5 in all, short of three (0 of 20; the line is 20 or 0). Issues and pull requests per the 9 October reading, not re-read (15 of 25). The 9 October MCP registry search came from its JSON API, which this run doesn't use, and is struck; no entry is credited (0 of 15). CI and CodeQL configured, CI passing on 22 September per the 9 October reading, npm trusted publishing, `Cargo.toml` on the default branch still at 0.3.14 (8 of 10). 20 + 0 + 15 + 0 + 8 = 43.); 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.)
- Transparency & trust, Lumbox +18: InboxAPI 54 (The CLI is open source under the MIT licence. The hosted mail service is closed, under terms dated 11 September 2026 that name Sitka Capital Pty Ltd as operator and Dini Labs Pty Ltd as owner of the technology (20 of 30). The terms and the privacy policy agree on roles, with the customer as controller of mail content, and the policy lists what is collected. It gives no retention period, and a DPA is available on request only (15 of 30). No deprecation policy. The terms allow functions to be removed at any time, with 14 days' notice only for changes to the terms that reduce a user's rights (3 of 20). No sub-processors are named, and data may be held in Australia and overseas, the United States among them. The CLI asks the npm registry for the latest version once a day and sends the MCP client's name and version to the service in its User-Agent, per the source (5 of 20). Terms and privacy policy still dated 11 September 2026 on 4 November.); Lumbox 72 (A closed hosted service; the security page says it can be self-hosted, but the repository the deployment guide clones isn't publicly readable. The footer names Cyphen Innovations Private Limited (15 of 30). The privacy policy and security page agree that mail is kept while its inbox exists and an account's data is deleted within 30 days, that email isn't used for training, and that the vault uses AES-256-GCM per-organisation keys (26 of 30). A deprecation policy with Deprecation and Sunset headers, 90 days' notice and 12 months for an old version (20). Hosts and locations named, Hetzner in Germany, Neon in the US, Vercel, Cloudflare, AWS SES, Dodo Payments and Steel for browsers (18 of 20). Total 79.)
- Agent ergonomics, Lumbox +17: InboxAPI 61 (The CLI source hides nine auth and encryption tools from MCP clients (five blocked, four internal) and adds local `whoami`, `report_bug` and `request_feature`. The tools reference names 17 tools and the README speaks of 21 tool definitions, so an agent sees between 11 and 30 (15 of 25, plus 2 for the hidden auth tools and the plain-text default, 17). The 28 KB size of the definitions came from the struck `tools/list` reading and is dropped. The reference describes paginated `get_emails`, search by sender, subject or date range, and a count tool. Bodies can't be searched (17 of 20, per 9 October, kept). No error codes are documented. The CLI source returns plain messages for refused recipients and rate limits (8 of 20). Sends take no idempotency key. The CLI adds `readOnlyHint` and `destructiveHint` to the tools and retries a call once after a token refresh (10 of 20). A send needs three fields and setup needs no configuration. There is no SDK, only the CLI, whose subcommands print JSON (9 of 15). 17 + 17 + 8 + 10 + 9 = 61.); 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.)
- Security & auth, Lumbox +14: InboxAPI 57 (The CLI holds an access and a refresh token in a local file written with mode 0600 and puts the token into each call, so the model never handles it. Tokens cover the whole account with no scopes, travel in the request body, and can be revoked one at a time or all at once from the CLI (20 of 30). There is no read-only mode. The CLI refuses `forward_email` without `confirm`, refuses new recipients unless a flag the model can set itself is passed, and keeps five auth and encryption tools out of MCP. The service caps an account at five external recipients (12 of 20). Inbound mail gets one of four trust levels and untrusted text is datamarked with a per-request marker, tool descriptions warn against following email content, and outbound mail containing a JWT is rejected, per the docs (14 of 15). `get_sent_emails` shows delivery status and an optional Claude Code hook writes a local activity log. No server-side audit log was found (6 of 15). `security.txt` returns 404, and no disclosure policy, bounty or certification was found. The repository runs CodeQL and publishes to npm with provenance (5 of 20). Re-read on 4 November, security.txt still answers 404, the repository has no SECURITY.md, and osv.dev lists no advisory for inboxapi or @inboxapi/cli.); 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.)
- Payments & pricing, InboxAPI +13: InboxAPI 53 (Graded as a hosted service. No x402, MPP or L402 in the docs, the tool list or the CLI source (0 of 40). The home page and FAQ say the service is free with no usage tiers, and that paid plans are planned with no price given. Send quota numbers aren't published (15 of 20). No card and no trial period (20). The CLI creates the account by proof-of-work on first use with no person involved. Owner verification, which needs a person to read a six-digit code, lifts trial restrictions the docs don't describe (18 of 20). Re-read on 4 November, the home page still says "Completely Free" with paid plans "coming soon".); 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.)