Loading ToolBench
Professional cloud sync & VFS for Obsidian. Features zero-space VFS, 4K streaming, MCP AI engine, and P2P collaboration. Supports Baidu/Aliyun/Quark/WebDAV/S3.
This MCP server exhibits significant quality gaps across naming, descriptions, and schema documentation. While 7 tools are defined, most lack depth in parameter descriptions and output schema documentation. Tool names are moderately clear (authorize, userInfo, storageInfo, download, upload, fileMng) but some are ambiguous (userInfo could be get_user_info; fileMng is non-standard). Descriptions exist but are brief (15-70 chars, well below the 194-char baseline for A+ tools). Most critically, input schemas are visible but sparse on parameter descriptions, e.g., 'fileMng' accepts 'operation' and 'path' with minimal guidance on valid operation values. No output schemas are documented in the source. The server mixes concerns (fileMng bundles list, mkdir, rename, delete, should be split). Error handling is not evident in the code samples provided. This is typical of community/plugin servers that prioritize implementation over agent-friendliness.
Authorize to use sync vault plugin via OAuth2 token acquisition
Download file from cloud storage
Download file from cloud storage and return as string
File management operations (list, create, delete, rename files/folders)
Get cloud storage capacity information (total and used space)
Upload file to cloud storage
Get cloud storage user information
Output schemas not documented for any tool. LLMs cannot infer response structures, forcing them to guess field names and types. This breaks downstream tool composition and forces extra discovery calls.
Tool 'fileMng' bundles four distinct operations (list, mkdir, rename, delete) with conditional parameters. Operation 'rename' requires source+dest path, but schema does not document this dependency. This violates single-responsibility and forces LLMs to reason about parameter combinations.
Tool names do not consistently follow verb_noun convention. 'userInfo', 'storageInfo', 'fileMng' are nouns or abbreviations. LLMs struggle to infer intent from noun-form names. Should be: get_user_info, get_storage_quota, list_files (split from fileMng).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | <=2025-11-25 | v2 |
Parameter descriptions are minimal (15-70 chars, well below 72-char baseline). Many lack examples, constraints, or format specifications. E.g., 'remotePath' in download/upload does not specify: max length, allowed characters, encoding, or whether it supports nested folders with /.
Duplicate/overlapping tools: 'download' and 'downloadFileAsString' both download files but differ only in return type (binary vs string). This forces LLMs to reason about which to call. Should merge into one 'get_file' tool with optional 'as_text' param, or clearly document when each applies.
No error handling guidance in any tool description. E.g., 'upload' does not state what happens if file exists, storage is full, or path is invalid. LLMs cannot plan recovery without knowing error types and recovery steps.
OAuth2 flow (authorize tool) lacks documentation of the multi-step flow. Description does not explain: why call 'get_code' vs 'get_token', what the user must do in between (approve in browser), or how the state parameter prevents CSRF. This leads to misuse.
Tool 'fileMng' operation 'list' output not documented. Does it return file names, sizes, modification times? Pagination? Are folders included? LLMs cannot build queries without knowing response structure.