Skip to main content
Glama
googlarz

Proton Drive MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Read synced text file

drive_read_file
Read-onlyIdempotent

Read UTF-8 text files up to 1 MB from a synced Proton Drive folder. Use for quick access to synced notes or configs; binary or larger files need the download tool.

Instructions

Read a UTF-8 text file (max 1 MB) from the local Proton Drive sync folder. Requires PROTON_DRIVE_SYNC_PATH pointing at the sync root, the desktop app running and the file synced. Binary, non-UTF-8 or larger files error — use drive_download.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute remote Drive path of the file to read (must start with '/'). /my-files/<rest> maps to <PROTON_DRIVE_SYNC_PATH>/<rest>; only /my-files is synced, other Drive roots are rejected. A path not starting with a Drive root is taken relative to the sync folder. E.g. /my-files/notes.txt

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedInput schema / properties / path / description
      Previous value: -"Absolute remote Drive path of the file to read (must start with '/'). Mapped to the local sync folder. E.g. /my-files/notes.txt"New value: +"Absolute remote Drive path of the file to read (must start with '/'). /my-files/<rest> maps to <PROTON_DRIVE_SYNC_PATH>/<rest>; only /my-files is synced, other Drive roots are rejected. A path not starting with a Drive root is taken relative to the sync folder. E.g. /my-files/notes.txt"
  2. Addedv0.1.2

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, not open-world), and the description adds substantial context beyond them: the 1 MB cap, the UTF-8-only constraint, the required environment variable and running desktop app, and which input classes produce errors. This is exactly the runtime behavior an agent cannot infer from annotations.

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?

Three dense sentences: what it reads, what it requires, and what fails. Constraints and prerequisites are front-loaded and every clause carries information, with no filler.

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 single-parameter read tool with no output schema, the definition covers prerequisites, limits, and failure modes well. It never states that the return value is the decoded file text (or how the content is framed), which is the one remaining inference an agent must make.

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 100%, so the path parameter's format, /my-files mapping, and relative-path fallback are already fully documented in the schema. The description adds no path syntax or format detail beyond it, so the baseline 3 applies.

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 (Read), resource (UTF-8 text file), scope (max 1 MB, local Proton Drive sync folder), and explicitly names the sibling it is not for unsupported inputs (drive_download). An agent can distinguish it from drive_download without opening either schema.

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?

Gives explicit preconditions (PROTON_DRIVE_SYNC_PATH set, desktop app running, file synced) and a clear when-not rule routing binary, non-UTF-8, or oversized files to drive_download. It does not, however, address the closer sibling drive_read_content, leaving one plausible alternative unmentioned.

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