Loading ToolBench
Self-hosted MCP server for Google Drive and Google Sheets
Krakenfy Drive MCP demonstrates solid fundamentals: all 17 tools have clear verb-noun naming (drive_*, sheets_*), complete input schemas with type constraints, and concise descriptions (avg ~80 chars). However, parameter descriptions are entirely absent, the schema shows types and constraints but no explanatory text for what each parameter controls. Output schemas are not documented, forcing LLMs to infer response structure. Error handling is minimal (generic fail() wrapper). No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification in the spec. Composition is strong: tools are single-purpose, chainable (IDs returned match downstream parameter names), and idempotent where appropriate (PATCH for rename/move/trash). Security is well-handled: no secrets in parameters, backoff/retry logic is robust. Naming is excellent (drive_search vs drive_list_folder distinction is clear). Main gaps: missing parameter descriptions, no output schema documentation, no error recovery guidance.
Create a folder at a path, creating intermediate folders as needed.
Create a workspace folder structure with a Google Sheet.
Download a file to a new local path; never overwrite an existing file.
Audit a folder tree recursively, including file metadata and paths.
Get file metadata, owners, and permissions.
List the direct children of a folder; use root for My Drive.
No parameter descriptions. Schema defines types and constraints (e.g., pageSize 1-100) but provides zero explanatory text. LLMs cannot infer what 'parentId' means vs 'folderId' without descriptions. Violates pattern:tool-description requirement that every parameter needs a description explaining what it controls.
Output schemas not documented. Tools return structured responses (files array, nextPageToken, etc.) but LLMs have no schema reference. Violates pattern:tool requirement that output structure be documented so agents can plan downstream calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Move a file or folder to a new parent folder.
Read or export text up to 2 MiB. Binary files must be downloaded.
Rename a file or folder.
Search files and folders accessible in Google Drive.
Share a file or folder with users or groups.
Move a file or folder to trash.
Upload a file from a local path to a folder.
Append rows to the end of a range in a spreadsheet.
Clear data from a range in a spreadsheet.
Read data from one or more ranges in a spreadsheet.
Update data in a range of a spreadsheet.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Server clearly stratifies risk (READ_ONLY, WRITE, DESTRUCTIVE) but does not expose this via MCP tool annotations. LLMs cannot distinguish safe reads from destructive operations without explicit hints.
Error handling lacks recovery guidance. fail() wrapper returns generic {error, code} with no actionable next steps. Pattern:recovery-guide requires errors to tell LLMs what to do: 'User not found. Try search_users() with a partial name.' Current errors give agents nothing to act on.
No confirmation step for destructive operations. drive_trash_file and sheets_clear are irreversible but lack dry-run or confirmation. Pattern:confirmation-request recommends agents should confirm before executing destructive actions to prevent catastrophic errors.