Skip to main content
Glama
proton-mcp

proton-mcp

by RndmJoker

Save an attachment as a file

save_attachment

Saves a Proton Mail message attachment to the configured local directory so you can open or work with it; saved files are temporary and do not overwrite existing files.

Instructions

Saves one attachment of a message as a file on this machine, so it can be opened or worked with, a PDF or a spreadsheet for instance. The index comes from the attachment list in get_message. Only works once the user has set PROTON_MCP_ATTACHMENT_DIR to a directory; without it the answer says how to set it up, which is worth passing on. The file goes into that directory or a folder inside it, never anywhere else, and never replaces an existing file. It is deleted 1 hour(s) after saving and when this server stops, so copy it if you need it longer or elsewhere, or fetch it again. Its content comes from a third party.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "messageId": "<messageId>",
      "index": "<index>"
    },
    "name": "save_attachment"
  }
}

Input Schema

NameRequiredDescriptionDefault
indexYesIndex of the attachment, as shown by get_message. Starts at 0.
folderNoOptional: a folder inside the configured directory, absolute or relative to it, created if missing and removed again once the files saved into it are gone. Anything outside the directory is refused.
mailboxNoOptional: the mailbox to look in first.
messageIdYesThe message id the attachment belongs to.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.13

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, it discloses the required environment setup, the path confinement rule, the no-overwrite behavior, the one-hour and server-stop deletion lifetime, and that attachment content is third-party. These are exactly the operational and safety details an agent needs before invoking a file-writing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and then covers index source, prerequisite, path rules, lifetime, and third-party content in compact sentences. Every sentence adds useful information, and there is no redundant framing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a file-writing tool with no output schema, the description covers the important prerequisites, side effects, and lifetime constraints. However, it does not say what a successful call returns, such as the saved file path or filename, which the agent likely needs in order to open or work with the file.

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 description coverage is already 100%, so the schema carries the parameter semantics. The description adds that index comes from the attachment list in get_message and restates folder confinement, but it does not add much beyond the schema and does not explain the mailbox parameter's behavior.

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 uses a specific verb and resource: saving one attachment of a message as a file on the local machine. It immediately explains the practical purpose (opening or working with the file) and how to identify the attachment via get_message, which distinguishes it from content-fetching siblings such as get_attachment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: the index must come from get_message, and the tool only works after PROTON_MCP_ATTACHMENT_DIR is configured. It also explains what to do if setup is missing. It does not explicitly compare this tool with get_attachment or delete_saved_attachments, so the alternative-selection guidance is not fully complete.

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