Skip to main content
Glama

search_emails

Search emails across accounts and mailboxes using filters like subject, sender, body text, date range, and attachments. Supports pagination and returns 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) 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
accountNo
mailboxNoINBOX
subject_keywordNo
subject_keywordsNo
senderNo
has_attachmentsNo
read_statusNoall
date_fromNo
date_toNo
include_contentNo
max_content_lengthNo
body_textNo
max_resultsNo
output_formatNotext
offsetNo
limitNo
sortNodate_desc

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
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 performance implications (speed differences for account, body, content inclusion), pagination behavior (offset/limit), and output format options. Does not mention error conditions or idempotency, but gives adequate transparency for a read-only search tool.

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 front-loaded with a clear summary, then an organized list of parameters. It is somewhat long (17 parameters explained) but each line adds value. Could be slightly more concise, but structure is good.

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 17 parameters and no annotations, the description covers most behavioral aspects: performance, defaults, pagination, output formats. It does not detail response structure, but output schema exists to cover that. Missing explicit error handling notes, but overall complete for typical usage.

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 0%, but the description explains every parameter in detail, including defaults, formats, and warnings (e.g., body_text slower). It adds meaning beyond the schema by describing semantics like the difference between subject_keyword and subject_keywords, and the alias max_results for limit.

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 it is a unified search tool that consolidates subject, sender, body, and cross-account search into one tool. It specifies verb 'search' and resource 'emails', and distinguishes from siblings like list_inbox_emails by mentioning consolidation.

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

Usage Guidelines4/5

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

The description provides context on when to use each parameter (e.g., account filtering faster, body text slower) but does not explicitly compare against sibling tools like get_email_thread or list_inbox_emails. It implies this is the general-purpose search, but could be clearer on when not to use it.

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