The Proton Drive MCP server enables AI assistants to manage files and folders within your locally synced Proton Drive. It works cross-platform (Windows, macOS, Linux) and all operations are performed locally without sending data to external servers.
Check Drive Access – Verify that Proton Drive is mounted and accessible (check_mount)
List Files & Folders – Browse the contents of any directory within Proton Drive (list_files)
Read Files – Retrieve the text content of a file (read_file)
Write/Create Files – Create new files or overwrite existing ones with text content (write_file)
Delete Files or Folders – Remove files or directories from Proton Drive (delete_file)
Create Folders – Make new directories within Proton Drive (create_folder)
Get File/Folder Info – Retrieve metadata and details about a specific file or folder (get_file_info)
Runs as a Node.js application to interface between AI assistants and the Proton Drive filesystem, with cross-platform support for Windows, macOS, and Linux.
Provides direct access to Proton Drive content, allowing file and folder management through local filesystem operations while preserving Proton's end-to-end encryption.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Proton Drive MCP list files in my Documents folder"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants like Claude Desktop, Cursor, and other MCP-compatible clients to interact with your Proton Drive files.
📁 List files and folders in your Proton Drive
📄 Read file contents directly
✏️ Create and write files to Proton Drive
🗑️ Delete files and folders
📂 Create new folders
🔄 Cross-platform support (Windows, macOS, Linux)
🔒 Secure - Works through local filesystem, no credentials needed
🚀 Easy to install - Just npm install and configure
Related MCP server: Filesystem MCP Server
Node.js 16 or higher
Proton Drive desktop app installed and synced
Claude Desktop, Cursor, or any MCP-compatible client
npm install -g proton-drive-mcpgit clone https://github.com/anyrxo/proton-drive-mcp.git
cd proton-drive-mcp
npm install
npm run buildThe MCP will try to auto-detect your Proton Drive location, but you can also set it manually:
macOS: ~/Library/CloudStorage/ProtonDrive-[email]-folder
Windows: C:\Users\[username]\Proton Drive
Linux: ~/ProtonDrive
Add to your Claude Desktop config:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"proton-drive": {
"command": "node",
"args": ["path/to/proton-drive-mcp/dist/index.js"]
}
}
}Add to your Cursor settings:
{
"mcp.servers": {
"proton-drive": {
"command": "node",
"args": ["path/to/proton-drive-mcp/dist/index.js"]
}
}
}If your Proton Drive is in a non-standard location:
{
"mcpServers": {
"proton-drive": {
"command": "node",
"args": ["path/to/proton-drive-mcp/dist/index.js"],
"env": {
"PROTON_DRIVE_PATH": "/custom/path/to/ProtonDrive"
}
}
}
}Once configured, you can ask your AI assistant:
"List all files in my Proton Drive"
"Create a new file called notes.txt with some content"
"Read the contents of Documents/report.pdf"
"Create a new folder called Projects"
"Delete the file old-notes.txt"
The MCP provides these tools:
Tool | Description |
| Verify Proton Drive is accessible |
| List contents of a directory |
| Read file contents |
| Create or overwrite files |
| Remove files or folders |
| Create new directories |
Test if the MCP is working:
# Check if Proton Drive is detected
npm run test:connection
# Run all tests
npm testMake sure Proton Drive desktop app is running
Check if your files are synced
Set PROTON_DRIVE_PATH environment variable manually
Ensure the MCP has read/write access to your Proton Drive folder
On macOS, you may need to grant permissions in System Preferences
Restart your AI client after configuration
Check the logs for any error messages
Verify the path to the MCP is correct
# Install dependencies
npm install
# Run in development mode
npm run dev
# Build for production
npm run build
# Run tests
npm testContributions are welcome! Please:
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
MIT License - see LICENSE file
All operations are performed locally on your filesystem
No data is sent to external servers
Proton's end-to-end encryption is preserved
Path validation prevents directory traversal attacks
Large files (>10MB) may take time to read
Binary files are not supported for reading (yet)
Some special characters in filenames may cause issues
Issues: GitHub Issues
Discussions: GitHub Discussions
Made with ❤️ for the Proton Drive community
Check if Proton Drive is mounted and accessible
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks if Proton Drive is 'mounted and accessible,' implying a read-only status check, but doesn't describe what 'accessible' means (e.g., permissions, network status), potential side effects, or response format. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but incomplete. It lacks details on what 'mounted and accessible' entails, potential error conditions, or how results are returned, leaving gaps in understanding the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('Proton Drive'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_file_info' which might also provide accessibility information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., when mounting status is relevant), exclusions, or comparisons to siblings like 'list_files' that might indicate accessibility. This leaves usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new folder in Proton Drive
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Folder path relative to Proton Drive root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a mutation operation, the description doesn't specify permissions required, whether the operation is idempotent, what happens if the folder already exists, or any rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with one parameter and no output schema, the description is minimally adequate. However, without annotations or output details, it lacks information about behavioral aspects like error handling or return values, which could be important for mutation operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'path' parameter clearly documented as 'Folder path relative to Proton Drive root.' The description doesn't add any additional meaning beyond what the schema provides, such as path format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new folder') and target resource ('in Proton Drive'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from potential sibling alternatives like 'write_file' or 'check_mount' that might also create folders, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'write_file' (which might create files) and 'delete_file' (which might remove folders), there's no indication of when folder creation is appropriate versus other operations, nor any mention of prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file or folder from Proton Drive
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to delete relative to Proton Drive root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Delete') but does not cover critical traits like whether deletion is permanent or reversible, permission requirements, error handling, or rate limits. This leaves significant gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Delete a file or folder') and specifies the resource context ('from Proton Drive'). It has zero waste, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like safety warnings, return values, or error conditions, which are crucial for a deletion tool. This leaves the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'path' parameter fully documented. The description adds no additional meaning beyond what the schema provides, such as path format examples or deletion scope details. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and resource ('a file or folder from Proton Drive'), distinguishing it from sibling tools like 'create_folder', 'read_file', or 'write_file'. It precisely communicates the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as distinguishing it from 'write_file' for overwriting or 'create_folder' for removal. It lacks context about prerequisites, like verifying existence with 'get_file_info' first, or exclusions, making it minimally helpful for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a file or folder
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file or folder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets information,' which implies a read-only operation, but doesn't specify what type of information (e.g., metadata, permissions, size), whether it requires authentication, or if there are rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns structured information. It doesn't hint at what information is retrieved (e.g., file size, type, timestamps) or how errors are handled, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'path' parameter clearly documented. The description adds no additional meaning beyond what the schema provides, such as path format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('information about a file or folder'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_files' (which lists multiple files) or 'read_file' (which reads file contents), missing an opportunity for clearer sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_files' for listing multiple files and 'read_file' for reading file contents, there's no indication of whether this tool is for metadata retrieval, existence checks, or other purposes, leaving the agent to guess based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and folders in Proton Drive
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path relative to Proton Drive root (e.g., "Documents" or "Projects/2024") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List') but lacks details on permissions, rate limits, pagination, or output format. For a read operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like return values, error handling, or constraints, which are crucial for a tool with potential complexity in file system operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'path' parameter fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 without compensating or detracting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('files and folders in Proton Drive'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get_file_info' or 'check_mount' that might also retrieve file information, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_file_info' (for specific file details) and 'check_mount' (potentially for drive status), there's no indication of appropriate contexts, exclusions, or comparisons, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a text file from Proton Drive
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to Proton Drive root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions reading 'a text file' but doesn't specify encoding, size limits, error handling for non-text files, or authentication requirements. For a file read operation with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a simple read operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file read tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the content is returned in, whether there are encoding considerations, size limitations, or how it handles errors. Given the lack of structured fields, the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'path' already documented in the schema as 'File path relative to Proton Drive root'. The description adds no additional parameter context beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and resource ('a text file from Proton Drive'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_file_info' or 'list_files', but the verb 'Read' suggests content retrieval rather than metadata operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_file_info' (for metadata) or 'list_files' (for directory contents). The description only states what it does, not when it's appropriate or what distinguishes it from similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write or create a file in Proton Drive
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to Proton Drive root | |
| content | Yes | Text content to write to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool writes or creates files but fails to specify critical details: whether it overwrites existing files, requires specific permissions, handles errors (e.g., invalid paths), or has rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy to parse quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file write operation with no annotations and no output schema, the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances like overwriting, which are critical for safe and effective use. This leaves the agent under-informed for a mutation task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('path' and 'content'). The description adds no additional semantic context beyond implying file creation/writing, so it meets the baseline of 3 where the schema does the heavy lifting without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write or create') and resource ('a file in Proton Drive'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling operations like 'create_folder' or 'delete_file' beyond the obvious file vs. folder distinction, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_folder' for directories or 'read_file' for retrieval. It lacks any mention of prerequisites, such as whether the parent directory must exist, or exclusions, like handling existing files, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
check_mountcreate_folderdelete_fileget_file_infolist_filesread_filewrite_fileEach tool has a clearly distinct purpose with no ambiguity: check_mount verifies accessibility, create_folder creates folders, delete_file deletes items, get_file_info retrieves metadata, list_files lists contents, read_file reads text files, and write_file writes files. The actions (check, create, delete, get, list, read, write) and targets (mount, folder, file) are well-defined and non-overlapping.
All tools follow a consistent verb_noun pattern using snake_case, such as check_mount, create_folder, delete_file, get_file_info, list_files, read_file, and write_file. The naming is predictable and readable throughout the set, with no deviations in style or convention.
With 7 tools, the count is well-scoped for a Proton Drive file management server, covering essential operations without bloat. Each tool earns its place by addressing core needs like mounting, CRUD operations, and file listing, making the set efficient and focused.
The tool set provides strong coverage for basic file operations, including create, read, update (via write_file), delete, and list, along with mount checking and metadata retrieval. A minor gap exists in update operations for folders (e.g., rename or move), but agents can work around this using delete and create, and core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/anyrxo/proton-drive-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
