Skip to main content
Glama

mail_search

Read-only

Search all mailboxes through a read-only index using optional filters for subject, sender, recipient, body text, dates, unread/flagged status, and attachments; returns citable pointers newest first.

Instructions

Indexed search across ALL mailboxes via Mail's Envelope Index — fast and read-only. All filters optional and ANDed: subject/from_/to substrings, mailbox a mailbox NAME exactly as mail_overview reports it ("Junk E-mail" — case-insensitive substring; the encoded spelling also works; a name that matches nothing RAISES — it is a typo, not an empty mailbox — while a stale folder url just returns no results), since/until (epoch seconds on received date), unread/flagged. body searches message TEXT via the FTS index and is BEST-EFFORT — it only sees messages already indexed by mail_index_bodies (run that first; incomplete coverage is normal). At least one filter required. Returns citable Pointers, newest first. Falls back to AppleScript inbox search on missing Automation access / schema drift. has_attachments means a real DOCUMENT — inline signature/newsletter images are excluded, so it will not match a mail whose only attachment is a logo. account takes a display name ("Personal") or a raw account UUID; the UUID form stays pure sqlite, while a NAME has to be resolved through Mail and therefore LAUNCHES Mail if it isn't running (an unknown name raises rather than guessing). Every other filter reads the index at rest and never launches Mail. Read-only; needs Full Disk Access, plus Automation access for Mail on the account-name path and the AppleScript fallback. Each Pointer carries folder (the round-trip mailbox token) and account (the owning account's uuid — map it to a name with one mail_overview call), so a hit is complete on its own: no second read to work out where it lives. Returns {results, truncated?, plane?, coverage?}. truncated means the answer came back AT limit (25 max) and there may be more — do NOT report such a search as exhaustive. plane = "applescript-inbox" means the sqlite index was unreachable and this scanned the INBOX ONLY. coverage explains an empty body= answer: bodies are only matchable once mail_index_bodies has indexed them.

Input Schema

NameRequiredDescriptionDefault
toNo
bodyNo
from_No
limitNo
sinceNo
untilNo
unreadNo
accountNo
flaggedNo
mailboxNo
subjectNo
has_attachmentsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.1

TDQS

A5/5.0
Behavior5/5

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

The description adds extensive behavior beyond the readOnlyHint and destructiveHint annotations: Full Disk Access and Automation requirements, AppleScript inbox fallback on missing access or schema drift, mailbox typos raising errors, body-index coverage limits, and account-name resolution potentially launching Mail. It also explains result fields such as truncated, plane, and coverage so the agent can interpret partial or degraded outcomes.

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?

Despite being long, the length is justified by the tool's 12 parameters and complex fallback/permission behavior. The purpose and core filters are front-loaded, and the remaining sentences each add operational meaning rather than repeating schema or annotations.

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?

With annotations, an output schema, and 12 undocumented parameters, this description covers the missing context an agent needs to call the tool correctly. It explains permissions, fallback behavior, best-effort body search, error conditions, truncation, and how to interpret the returned coverage and plane fields.

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 description coverage is 0%, so the description carries the full burden and does so thoroughly for all 12 parameters. It defines substring semantics for subject/from_/to, mailbox-name matching rules, epoch-second date filters, unread/flagged flags, body-index best-effort behavior, has_attachments document semantics, account display-name versus UUID behavior, and limit via the 25-max truncation note.

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 opens with a specific verb and resource: indexed search across ALL mailboxes via Mail's Envelope Index, fast and read-only. It clearly distinguishes this tool from siblings by naming mail_overview and mail_index_bodies where their roles matter, and by explaining scope such as all mailboxes and optional ANDed filters.

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?

It explicitly states conditions: at least one filter is required, body search requires mail_index_bodies first and is best-effort, mailbox names must match mail_overview output, and account-name lookups launch Mail while UUID lookups stay pure sqlite. It also tells the agent not to treat a truncated result as exhaustive, which is a usage constraint beyond basic invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.