Skip to main content
Glama
wylieswanson

apple-mail-mcp-server

by wylieswanson

search_messages

Read-onlyIdempotent

Search for messages using filters like sender, subject, date, read status, and attachment presence. Returns metadata-only results from a specified account or from a list of message IDs.

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?

Beyond readOnlyHint/idempotentHint annotations, describes that it returns metadata-only rows, includes performance warnings for body_contains/text_contains, and explains include_attachments overhead. No contradictions.

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 sections and bullet points, front-loaded with purpose. Slightly lengthy but all content is justified by the tool's complexity. Could be condensed slightly.

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?

Comprehensive coverage of 15 parameters, modes, filtering, performance, and related tools. Output schema exists, so return value explanation is unnecessary. No gaps identified.

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%, so baseline is 3. The description adds context for source/account/mailbox interaction and mode behavior, but individual parameter descriptions are already thorough in schema. Still adds value beyond schema.

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?

Clearly states 'Search for messages matching criteria' and distinguishes two corpus modes. Verb+resource is specific, and sibling differentiation is implicit via mode explanations (e.g., compare to get_messages for full bodies).

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 explains when to use each mode (source=None vs source=list) and when to prefer alternatives like get_messages or get_thread. Provides clear context for filtering composition.

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/wylieswanson/apple-mail-pz-mcp'

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