protonmail-mcp-server

by mattias242

Overview Schema Source Related Servers Discussions Admin

Python

Local

Lägg till etikett

add_label

Idempotent

Add a label to one or more ProtonMail emails without moving them from their folder; the label must already exist.

Instructions

Lägg till en etikett (Labels/…) på ett mejl. Mejlet ligger kvar i sin mapp.

I Proton kan ett mejl ha många etiketter men ligger i exakt en mapp. Verktyget gör UID COPY till etiketten, vilket hos Bridge betyder "lägg till etiketten" — mejlet flyttas inte och inget annat ändras. Har mejlet redan etiketten händer inget märkbart.

Etiketten måste finnas. Skapa den annars först med create_folder("Labels/Namn"); list_mailboxes visar vilka som finns. Finns den bara med annan versal/gemen (t.ex. "Faktura" när label är "faktura") används den befintliga; skapa ingen dubblett.

Avvisas med fel (inget ändras):

etiketten finns inte, eller finns i flera varianter med olika versaler men inte med exakt det namnet (felet räknar upp dem),
label är Starred (använd flag_email), en mapp (Folders/…, använd move_email) eller en systemmapp (INBOX, Trash …),
mailbox är etiketten själv,
UID:t finns inte i mailbox (UID:n gäller per mapp),
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 tillagd. Med en lista med UID:n blir svaret {"ok": [UID, ...], "failed": [{"uid": ..., "error": ...}]}: ett resultat per UID. UID:n som inte finns i mailbox eller som Bridge nekar hamnar i failed medan de andra genomförs. Ett ogiltigt UID (inte heltal) eller fler än 100 avvisar hela anropet innan något ändras.

Input Schema

Name	Required	Description
`uid`	Yes	Mejlets 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": ...}]}.
`label`	Yes
`mailbox`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: it explains the UID COPY mechanism, that nothing is moved or otherwise altered, the idempotent no-op when the label already exists, per-folder UID scoping, and partial-failure batch semantics with pre-mutation validation. This is a mutation tool whose side effects are fully disclosed.

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?

Purpose is front-loaded and the bulleted rejection cases are scannable, but the entry is long and the case-variant label rule plus the repeated return-value explanation push it past what is strictly necessary. Every sentence is informative, though some could be tightened.

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 three-parameter mutation tool with a batch mode, the description covers preconditions, error taxonomy, side effects, and return shape. Even though an output schema exists, the explanation of the ok/failed batch result is a useful complement rather than a gap-filler.

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?

With only 33% schema coverage, the description carries the load: it defines uid as a per-mailbox identifier accepting up to 100 values, tells the agent to take mailbox from list_emails/search_emails/get_email output, and clarifies that label may be given with or without the 'Labels/' prefix. It adds real meaning beyond the bare 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?

States a specific verb and resource ('Lägg till en etikett (Labels/…) på ett mejl') and immediately bounds the effect ('Mejlet ligger kvar i sin mapp'). It also implicitly distinguishes itself from move_email and flag_email by naming them as the correct tools for folders and Starred.

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?

Explicit routing rules: use flag_email for Starred, move_email for Folders/…, create_folder to create a missing label, and list_mailboxes to discover existing ones. It also states when the tool is rejected, which is exactly the when-not guidance an agent needs.

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