Skip to main content
Glama
googlarz

Proton Drive MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

List folder

drive_list
Read-onlyIdempotent

List immediate files and folders in a Proton Drive folder, one level deep and not recursive, with pagination and name sorting. Use '/' to get top-level roots.

Instructions

List the immediate children of a Proton Drive folder (one level, not recursive). Listing '/' returns the top-level roots. Returns {items, total, offset, limit, hasMore} (default limit 200, sorted by name); items are [{name, path, type ('file'|'folder'), size? (bytes), storageSize? (encrypted, all revisions), modifiedAt?, mimeType?, mtime? (original local modification time), uploadedAt? (revision upload time), sha1? (hash CLAIMED by the uploader: unverified and often absent)}]. Items come in a stable sorted order; each page is a fresh read, so changes between page calls can still shift items. Use drive_list_trash for the trash.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute remote path, e.g. /my-files/Reports.
typeNoOnly list items of this type (default: both).
limitNoMax items to return (default 200).
offsetNoNumber of items to skip (default 0).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • addedInput schema / properties / type
      Added value: +{
+  "description": "Only list items of this type (default: both).",
+  "enum": [
+    "file",
+    "folder"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv1.2.0
    • changedInput schema / properties / path / description
      Previous value: -"Absolute remote Drive path to list (must start with '/'). E.g. /my-files or /my-files/Reports"New value: +"Absolute remote path, e.g. /my-files/Reports."
  3. Changed2 schema fields changedv1.0.38
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Max items to return (default 200).",
+  "maximum": 1000,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Number of items to skip (default 0).",
+  "minimum": 0,
+  "type": "integer"
+}
  4. Changed1 schema field changedv0.1.2
    • changedInput schema / properties / path / description
      Previous value: -"Remote Drive path to list. E.g. /my-files"New value: +"Absolute remote Drive path to list (must start with '/'). E.g. /my-files or /my-files/Reports"
  5. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only establish read-only/idempotent, yet the description discloses pagination behavior (default limit 200, offset, hasMore), stable sorted order, the caveat that each page is a fresh read so items can shift between page calls, and the important trust caveat that sha1 is a claimed, unverified, often-absent hash. These are real behavioral traits not derivable from the annotations or schema.

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?

Front-loads the core operation and scope in the first clause, then layers return shape and caveats in a logical order. It is dense and one parenthetical field list is long, but every element carries information an agent needs given the absence of an output schema.

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?

With no output schema, the description fully carries the return contract: the response envelope, item field meanings, sorting, pagination, and the trust caveat on sha1. Combined with the read-only annotations, an agent has everything needed to call it and interpret the result.

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 all four parameters are already documented, including the type enum and limit/offset defaults. The description's field-level explanation (storageSize, mtime, uploadedAt, sha1) describes returned items rather than refining parameter meaning, so it adds little on this axis beyond the schema baseline.

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 ('List the immediate children of a Proton Drive folder') and immediately bounds the scope with '(one level, not recursive)', which also separates it from the recursive drive_tree sibling. The note that listing '/' returns top-level roots removes the main ambiguity about the path parameter's root case.

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?

Explicitly routes trash browsing to drive_list_trash and clarifies the non-recursive scope, so the agent knows when not to use it. It does not, however, contrast against drive_tree or drive_search, which an agent might reasonably confuse it with given 48 siblings.

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