macos-apps-mcp

Overview Schema Source Related Servers Discussions Admin

mail_index_bodies

Read-only

Build or refresh the searchable body index for local .emlx email files, enabling body search in the mail_search tool without modifying Mail's data.

Instructions

Build/refresh the opt-in FTS body index used by mail_search(body=…). Reads every .emlx file at rest, .partial ones included (never launches Mail, never writes in Mail's data). Resumable and size-capped — safe to re-run; a re-run continues where it left off. rebuild=True re-indexes from scratch. Returns {indexed, skipped, total_emlx, capped, indexed_this_run}. Read-only for Mail; the one thing it writes is this server's own FTS sidecar. Needs Full Disk Access (it reads .emlx at rest), NOT Automation.

indexed_this_run is THIS RUN's progress, NOT coverage: a resumable indexer's own counters cannot say how much of the store is searchable (a fully-indexed store re-runs as "14 newly indexed"). mail_search(body=…) is the one place that answers "is body search usable?", and it does so on the path that needs it — an empty result.

A .partial.emlx is missing its ATTACHMENTS, not its body, so partials are indexed like any other message (#119). The residual unsearchable tail is ~0.5%: messages Mail never stored a text part for.

Input Schema

Name	Required	Description	Default
`rebuild`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.15.1Oct 26, 2026

TDQS

A3.9/5.0

Behavior1/5

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

The description contradicts the readOnlyHint=true annotation: it says the tool builds/refreshes an index and explicitly writes the server's own FTS sidecar. Even though it clarifies that Mail's data is not modified and that Full Disk Access is required, the tool-level readOnly annotation is inconsistent with the disclosed sidecar write.

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 and information-dense, but it is long and includes some repetition around resumability and safe re-runs. Most sentences add real value, though the prose could be tightened without losing meaning.

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?

It covers permissions (Full Disk Access, not Automation), write scope (Mail untouched, FTS sidecar written), resumability and size caps, partial .emlx handling, residual unsearchable tail, and return-shape context. This is highly complete for a complex indexing tool.

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%, but the description fully explains the only parameter: rebuild=True re-indexes from scratch, while normal runs resume where they left off. That is exactly the semantic detail an agent needs beyond the bare boolean 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?

The description states a specific verb and resource: build/refresh the opt-in FTS body index used by mail_search(body=…). It clearly scopes what is indexed and how it relates to a sibling consumer tool, leaving little ambiguity about the tool's purpose.

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?

It explains resumability, safe re-runs, and when rebuild=True applies, and it routes the question 'is body search usable?' to mail_search(body=…). It does not explicitly compare against other index-related siblings such as mail_index_ids, but the operational guidance is otherwise clear.

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

Deploy Server