Skip to main content
Glama

search_emails

Search across Apple Mail accounts using filters for subject, sender, date, attachments, flags, and body content. Returns paginated results in text or JSON format.

Instructions

Unified search tool with JSON output, pagination, and real date filtering.

Consolidates subject search, sender search, body content search, and cross-account search into a single tool.

Args: account: Account name to search in (e.g., "Gmail", "Work"). If None, searches ALL accounts (slower). mailbox: Mailbox to search (default: "INBOX", use "All" for all mailboxes, or specific folder name) subject_keyword: Optional keyword to search in subject subject_keywords: Optional list of subject keywords; matches any keyword sender: Optional sender email or name to filter by has_attachments: Optional filter for emails with attachments (True/False/None) flagged: Optional filter for flagged emails (True/False/None) flag_color: Optional filter for a specific flag color: "red", "orange", "yellow", "green", "blue", "purple", or "gray". Implies flagged=True. read_status: Filter by read status: "all", "read", "unread" (default: "all") date_from: Optional start date filter (format: "YYYY-MM-DD") date_to: Optional end date filter (format: "YYYY-MM-DD") include_content: Whether to include email content preview (slower) max_content_length: Maximum content length in characters when include_content=True (default: 500, 0 = unlimited) body_text: Optional text to search for in email body content (case-insensitive). WARNING: body search is significantly slower as it reads each message body. max_results: Backward-compatible alias for limit output_format: Output format: "text" or "json" (default: "text") offset: Number of matching results to skip before returning data limit: Maximum number of results to return per page sort: Result sort order: "date_desc" or "date_asc"

Returns: Formatted list of matching emails or JSON payload with stable message metadata

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNodate_desc
limitNo
offsetNo
senderNo
accountNo
date_toNo
flaggedNo
mailboxNoINBOX
body_textNo
date_fromNo
flag_colorNo
max_resultsNo
read_statusNoall
output_formatNotext
has_attachmentsNo
include_contentNo
subject_keywordNo
subject_keywordsNo
max_content_lengthNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Since no annotations are provided, the description carries the full burden. It discloses performance traits (body_text slower, account=None slower), pagination via offset/limit, and output format options. It does not mention authentication, rate limits, or read-only nature, but as a search tool those are less critical. The warnings are valuable.

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 well-structured with a summary line followed by a detailed parameter list. It is verbose due to the many parameters, but each line is necessary. The front-loaded summary quickly communicates the tool's purpose. Could be slightly more concise, but overall effective.

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 the tool's complexity (19 parameters, many optional filters) and the existence of an output schema, the description covers everything needed: what the tool does, how to use parameters, performance implications, and return types. It is comprehensive and leaves little ambiguity for an AI agent.

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?

With 0% schema description coverage, the description fully compensates. Every parameter is documented with purpose, default, and sometimes special values (e.g., mailbox: 'INBOX', 'All'; flag_color lists colors). This exceeds the baseline and provides rich context beyond the schema's property titles.

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 identifies the tool as a unified email search tool, consolidating subject, sender, body, and cross-account searches. It distinguishes itself from siblings like list_inbox_emails by emphasizing filtering capabilities and advanced search features.

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

Usage Guidelines3/5

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

The description provides some usage guidance (e.g., warning that body_text is slower, account=None searches all accounts), but it does not explicitly tell when to use this tool versus alternatives like list_inbox_emails or get_email_thread. The context is implied but not direct.

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

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