mcp-proton-mail

Overview Schema Source Related Servers Discussions Admin

Mark approved mail read or unread

set_read_state

Destructive

Marks approved messages as read or unread by setting or clearing Seen; requires an approved preview token and changes only the Seen state.

Instructions

Mark the approved messages read or unread by setting or clearing Seen; only call after the user explicitly approved the preview.

Use it only with a mark_read (state="read") or mark_unread (state="unread") token from preview_action that the user approved, or the continuation_token of that approval; the wrong state refuses before the form. Unless the operator turned it off, the user then confirms the exact change in the client's form. Only Seen changes. limit caps the messages this call processes.

Returns log_ids (a list even for zero or one chunk), counts, run/continuation state and message IDs; verbose=true adds full rows. Pass each log_id to undo_action, which restores each message's prior state. Any untouched remainder gets a continuation, redeemed with the same state; a continuation reports a changed row in blocked_ids and leaves it untouched. An expired, used or unknown token refuses: preview again.

Input Schema

Name	Required	Description
`limit`	No	Messages to process in this call, 1 to 200. A value above the approved total refuses and keeps the token.
`state`	Yes	read redeems a mark_read preview and unread a mark_unread preview. The other value refuses without consuming the token.
`token`	Yes	Single-use token from the preview the user approved, or the continuation_token of an earlier partial run of that approval.
`verbose`	No	true adds messages and replaces blocked_ids, missing_ids and mismatched_ids with full blocked, missing and mismatched rows.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and non-idempotent, but the description adds substantial behavior beyond them: only Seen changes, an optional client-side confirmation form, token refusal on wrong state, continuation semantics for untouched remainders, and how blocked_ids marks a changed row. The only thing not covered is rate/performance expectations, which is minor for a mailbox-scale operation.

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 gate ('only call after the user explicitly approved') is front-loaded and the token/continuation lifecycle follows logically. It is dense but almost every clause carries distinct operational information; the return-value sentence is partly redundant given the output schema.

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?

For a destructive, token-gated mutation, the description covers the full lifecycle: acquisition, state matching, confirmation, partial runs via continuation, blocked/refused tokens, and undo. Given the output schema exists, the extra prose about log_ids and verbose is redundant but not a completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents limit, state, token and verbose in detail. The description restates limit ('caps the messages this call processes') and that continuation is 'redeemed with the same state', adding modest cross-parameter context rather than new per-parameter meaning — the baseline 3 applies.

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?

States a specific verb and resource — 'Mark the approved messages read or unread by setting or clearing Seen' — and scopes it to approved messages, which separates it from label/move/apply_rules siblings. An agent can tell immediately what this mutates and on what input.

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 an explicit precondition ('only call after the user explicitly approved the preview') and names the token sources from preview_action, plus the misuse case (wrong state refuses before the form). It also names undo_action as the recovery path, so when-to-use and when-not-to-use are both covered.

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