Loading ToolBench
An MCP server to upload files to a Zipline-compatible host.
The server defines 9 tools with explicit schemas and descriptions. Naming follows verb_noun convention (upload_file, validate_file, list_user_files, etc.), which is good. Descriptions are present and reasonably detailed (avg ~150-200 chars), exceeding the 10-char minimum. However, several tools have schema gaps: tmp_file_manager and remote_folder_manager accept free-form command strings instead of structured enums, forcing LLMs to construct command syntax at runtime. Parameter descriptions are generally good but some lack constraint information (e.g., 'folder' in upload_file doesn't explain valid format for folder IDs). Output schemas are not documented, the code shows Zod validation but response structures are inferred from API responses rather than explicitly declared. Error handling is present (McpErrorCode, mapHttpStatusToMcpError) but recovery guidance is limited. Security is well-handled: ZIPLINE_TOKEN injected server-side, no secrets in parameters. Composition is sound, tools are single-responsibility. Overall: competent implementation with room for formalization in schema documentation and command parameter structure.
Delete a file from Zipline by its ID.
Download a file from an HTTP or HTTPS URL into the user sandbox.
Retrieve detailed information about a specific file by ID.
List user's files on Zipline with pagination, filtering, sorting, and search capabilities.
Manage folders on Zipline. Supported commands: LIST, ADD, EDIT, GET, DELETE.
Manage temporary files in the user sandbox. Supported commands: PATH, LIST, CREATE, OPEN, READ, DELETE.
tmp_file_manager and remote_folder_manager accept free-form command strings instead of structured enums. LLMs must construct command syntax ('CREATE <filename>', 'LIST', 'ADD <name>', 'EDIT <id> <key> <value>', etc.) from natural language, inviting malformed syntax and requiring trial-and-error.
Output schemas are not documented. Tools return responses via Zod validation and HTTP calls, but the response structure (fields, types, nesting) is not explicitly declared for LLM planning. This forces LLMs to infer response shapes from experience or make assumptions about chaining.
tmp_file_manager combines multiple concerns (PATH, LIST, CREATE, OPEN, READ, DELETE) into one tool. These should be split into separate tools (list_tmp_files, create_tmp_file, read_tmp_file, delete_tmp_file) so agents can compose them independently and each has a single responsibility.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Update file metadata including favorite status, view limits, password, tags, name, and folder location.
Upload a file to Zipline with optional expiration, password protection, view limits, and folder placement.
Validate a file for secrets and sensitive data before upload.
'folder' parameter in upload_file and 'folderId' in update_user_file lack constraint documentation. Description says 'alphanumeric, hyphens, underscores allowed' but does not state minimum/maximum length, required format pattern, or how to discover valid folder IDs.
Error handling provides McpErrorCode mapping but does not include recovery guidance in error responses. When a tool fails, the LLM gets an error code but no suggestion for next steps (e.g., 'File not found. Try list_user_files() to discover available files.').