← All articles

The 7 MCP Email Tools Explained: What AI Can and Can't Do

2026-08-09

The trustworthiness of an MCP email server comes down to "what tools it exposes." Tools are the very list of operations the AI is allowed to use. So look at the exposed tools and you know precisely what the AI can and can't do. This article walks through all seven tools Zephmail provides, one by one, split into read tools (safe) and write tools (gated), and shows that the absence of "dangerous tools" is the key to safety.

By the time you finish reading, you'll be able to answer "is it safe to let AI touch my mail?" with a concrete basis. The key is to look at the list of exposed tools. Let's go in order.

Why the "tool list" matters

It's dangerous to speak of AI safety with optimism or "probably fine." The strength of MCP is that it guarantees safety by mechanism. A tool the server doesn't provide simply doesn't exist for the AI. Without a "delete everything" tool, no matter how clever, the AI cannot delete everything. In other words, the list of exposed tools is like a contract defining the AI's permissions.

Read tools (run as-is, safe)

These only fetch information and change nothing. Worst case, they "read something unneeded," so they can run freely.

• list_folders — Gets the list of your account's folders and labels. "Inbox," "Sent," "Important" — the first step for the AI to grasp where things are.
• list_messages — Lists recent mail in a folder, newest first. It can narrow to unread only, forming the basis of "summarize this morning's unread."
• get_message — Specifies a UID to fetch a particular message's body. Summaries and reply drafts need to read the target message's contents accurately.
• search_messages — Full-text searches within a folder to find mail matching keywords. Even with a fuzzy subject or date, "invoice" finds it in one shot.
• get_selected_message — Gets the message you currently have open in Zephmail. It enables screen-context requests like "reply to this email."

Write tools (never complete on their own)

From here, changes are involved, so these are strictly limited. The point is that neither completes with the AI alone.

• create_draft — Creates a draft and reflects it in Zephmail's composer. You can specify recipient, subject, body, reply source, and so on, but it does not send. It merely prepares a draft for review, which you can read, fix, or discard.
• request_send — Adds a send to an "approval queue." The actual send happens only when you check the content in Zephmail and approve. The AI can't press approve.

Why "seven"? A no-more, no-less design

More tools aren't better. Too many, and the permissions granted to the AI widen and become hard to grasp. Too few, and it's useless. Zephmail's seven tools are the result of balancing this. On the read side, they're necessary and sufficient to cover everyday email operations (list, body, search, current selection). On the write side, they're the minimal set that's safely useful — draft and send request. By not adding "convenient but dangerous" ones (like autonomous deletion), the design keeps utility while narrowing permissions. The number and kinds of tools themselves express the design judgment of "where to draw the line between convenience and safety."

If tools were added in the future

Features may grow and tools may be added in the future. Even so, the principle doesn't change. When adding a new tool, always ask "is it an irreversible operation?" and "should the AI do it alone?" Even if a delete- or archive-like operation were added, it would take a form that inserts approval, or limits to UI operation. The important thing is not to break the safety boundary in the chase for convenience. The tool list may change like a living thing, but "keep destructive operations in human hands" should be the unchanging axis.

The boundary — note "what's not here"

Looking at these seven, what matters is the tools that don't exist. There is not one tool for the AI to autonomously complete an irreversible operation — send, delete, archive, report as spam, or move to a folder — on its own. All these operations remain in your hands in the app.

So however large a request you make of the AI, there's no way for it to run wild. Read, search, summarize, draft, propose a send — that's the extent of the AI's permission, and the final act of actually sending or deleting is always done by a human. Combined with a local-only connection and audit logs, this boundary shifts AI email from "smart but scary" to "smart and safe."

An example of the actual flow

Ask "reply to the invoice email from accounting saying payment lands at month-end," and the AI first finds the mail with search_messages("invoice"), reads the body with get_message, and creates a quoted reply with create_draft. You check and adjust the draft that appears in the composer, and send it yourself. Every call remains in the activity log. Not one dangerous operation was run automatically.

Frequently asked questions

Won't the AI accidentally delete everything? It can't. No delete tool is exposed to the AI. Deletion is done by you in the app.

Why isn't it sent when I ask to send? That's by design. request_send only puts it in an approval wait and doesn't send until your approval. It's a deliberate safety design.

Can I confirm which tool was called? Yes. Every AI action is recorded in the activity log and reviewable at any time.

Where can I check the tool list? After connecting, ask the assistant "tell me the tools you can use," and it returns the list of exposed tools. You can confirm with your own eyes that no autonomous send or delete tool is there.

The power that emerges from combining tools

Individual tools are simple, but combined they become powerful. Behind the single line "reply to the invoice from accounting," a multi-tool sequence unfolds — search_messages to find the mail, get_message to read the body, create_draft to make the reply. What the AI excels at is translating your vague request into this chain of concrete tool calls. You only say "what you want to do" in natural language; "which tools, in what order" is the AI's judgment. Read tools grasp the situation, write tools prepare the deliverable — that flow connects naturally inside a conversation.

Importantly, however complex the chain, it can't exceed the range of exposed tools. Seven tools are all there is, and operations outside them (autonomous sending, deletion) don't exist. So even as the chaining grows sophisticated, the danger level doesn't rise. Capability widens by combination while the permission ceiling stays fixed — that's why you can delegate with confidence.

The "permission model" view

An MCP tool list is, in effect, the "permission model" granted to the AI. Picture the permissions an OS grants an app (camera, location). Just as an app can only act within the permissions the user allows, the AI can only act within the tools the MCP server exposes. From this view, the conditions of a good MCP server come into focus: grant "read permissions sufficient to be useful" while narrowing "irreversible write permissions." Zephmail's seven tools embody exactly this balance — rich reading, writing limited to draft and send request, zero destructive operations.

Concrete scenes where each tool shines

Let me give a scene where each tool bites. list_folders helps someone using many labels have the AI grasp "where things are." list_messages is the basis of the morning unread check. search_messages solves "where's that thing again?" in one shot. get_message is essential for reading a target's contents accurately for summary or reply. get_selected_message enables context-dependent instructions like "reply to this" for the mail open on screen. On the write side, create_draft is used for building the skeleton of routine replies, and request_send for a safe send flow with approval inserted. Each maps to a concrete moment of daily email work.

Understanding tool arguments (parameters)

Each tool has "arguments," which control the AI's operation even more finely. For example, list_messages has arguments like "folder name," "count," and "unread only," letting you narrow to "the latest 10 unread in INBOX." search_messages takes a search keyword and count; create_draft takes recipient, subject, body, and the Message-ID of the reply source. That arguments are clearly defined means the range of what the AI can do is fixed as a specification. Vague natural language doesn't morph directly into a can-do-anything permission.

Why we deliberately don't build a "delete tool"

Technically, delete or archive tools could be added to the MCP. So why deliberately not build them? The answer is the design judgment of "prioritizing safety over convenience." Deletion is irreversible, and an AI misjudgment ties directly to an unrecoverable loss. While the convenience of reading and drafting is large, the convenience of autonomous deletion is amply substituted by "taking one manual step." Weighing the convenience gained against what could be lost, not exposing a delete tool is the rational choice. "Making dangerous things impossible" over "increasing what's possible" — that's the mindset of trustworthy design.

Different from the MCP of developer tools

Codex and Claude Code are used to handling powerful, autonomous MCP tools like file editing and command execution. But email differs in the nature of its risk from code. Code can be reverted before a commit even if you err, but a sent email can't be taken back. So email's MCP is deliberately designed to "narrow what's possible" more than developer tools. Even within the same MCP, carefully choosing the tools to expose according to the target's nature — that judgment is what separates a good email MCP server from a bad one.

Wrapping up

The trustworthiness of an MCP email server is decided by the tools it exposes. Zephmail's seven tools are five read (list folders, list messages, get body, full-text search, current selection) and two write (create draft, request send). Neither write tool completes with the AI alone, and no tool autonomously sends, deletes, archives, or moves. This "what's not here" is the core of safety. Capability widens by combination while the permission ceiling stays fixed, and every operation stays in a log — so smarts and safety coexist. If you want to know what the AI can and can't do, looking at the list of exposed tools is the surest method.

Frequently asked questions

Will tools be added in the future? Tools that make reading and drafting more convenient may increase, but the policy is consistent — no tool for the AI to autonomously complete send, delete, archive, or move will be added. Even when raising convenience, the safety boundary of "keep irreversible operations inside human approval" doesn't move. So even as tools grow, you can treat it as settled that "the AI won't delete or send on its own."

See it yourself

Install Zephmail, connect your assistant, and open the "AI integration (MCP)" panel to watch each tool call appear in the activity log in real time. What the AI is doing becomes fully transparent — that's the condition for AI email you can delegate to with confidence.