Skip to main content
Glama
mattias242

protonmail-mcp-server

by mattias242

Ta bort etikett

remove_label
DestructiveIdempotent

Removes a specific label from one or more emails without deleting, moving, or otherwise changing them; specify the mailbox UID and label to update.

Instructions

Ta bort en etikett (Labels/…) från ett mejl utan att röra mejlet i övrigt.

Mejlet ligger kvar i sin mapp och behåller sina andra etiketter; det raderas inte och hamnar inte i Trash. Verktyget letar upp mejlets UID i etikettens vy via Message-ID (UID:n gäller per vy) och gör UID EXPUNGE på just det UID:t där, vilket hos Bridge bara tar bort etiketten.

mailbox kan vara mappen där mejlet ligger (t.ex. INBOX) eller etiketten själv (t.ex. "Labels/Kvitton" med UID:t från en listning av etiketten).

Avvisas med fel (inget ändras):

  • mejlet har inte etiketten,

  • etiketten finns inte (create_folder("Labels/Namn") skapar den); finns den bara med annan versal/gemen används den befintliga, och finns flera sådana varianter räknar felet upp dem,

  • label är Starred (använd unflag_email), en mapp eller en systemmapp,

  • UID:t finns inte i mailbox (UID:n gäller per mapp),

  • mejlet saknar ett Message-ID som går att söka på, eller går inte att skilja från ett annat mejl i etiketten — ange då etiketten som mailbox och UID:t därifrån (i en lista gäller felet bara det UID:t),

  • Bridge nekar (felet innehåller Bridges förklaring).

Args: uid: Mejlets UID i mailbox, eller en lista med upp till 100 UID:n ur samma mailbox mailbox: Mappen som UID:t kom från (obligatorisk). UID:n gäller per mapp: samma nummer i en annan mapp är ett annat mejl. Använd fältet mailbox från svaret av list_emails, search_emails eller get_email. label: Etiketten, med eller utan prefix: "Kvitton" eller "Labels/Kvitton"

Returns: True när etiketten är borttagen. Med en lista med UID:n blir svaret {"ok": [UID, ...], "failed": [{"uid": ..., "error": ...}]}: ett resultat per UID. UID:n som inte finns, som saknar etiketten eller som Bridge nekar hamnar i failed medan de andra genomförs. Nekar Bridge borttagningen efter att ha hunnit med en del, kontrolleras vilka mejl som inte längre har etiketten; de räknas som ok. Ett ogiltigt UID (inte heltal) eller fler än 100 avvisar hela anropet innan något ändras.

Input Schema

NameRequiredDescriptionDefault
uidYesMejlets UID i mailbox, eller en lista med upp till 100 UID:n ur samma mailbox. Med en lista blir svaret {"ok": [UID, ...], "failed": [{"uid": ..., "error": ...}]}.
labelYes
mailboxYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds substantial context beyond them: the underlying UID EXPUNGE mechanics against the label's view, per-view UID scoping, and confirmation that the message is not deleted or moved to Trash. Batch semantics are disclosed precisely, including that invalid UIDs or more than 100 abort the whole call before any change, and that partial Bridge denials are re-verified and counted as ok.

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 with the core action and the non-destructive guarantee, then mechanics, error cases, args and returns in a logical order. It is long, and the batch return shape is repeated verbatim in both the description and the uid schema field, which is mild redundancy; for a tool with this many failure modes the length is mostly justified.

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?

Despite an output schema existing, the description still covers return shapes, partial-failure accounting and pre-flight validation, so an agent knows both the success and failure contract. Combined with annotations and the schema, nothing needed to invoke this correctly is missing.

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 only 33%, so the description carries the burden and does: mailbox is explained as per-folder UID scoping plus where to obtain the value (list_emails, search_emails, get_email), label is shown with and without the "Labels/" prefix, and uid batch behavior and the 100-item limit are stated. It adds semantics the schema does not encode.

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 states a precise verb+resource+scope: remove a label from an email without otherwise touching the email, and immediately clarifies that the message is not deleted or moved to Trash. This distinguishes it cleanly from siblings such as delete_email, unflag_email and add_label. An agent can select it without opening the 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?

It names the alternatives and the conditions that route elsewhere: use unflag_email for Starred, use create_folder("Labels/Namn") to create a missing label, and use the label itself as mailbox when Message-ID lookup is ambiguous. It also enumerates the exact rejection conditions (label absent, label missing, system folder, UID not in mailbox, >100 UIDs), which is explicit when-not-to-expect-success guidance.

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