Skip to main content
Glama
nikolausm

IMAP MCP Server

by nikolausm

imap_search_emails

Search email messages by sender, recipient, subject, body, date, or status. Optionally search all folders and include message bodies.

Instructions

Note: on some servers a 'flagged' or starred message carries a custom keyword (e.g. an Open-Xchange color label or Apple's $MailFlagBit*) instead of, or in addition to, the \Flagged system flag. After any flagged search, inspect each result's customKeywords field before concluding a message is or isn't flagged — do not rely on the flagged filter alone. Search for emails matching criteria (sender, recipient, subject, body text, date range, read/flagged status). Use this to FIND messages when you know something about them but not their UID — e.g. "emails from amazon last week", "unread invoices". By default searches a single folder (INBOX). Set searchAllFolders=true to scan every mailbox at once — this catches messages filed away by rules (e.g. a receipt routed to a custom folder); Trash/Spam/Drafts are skipped unless you opt in. By default returns lightweight headers (uid, from, subject, date, and folder when searching across folders); set includeBody=true to also return the parsed body in one round-trip instead of paying the N+1 cost of calling imap_get_email per match. For the newest messages without criteria, prefer imap_get_latest_emails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoSearch by recipient
bodyNoSearch in body text
fromNoSearch by sender
seenNoFilter by read/unread status
limitNoMaximum number of results
sinceNoSearch emails since date (YYYY-MM-DD)
beforeNoSearch emails before date (YYYY-MM-DD)
folderNoFolder name to search (default: INBOX). Ignored when searchAllFolders is true.INBOX
flaggedNoFilter by flagged status
subjectNoSearch by subject
keywordsNoMatch messages that have ANY of these CUSTOM keywords (server-side OR; not system flags like \Seen/\Flagged). Read a mailbox's available custom keywords from imap_folder_status's customKeywords field, then pass the ones you want here.
accountIdNoAccount ID (from imap_list_accounts). Optional if accountName is given or only one account is configured.
messageIdNoSearch by RFC822 Message-ID header (substring match)
bodyFormatNoHow to render the body when `includeBody` is true. Mirrors `imap_get_email` — "markdown" (default) returns clean Markdown and omits raw HTML so it never crosses the MCP boundary; "text" returns plain text; "html" returns raw HTML; "auto" prefers substantive text/plain, else Markdown.markdown
unKeywordsNoExclude messages that have ANY of these CUSTOM keywords (server-side; result has NONE of them). Same keyword source as `keywords` — check imap_folder_status first.
accountNameNoAccount name instead of accountId. Optional if accountId is given or only one account is configured.
includeBodyNoIf true, also fetch the parsed message body in the same round-trip and return it alongside headers (avoids the N+1 cost of calling imap_get_email per match). Body is rendered per `bodyFormat` and capped at `bodyMaxLength` characters per field. Off by default to preserve lightweight behavior.
includeSpamNoWhen searchAllFolders is true, also search Spam/Junk folders (off by default — noisy).
includeTrashNoWhen searchAllFolders is true, also search Trash/Bin/Deleted folders (off by default — noisy).
bodyMaxLengthNoPer-message cap (in characters) for each rendered body field when `includeBody` is true. Defaults to 10000 to match `imap_get_email`.
includeDraftsNoWhen searchAllFolders is true, also search the Drafts folder (off by default).
searchAllFoldersNoSearch across ALL folders instead of just `folder`. Skips Trash/Spam/Drafts and non-selectable folders by default. Use when a message might have been filed/archived/moved and you do not know which folder it is in.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses flagged keyword caveat, default single-folder search, skipping of Trash/Spam/Drafts, lightweight return format, and includeBody cost. Minor omission: no mention of rate limits or pagination beyond limit parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but front-loaded with a critical note. Every sentence adds value given the tool's complexity. Could be slightly trimmed (e.g., the flagged note could be in a dedicated warning), but overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 22 parameters, no output schema, and no annotations, the description is very complete. It covers default behaviors, performance trade-offs, and edge cases. It mentions returned fields but not exact format—acceptable without output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed parameter descriptions. The description adds significant value beyond schema: explains flagged keyword caveat, searchAllFolders behavior, includeBody benefits and bodyFormat options, custom keyword sourcing, and interaction between parameters like folder and searchAllFolders.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'emails', listing specific criteria. It distinguishes itself from siblings like imap_get_email (used when UID is known) and imap_get_latest_emails (for newest without criteria).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use: 'FIND messages when you know something about them but not their UID.' Provides alternatives: 'For the newest messages without criteria, prefer imap_get_latest_emails.' Also gives guidance on searchAllFolders and includeBody to avoid N+1.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nikolausm/imap-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server