Skip to main content
Glama
s-morgan-jeffries

apple-mail-mcp

search_messages

Read-onlyIdempotent

Search for email messages using filters like sender, subject, date, read status, or body text. Optionally restrict to specific message IDs or the selected messages in Mail.

Instructions

Search for messages matching criteria. Returns metadata-only rows.

Two corpus modes:

  • source=None (default): search the given account/mailbox using the IMAP/AppleScript SEARCH path. account is required.

  • source=[id1, id2, ...]: scope the search to the specific messages identified by the given ids. account/mailbox are ignored; the connector resolves each id self-sufficiently. The resulting message dicts are post-filtered by the other criteria (sender_contains, read_status, etc.) — full filter composition. The literal token "SELECTED" may appear in the list and is server-resolved at call time to Mail.app's current UI selection (zero-or-more messages). Mixed lists like ["SELECTED", "12345"] are valid. Missing ids drop out silently (partial-results).

For thread retrieval, call get_thread(message_id) to expand an anchor into thread member ids, then optionally pipe those ids into source=[ids] for filtered metadata browsing or into get_messages([ids]) for full bodies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results to return (default: 50).
sourceNoOptional list of message ids (with optional ``"SELECTED"`` sentinel) to restrict the search to. ``None`` (default) searches the account/mailbox normally.
accountNoMail.app account display name (e.g., "Gmail", "iCloud") or UUID (from list_accounts). Required when ``source is None``; ignored when ``source`` is a list. Names are convenient but unstable across renames; UUIDs are stable.
date_toNoInclusive upper bound on date received (full day included). ISO 8601 YYYY-MM-DD.
mailboxNoMailbox name (default: "INBOX"). Ignored when ``source`` is a list.INBOX
date_fromNoInclusive lower bound on date received. ISO 8601 YYYY-MM-DD.
is_flaggedNoFilter by flagged status (true=flagged, false=not flagged).
read_statusNoFilter by read status (true=read, false=unread).
body_containsNoSubstring match against message body content. IMAP uses ``BODY`` predicate (sub-second); AppleScript reads ``content of msg`` per candidate (very slow on large mailboxes — measured 148s for 100 cold-cache messages). When the call commits to AppleScript with this filter set, a ``warnings`` field is included in the response. Case-insensitive on both paths.
text_containsNoSubstring match against headers + body (RFC 3501 ``TEXT`` semantics). On AppleScript, approximated as ``content + subject + sender`` (recipients and other headers not matched). Same perf characteristics as ``body_contains``.
has_attachmentNoFilter messages with (true) or without (false) attachments.
sender_containsNoFilter by sender email/domain substring.
subject_containsNoFilter by subject keywords substring.
include_attachmentsNoWhen True, each row includes an ``attachments`` field listing per-attachment metadata (name, mime_type, size, downloaded). Default False — opt-in because the AppleScript fallback path can be slow on cold caches (#142). Free on the IMAP fast path. To fetch attachment metadata for a known list of ids cheaply, prefer ``get_messages([ids])`` (default-on attachments, bounded cardinality).
received_within_hoursNoRelative-time filter. When set, only return messages received within the last N hours (hour precision). Composes with ``date_from`` / ``date_to`` — the most restrictive filter wins. Must be a positive int. Days = 24, weeks = 168, etc.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Goes well beyond annotations by describing two corpus modes, performance warnings, silent failure for missing ids, SELECTED sentinel behavior, warnings field inclusion, and opt-in attachments due to AppleScript slowness. Annotations only say readOnly/idempotent/non-destructive.

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?

Well-structured with clear breakdown of modes and thread retrieval workflow. First sentence is concise and informative. Some redundancy could be trimmed, but every section is justified by the tool's complexity.

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

Completeness5/5

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

Given 15 parameters, two modes, and an output schema, the description covers all essential aspects: operations, performance trade-offs, workflow guidance, and warning mechanisms. No gaps remain for an agent to misuse the tool.

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

Parameters4/5

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

Schema coverage is 100%, but description adds crucial context about parameter interaction (e.g., source modes, account ignored when source is list, received_within_hours composes with date fields). Adds value beyond schema descriptions.

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 tool's purpose: 'Search for messages matching criteria. Returns metadata-only rows.' It distinguishes from siblings like get_messages (full bodies) and get_thread (thread expansion) by explicitly mentioning thread retrieval workflow and source list mode.

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?

Provides explicit guidance on when to use default mailbox search vs. source list mode, and how to combine with get_thread and get_messages. Also warns about performance impact of body_contains/text_contains on AppleScript path, aiding decision-making.

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/s-morgan-jeffries/apple-mail-fast-mcp'

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