protonmail-mcp-server

by mattias242

Overview Schema Source Related Servers Discussions Admin

Python

Local

Flytta mejl

move_email

Destructive

Move a ProtonMail email to another folder by UID; only that email changes. Supports batch moves up to 100 UIDs.

Instructions

Flytta ett e-post till en annan mapp. Bara det angivna mejlet påverkas.

Verktyget är till för mappar: INBOX, Archive, Spam, Trash och Folders/…. Mejlet flyttas dit och försvinner ur källmappen.

Proton skiljer på mappar och etiketter. Är målet en etikett (Labels/…) läggs etiketten till och mejlet ligger kvar i källmappen; är källan en etikett tas den etiketten bort. För etiketter finns add_label och remove_label, för stjärnmärkning flag_email och unflag_email.

Avvisas med fel (inget ändras):

källa och mål är samma mapp (i Trash/Drafts skulle Bridge radera mejlet),
flytt till eller från All Mail, och mellan INBOX och Sent (Bridge nekar),
flytt till Starred (Bridge skulle ta bort mejlet ur källmappen) — stjärnmärk med flag_email i stället,
flytt till Trash eller Drafts från en etikett eller Starred, eftersom mejlet redan kan ligga där och då raderas permanent,
UID:t finns inte i källmappen (UID:n gäller per mapp). Vakterna gäller också när en lista med UID:n anges.

Ligger mejlet redan i Trash (eller Drafts, vid flytt dit) görs ingenting med det: ett Proton-mejl kan synas i flera mappar samtidigt, t.ex. ett mejl till sig själv i både INBOX och Sent, och Bridges vyer släpar 20–40 s efter en flytt. En ny flytt dit skulle få Bridge att radera mejlet permanent. Mejlet räknas som ok och svaret förklarar det i "note". Samma mejl känns igen på Protons mejl-id; går det inte att avgöra (flera likadana mejl i målet) flyttas mejlet inte och det blir ett fel.

Args: uid: UID:t som sträng, eller en lista med upp till 100 UID:n ur samma källmapp target_mailbox: Målmapp att flytta till mailbox: Källmappen, dvs. 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.

Returns: True när flytten är klar. Misslyckas den kastas ett fel med Bridges förklaring. Låg mejlet redan i Trash/Drafts blir svaret {"ok": [UID], "failed": [], "note": "... ligger redan i papperskorgen ..."} i stället för True. Med en lista med UID:n blir svaret {"ok": [UID, ...], "failed": [{"uid": ..., "error": ...}]}: ett resultat per UID, i ett enda IMAP-kommando. UID:n som inte finns eller som Bridge nekar hamnar i failed medan de andra genomförs. UID:n vars mejl redan låg i målet räknas som ok och nämns i "note". 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": ...}]}.
`mailbox`	Yes
`target_mailbox`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.4.0Oct 21, 2026

removedInput schema / properties / mailbox / default
```
Removed value: -"INBOX"
```
addedInput schema / properties / mailbox / maxLength
```
Added value: +255
```
addedInput schema / properties / mailbox / minLength
```
Added value: +1
```
addedInput schema / properties / target_mailbox / maxLength
```
Added value: +255
```
addedInput schema / properties / target_mailbox / minLength
```
Added value: +1
```

addedInput schema / properties / uid / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "maxItems": 100,
+    "minItems": 1,
+    "type": "array"
+  }
+]

addedInput schema / properties / uid / description

Added value: +"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\": ...}]}."

removedInput schema / properties / uid / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "uid",
-  "target_mailbox"
-]New value: +[
+  "uid",
+  "target_mailbox",
+  "mailbox"
+]

addedOutput schema / properties / result / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "additionalProperties": true,
+    "type": "object"
+  }
+]

removedOutput schema / properties / result / type
```
Removed value: -"boolean"
```

First observedv0.1.0Jul 31, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, but the description adds substantial beyond-annotation context: the specific Bridge-side guards that reject a move, the 20-40s view lag, the idempotent Trash/Drafts no-op behavior, and the note field explanation. However, it does not describe authentication or rate-limit concerns, and much of the mutation-risk detail is partly implied by the destructive annotation.

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 purpose and folder-vs-label routing are front-loaded, and the bulleted rejection list is well structured. The main cost is the lengthy 'Returns' section, which largely duplicates the existing output schema and the rest of the prose, so it is slightly longer than it needs to be.

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, multi-UID mutation tool with only 33% schema coverage, the description covers the source/mailbox requirement, the batch response shape, per-UID failure handling, guard conditions, and the Trash/Drafts special case. Combined with the output schema and annotations, an agent has everything needed to invoke it correctly.

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?

Schema description coverage is only 33% (mailbox and target_mailbox are undocumented in the schema), so the description carries real weight: it defines mailbox as the source folder, stresses that UIDs are per-mailbox, and tells the agent to reuse the mailbox field from list_emails/search_emails/get_email responses. The uid semantics (string or list of up to 100 from the same source) are also clarified here.

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 ('Flytta ett e-post till en annan mapp') and immediately scopes it ('Bara det angivna mejlet påverkas'). It explicitly distinguishes its domain from siblings by naming add_label, remove_label, flag_email and unflag_email and explaining that labels behave differently from folders.

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 routing: folders are handled here, labels are handled by add_label/remove_label, starring by flag_email/unflag_email. It also enumerates the exact conditions that are rejected (same source and target, All Mail, INBOX<->Sent, Starred, Trash/Drafts from a label) so the agent knows when NOT to call it.

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