Skip to main content
Glama
TG-Techie

apple-mail-mcp

by TG-Techie

search_messages

Search Apple Mail messages by criteria like sender, subject, date, or attachments, returning metadata rows. Restrict results to specific message IDs or the current selection for targeted filtering.

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).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and exceeds it. It reveals that results are metadata-only, that missing ids drop out silently (partial results), that body_contains on AppleScript is slow (with measured times) and adds a warnings field, and that include_attachments is opt-in for performance reasons. It also explains the semantics of the SELECTED sentinel and mixed lists, leaving little to inference.

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

Conciseness5/5

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

The description is long but every sentence earns its place given the tool's complexity (14 parameters, two modes, performance tradeoffs). It is front-loaded with the core purpose, then uses structured bullet points for the modes, and closes with routing guidance. No filler or redundant phrasing.

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?

The description is complete for an agent to call this tool correctly. It covers all operational modes, parameter interactions, performance caveats, and even cross-references sibling tools for the right follow-up call. The existence of an output schema means the return format is already established, and the description's note that rows are metadata-only aligns with that.

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?

Even though the schema covers 100% of parameters, the description adds substantial meaning beyond the schema. It explains the two semantic modes of source, the interaction between account/mailbox and source, the approximation of text_contains on AppleScript, and the performance implications of body_contains and include_attachments. This is far beyond the schema's basic property 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 states a specific verb ('Search for messages'), a clear resource scope, and clarifies that it returns 'metadata-only rows.' It explicitly distinguishes itself from siblings like get_thread and get_messages by explaining the thread-retrieval pipeline, so an agent can immediately tell which tool to use.

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?

The description gives explicit when-to-use guidance: it contrasts the two source modes (None vs. id list), explains when account/mailbox are required vs. ignored, and routes the agent to get_thread for thread expansion and get_messages for body retrieval or cheap attachment metadata. It also notes when include_attachments should be avoided and when to prefer the alternative.

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/TG-Techie/apple-mail-mcp'

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