Skip to main content
Glama
googlarz

Proton Drive MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Move item

drive_move

Move or rename a Proton Drive file or folder by setting the full destination path; use a new filename to rename or a new parent to relocate. Fails if target exists or parent is missing.

Instructions

Move or rename a file or folder. destinationPath is the FULL new path (not the parent folder): same parent + new filename renames, a different parent moves. Fails if destinationPath is occupied or its parent is missing. To keep the original use drive_copy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourcePathYesAbsolute remote path to move.
destinationPathYesAbsolute remote destination path (full new path); parent must exist.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • changedInput schema / properties / destinationPath / description
      Previous value: -"Absolute remote destination path (must start with '/'). Parent folder must exist."New value: +"Absolute remote destination path (full new path); parent must exist."
    • changedInput schema / properties / sourcePath / description
      Previous value: -"Absolute remote path of the file or folder to move (must start with '/')."New value: +"Absolute remote path to move."
  2. Changed2 schema fields changedv0.1.2
    • changedInput schema / properties / destinationPath / description
      Previous value: -"New remote path."New value: +"Absolute remote destination path (must start with '/'). Parent folder must exist."
    • changedInput schema / properties / sourcePath / description
      Previous value: -"Current remote path of the file/folder."New value: +"Absolute remote path of the file or folder to move (must start with '/')."
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only supply destructiveHint=false, so the description carries most of the burden and does well: it discloses the two failure modes (destination occupied, parent missing) and the full-path requirement. It doesn't say what happens to an existing target or whether the operation is reversible/overwriting, but the added context is solid.

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 tight sentences, zero waste, with the core behavior front-loaded and the alternative/edge cases trailing. Every sentence earns its place.

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?

With no output schema and minimal annotations, the description adequately covers action, semantics, failure modes, and an alternative. Only the omission of a pointer to drive_rename and any note on overwrite/reversibility behavior leaves a small gap.

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 100%, so baseline is 3, but the description genuinely adds semantics the schema doesn't: destinationPath is the FULL new path, not the parent, and the rename-vs-move distinction follows from that. This is real meaning beyond the raw field docs.

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+resource ('Move or rename a file or folder') and immediately clarifies the overloaded behavior that distinguishes it from a plain rename tool: same parent + new filename renames, different parent moves. An agent can tell exactly what this does.

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?

Names the alternative explicitly ('To keep the original use drive_copy') and gives the condition that selects it, plus the failure conditions (destination occupied, parent missing). It does not address the sibling drive_rename, which is the closest potential source of confusion, keeping it just short of a 5.

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