About mails0.

One project, several public surfaces

The product name, packages, documentation, and source repositories describe different parts of the same system.

mails0 is the product and hosted website. mails-agent is the npm and PyPI package that provides the command-line interface and SDK. mails-agent-mcp exposes mailbox tools to compatible MCP clients. The source repository is the implementation record for the API, worker, database, storage, and deployment paths.

Those names should not be treated as separate vendors or unrelated products. When a page discusses a package version, command, mailbox lifecycle, or self-hosted capability, the linked package metadata or repository is the stronger source than the summary on this site.

Published pages have a named editorial owner

Gene Dai is the named maintainer and editorial owner shown on mails0 content pages. The author link resolves here, and this page links onward to the public GitHub identity used for the project. That relationship gives readers and answer engines a stable path between a claim, its author, the product entity, and the implementation record.

A named owner is not a substitute for evidence. Product claims still need a visible source, a current review date, and language that distinguishes implemented behavior from a roadmap, proposal, vendor statement, or inference. Comparisons must also state when another product is the better fit.

What mails0 is designed to do

The project focuses on programmable email identities for software-driven workflows. Its core jobs include receiving messages, extracting verification codes, searching inboxes, preserving thread context, reacting through webhooks or events, exposing tools through CLI, SDK, HTTP, and MCP, and deploying the service in a Cloudflare account.

It is not positioned as a human email client, newsletter platform, customer-support suite, or universal replacement for managed sending infrastructure. A managed provider can be the stronger choice when a team wants vendor-operated deliverability, a mature testing platform, or a human mailbox integration. The comparison library is expected to preserve those boundaries.

• Use a dedicated mailbox when the workflow genuinely depends on email identity or asynchronous delivery.
• Start with receive-only temporary access before granting durable identity or sending authority.
• Treat message content, links, attachments, and requested actions as untrusted input.
• Inspect current documentation and source before depending on a capability in production.

How to challenge or correct a claim

If a page conflicts with the product source, package metadata, or a linked vendor document, use the project issue tracker to provide the page URL, the disputed sentence, and the strongest available source. Corrections should update the visible text, structured data, discovery files, and sitemap date together when those surfaces repeat the same claim.

A page review date means the cited sources were checked on that date. It does not guarantee that an external vendor, registry, search engine, or hosted dependency will remain unchanged. Time-sensitive pricing, limits, and product availability should always be rechecked at the official destination.

Sources and product scope

Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.

Related implementation paths