Skip to main content
Glama
googlarz

Proton Mail Bridge MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

update_message_flags

Add or remove custom IMAP flags on a single email, then verify server application. Returns flags not applied for precise control.

Instructions

Add or remove arbitrary IMAP flags on a single message, then verify the server applied them. Prefer bulk_update_flags to update flags across multiple messages at once. Returns notApplied[] listing flags the server silently dropped. Use for custom IMAP flags (e.g. \Answered) or when mark_email_read / star_email don't cover the flag you need. \Seen/\Flagged/\Deleted are gated the same as mark_email_read/star_email/delete_email: each requires the matching action in PROTONMAIL_ALLOWED_ACTIONS, and setting \Deleted also requires confirmed:true when PROTONMAIL_CONFIRM_DESTRUCTIVE is enabled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailIdYesComposite email id in FOLDER::UID format.
confirmedNoPass true to confirm setting \\Deleted. Required when PROTONMAIL_CONFIRM_DESTRUCTIVE is enabled.
flagsToAddNoIMAP flags to set, e.g. ["\\Seen", "\\Flagged", "\\Answered"].
flagsToRemoveNoIMAP flags to clear.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.37
    • addedInput schema / properties / confirmed
      Added value: +{
+  "description": "Pass true to confirm setting \\\\Deleted. Required when PROTONMAIL_CONFIRM_DESTRUCTIVE is enabled.",
+  "type": "boolean"
+}
  2. Addedv1.17.0
  3. Removedv1.13.11
  4. Addedv1.13.4

TDQS

A4.4/5.0
Behavior4/5

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

The description discloses verification behavior ('then verify the server applied them'), the notApplied[] return, and gating rules for \Seen/\Flagged/\Deleted, including the confirmed:true requirement. Since annotations only provide destructiveHint=false, this adds significant behavioral context beyond them.

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 dense but well-structured: it front-loads the core action, then adds routing and gating details. While slightly long, every sentence contributes value and it avoids redundancy.

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?

Even without an output schema, the description states what is returned (notApplied[]). It covers usage, gating, alternatives, and required confirmation for destructive flags. For a 4-parameter tool with no output schema, this is thoroughly complete.

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 all parameters are already documented in the schema. The description references flagsToAdd/confirmed in the gating context but doesn't add new per-parameter meaning beyond what's in the schema, justifying the baseline 3.

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+resource: 'Add or remove arbitrary IMAP flags on a single message' and adds verification. It clearly distinguishes from sibling tools like bulk_update_flags and mark_email_read/star_email, so an agent can immediately understand its unique scope.

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 says to prefer bulk_update_flags for multiple messages, and directs use for custom flags or when mark_email_read/star_email don't cover a flag. This provides clear when-to-use and alternatives, leaving no ambiguity.

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

Deploy Server

Other Tools