IMAP Is Legacy; JSON-Native Email Is the Future

This piece argues the case, names IMAP's specific frictions for agents, and describes the JSON-native contract that replaces it.

What IMAP was designed for

IMAP (Internet Message Access Protocol) was designed so a human's mail client could maintain a long-lived, authenticated connection to a server and synchronize folders, flags, and message state. It assumes a persistent session, it speaks a line-based command grammar, and it returns raw RFC 822/MIME blobs that the client is responsible for parsing. For a desktop or phone client that stays connected and renders mail to a person, that model is excellent and battle-tested.

An AI agent is none of those things. It is typically stateless between steps, it reasons over structured data, and it wants to call a tool, get a clean result, and continue. The impedance mismatch is the whole problem.

Why IMAP is a poor fit for agents

The frictions are concrete:

• Stateful sessions vs. stateless agents. IMAP wants a maintained connection (the efficient real-time path, IDLE, depends on holding one open). Agents come and go; managing a persistent IMAP session inside an ephemeral agent runtime is fragile glue nobody wants to own.
• You parse MIME yourself. IMAP hands you raw message bytes - nested MIME parts, encodings, headers - and leaves the parsing to you. An agent wants {"from": ..., "subject": ..., "text": ...}, not a multipart blob to disassemble.
• A command grammar, not a resource model. IMAP's verbs (SELECT, FETCH, UID SEARCH) are a protocol to implement, not an HTTP resource to call. There's no JSON, no standard pagination envelope, no idempotency semantics.
• Auth friction. On the mainstream consumer providers, IMAP now sits behind OAuth (Google removed password-based "less secure app" access), so even the "simple" path drags in a consent flow.
• Not tool-shaped. An agent runtime can't register "IMAP" as a native capability. It can register an HTTP API or an MCP server.

None of this means IMAP is bad. It means asking an agent to speak IMAP is asking it to act like a 1990s mail client.

The JSON-native contract that replaces it

What an agent actually wants is a small, predictable, stateless contract:

• Send as one HTTP call with a JSON body and an Idempotency-Key so a retry can never double-send.
• Read inbound as a clean JSON list - a stable envelope with pagination - where each message is already parsed into sender, subject, body, and attachments.
• Fetch on demand when the agent needs to block on a message that just arrived, instead of holding a socket open.
• Authenticate with a single scoped bearer key, not an interactive OAuth dance.
• Be tool-shaped so an MCP-capable runtime can call it natively.

This is the contract behind a two-way email API: send, receive, and read-back as one mailbox object, expressed in JSON. The inbound email API pillar goes deep on the read side, including on-demand fetches for blocking reads.

And then there's MCP

The real leap beyond "REST instead of IMAP" is that an agent shouldn't even hand-roll HTTP calls if it doesn't want to. With the Model Context Protocol, the mailbox's actions become *tools* the agent runtime discovers and calls natively - send, list inbound, read a message - with no client glue at all. That is something IMAP structurally cannot offer: it has no notion of a self-describing, agent-discoverable tool surface. We cover that in the MCP email server pillar.

How Sairaph Mail expresses it

Sairaph Mail exposes every mailbox as a JSON-native REST API (/api/v1) and a native MCP server (/mcp/v1/mcp, streamable-HTTP), over the same scoped key - no IMAP loop to babysit, no MIME to disassemble, no OAuth consent screen. Send is one idempotent HTTP call; inbound comes back as a parsed, paginated JSON list with an on-demand fetch for blocking reads. IMAP keeps doing what it's good at - running mail clients for humans. For agents, a JSON-native, tool-shaped contract is simply the better fit. See it on the product page.