A hardened Model Context Protocol server for pCloud, exposing file management tools (list, download, upload, delete, share, create folders) over stdio or authenticated HTTP.
pcloud-mcp demonstrates solid tool design with consistent naming (verb_noun pattern), comprehensive parameter schemas, and clear descriptions. All 12 tools have explicit input schemas with typed parameters and descriptions. Tool names are action-oriented (list_, download_, upload_, create_, delete_, move_, share_, save_). Descriptions average ~120 chars and explain WHAT the tool does and WHEN to use it. However, output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling lacks recovery guidance (no 'try X instead' patterns). Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present but not formally integrated into schema. Parameter descriptions could be more prescriptive about constraints (e.g., folder_id 0 for root is mentioned but not formalized as a constraint).
Create a new folder inside a pCloud parent folder. Use parent_id 0 for the account root.
Create a public upload link for a pCloud folder. ANYONE with the returned URL can upload files into that folder without signing in — useful for collecting files from a phone or another person. Confirm intent before creating; it opens an unauthenticated write path into the account.
Permanently delete a pCloud file by file_id. This cannot be undone.
Permanently delete a pCloud folder by folder_id, including ALL of its contents, recursively. This cannot be undone.
Download a single pCloud file to a local directory. Provide file_id and the file's name (both from pcloud_list_folder) and a local destination directory. The name is validated to prevent path traversal.
Output schemas not documented. LLMs cannot predict response structure (e.g., what fields does pcloud_list_folder return? Is it {items: [{name, id, isFolder}]}?). This breaks tool chaining, agents cannot extract folder_id from list results to pass to download_folder without guessing.
Error handling lacks recovery guidance. Errors do not tell LLMs what to do next (e.g., 'file_id not found, call pcloud_list_folder to discover valid IDs'). Raw error codes or stack traces give agents nothing actionable.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | <=2025-11-25 | v2 |
Download a pCloud folder and its entire subtree to a local directory, mirroring the structure under destination/<name>. Every remote name is validated to prevent path traversal; the download aborts if any name is unsafe.
List the immediate contents of a pCloud folder. Use folder_id 0 for the account root. Returns each child's name, id, and whether it is a folder.
Rename and/or move a pCloud file. Set new_name to rename, to_folder_id to move; either or both may be provided.
Rename and/or move a pCloud folder. Set new_name to rename, to_folder_id to move; either or both may be provided.
Save text content directly into a new pCloud file (e.g. a note, summary, or generated document) without needing a local file. Provide folder_id (0 = root), a file name, and the text content.
Create a public share link for a pCloud file. Anyone with the link can access the file, so confirm intent before sharing.
Upload a local file into a pCloud folder. Use folder_id 0 for the account root. By default the local file name is kept; set name to store under a different name.
Destructive operations (delete_file, delete_folder) lack confirmation/dry-run support. Agents make mistakes, no confirm_before_execute pattern to prevent accidental data loss.
Parameter constraints not formalized. 'folder_id 0 for root' is mentioned in descriptions but not declared as a constraint (e.g., enum or pattern). LLMs may pass invalid IDs without validation feedback.
Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) are metadata but not integrated into tool schema. LLMs cannot parse these from the tool definition, they must be encoded in descriptions or as formal schema hints.