mcp-proton-mail

Overview Schema Source Related Servers Discussions Admin

Preview, run or cancel a search-index rebuild

reindex

Preview, start, or cancel a rebuild of the local search index when search results report incomplete coverage; mail, flags, and folders are never changed.

Instructions

Preview, start or cancel a full rebuild of the local search index, chosen by op; mail, flags and folders are never changed.

Use it when search results report incomplete index coverage (index_note, index_status) or the user asks for a rebuild. Check reindex_status first: it reports progress and changes nothing. A rebuild only reads mail and writes a separate local candidate index.

op="preview" takes no other argument and starts nothing. It returns current indexed and All Mail counts, missing count, ETA, log_id and a single-use token that expires after five minutes. Present it for explicit user approval; reindex has no form. Counts describe All Mail; ETA also includes LIST-vetted real-folder copies, from their STATUS counts. Label views are excluded.

op="execute" takes only token: only call after the user explicitly approved the preview. It returns log_id and run_id at once while the rebuild runs in the background; poll reindex_status. One rebuild runs at a time: an already running refusal includes its run_id and never queues another. Search keeps using the old index. A separate read-only IMAP connection reads All Mail and real folders at a capped rate, and rechecks folder UIDVALIDITY and live inventories before the final All Mail validation. The candidate replaces the live index only at >=99% of the current All Mail count; otherwise, or after any folder error or a cancellation, the old index stays and status says why.

op="cancel" takes only run_id, from op="execute" or reindex_status: it stops that rebuild and discards its candidate, keeping the old index. Poll reindex_status until the run reports cancelled.

Any other mix of arguments refuses. An expired or used token refuses: preview again.

Input Schema

Name	Required	Description
`op`	Yes	preview takes no other argument, execute takes only token and cancel takes only run_id.
`token`	No	With op="execute": the token from the preview the user approved.
`run_id`	No	With op="cancel": the run_id from op="execute" or reindex_status.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Far beyond the annotations: it discloses the candidate-index isolation, the 99% All Mail threshold before the candidate replaces the live index, UIDVALIDITY/inventory rechecks, capped read rate, single-run concurrency with refusal payload, five-minute single-use token, and token expiry recovery. The only residual gaps are the refusal semantics for a stale run_id and whether a failed execute consumes the token, which are left partial.

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?

Front-loaded and organized per op, with the invariant up front and each action in its own paragraph. It is on the long side for three parameters, and the sentence about All Mail counts versus LIST-vetted folder copies in the ETA borders on return-value explanation that the output schema already covers.

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?

An output schema exists, so return shapes need not be restated, and the description still covers prerequisites, approval gating, concurrency, failure and cancellation outcomes, and post-call polling. An agent has everything needed to call this correctly on the first attempt.

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 the baseline is 3; the description still adds real meaning by pairing each op value with its permitted companion argument, stating that any other mix refuses, giving the five-minute single-use token lifetime, and citing both sources of run_id for cancel.

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 opening sentence names the specific resource (local search index), the three actions (preview/start/cancel), the discriminator (chosen by op), and the key invariant (mail, flags and folders are never changed). It is immediately distinguishable from the sibling reindex_status, which is explicitly named as the progress-only counterpart.

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?

Trigger conditions are explicit: search results report incomplete coverage via index_note/index_status, or the user asks for a rebuild. It names the alternative (reindex_status) and the ordering rule (check it first), and gates execute on explicit user approval of the preview.

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