mcp-proton-mail

Overview Schema Source Related Servers Discussions Admin

Check search-index rebuild progress

reindex_status

Read-onlyIdempotent

Reports progress and state of the current or last search-index rebuild so you can poll after an execute request and judge whether search results may be incomplete; it never starts or resumes rebuilds.

Instructions

Report the progress of the current or last search-index rebuild; contacts no Bridge and changes nothing.

Use it to poll after reindex(op="execute"), or to judge whether search results may be incomplete. It never starts or resumes a rebuild: use reindex for that.

Returns state (idle, rebuilding, running, succeeded, failed or cancelled), progress, ETA, last error, run_id and the swap outcome and reason. last_full_run groups the current or last full rebuild's old_count, new_count and all_mail_count: last_full_run.all_mail_count is the count at that full rebuild, while top-level all_mail_count is the live count from the latest locally observed inventory, beside all_mail_max_uid and all_mail_observed_at. indexed_count and indexed_max_uid always read the serving index. target is the last observed All Mail total; percent is indexed_count divided by target, clamped to 0..100 (100 for an empty target, null if unknown). last_catchup_at is the last incremental sync or committed automatic recovery batch; last_expunge_reconciliation_at the last inventory reconciliation. Timestamps survive restart, unavailable fields are null, and UID maxima are strings ("0" when empty).

A manual rebuild's progress and ETA include All Mail and real-folder header copies. Automatic startup recovery reports source="auto" and state="rebuilding", counts All Mail only and reports success after real folders are also checked; max_uid then aliases all_mail_max_uid, and last_full_run still describes the manual rebuild. Its ETA is null until new indexed headers give an observed rate. A previous successful run never reports succeeded while headers are missing. With the optional background sync on, a background_sync object adds active, last_outcome and last_skip_reason (fixed codes), last_tick_at, commands_today, rows_today and their daily limits.

Input Schema

Name	Required	Description	Default
No arguments

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

Behavior5/5

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

Annotations already cover read-only/idempotent/no-destruction, yet the description goes well beyond them: the full state vocabulary, ETA semantics for manual vs auto recovery, null-on-unavailable behavior, string-typed UID maxima, and the rule that a previous success never reports succeeded while headers are missing. This is exactly the kind of behavioral context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and usage are front-loaded and efficient, but the long middle block enumerates individual return fields (all_mail_max_uid, indexed_max_uid, last_catchup_at, percent clamping rules) that an output schema already documents. Useful detail, but it makes the definition much longer than needed for selection.

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?

For a zero-parameter status tool this is more than complete: it covers states, ETA caveats, auto vs manual recovery differences, and background sync extras. The only flaw is redundancy against the existing output schema rather than any missing information.

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?

There are zero input parameters, so the baseline is 4 and there is no parameter meaning to add. The description instead spends its space on return-field semantics, which is a different axis and partly overlaps the output 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 opening clause names a specific verb and resource ('Report the progress of the current or last search-index rebuild') and immediately contrasts with the sibling that mutates state ('It never starts or resumes a rebuild: use reindex for that'). An agent can distinguish it from reindex without opening either schema.

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?

Gives explicit when-to-use ('poll after reindex(op="execute")', 'judge whether search results may be incomplete') and an explicit exclusion ('never starts or resumes a rebuild: use reindex for that'). The alternative tool is named and the condition that selects it is stated.

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