Loading ToolBench
MCP server for Google Cloud Storage operations including bucket management, file operations, and folder operations
The server defines 16 GCS storage tools with consistent naming (verb-first: list_, create_, delete_, get_, upload_, download_, copy_, move_, rename_, read_). All tools have descriptions and input schemas with property definitions. However, there are significant gaps: (1) No output schemas documented anywhere, tools declare what they do but not what fields/structure they return, forcing LLMs to guess. (2) Parameter descriptions are present but often generic and lack format/constraint details (e.g., 'Name of the bucket' lacks validation rules, regex patterns, length limits). (3) No error handling guidance, a tool that 'deletes all files' under a folder has no recovery path or confirmation mechanism. (4) No pagination support on list operations despite the pattern baseline requiring it. (5) Sensitive operations (delete_bucket with force=true, delete_folder, delete_file) lack confirmation or dry-run patterns. (6) Tool descriptions are terse (avg ~80 chars) and lack dependency hints or WHEN-to-use guidance. Overall solid foundation but falls short of production-grade completeness.
Copy a file within the same bucket or to a different bucket
Create a new GCS bucket in the project
Delete a GCS bucket. Use force=true to delete even if it has files.
Delete a specific file from a GCS bucket
Delete all files under a folder prefix in a GCS bucket
Download a file from GCS to local machine
No output schemas documented. All 16 tools lack return type definitions, LLMs cannot predict what fields to expect, forcing them to reason about response structure. E.g., list_files returns what? Array of file objects? Fields: name, size, updated_at? No way to know.
No pagination support on list tools. list_buckets, list_files, list_folders, get_bucket_metadata accept no limit/offset/page_size parameters. If a project has 1000 buckets or 10,000 files, these tools will either timeout or return incomplete results with no way for the agent to fetch more.
Destructive operations lack confirmation or dry-run. delete_bucket (force=true), delete_file, delete_folder are irreversible. No support for confirm_before_execute or dry-run mode. An LLM mistake deletes data with no recovery path.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get metadata of a GCS bucket — location, storage class, creation date
Get metadata of a file — size, content type, MD5, created date, updated date
List all GCS buckets in the GCP project
List all files in a GCS bucket with optional folder prefix filter
List all folders (prefixes) inside a GCS bucket
Move a file from one location to another — within same bucket or across buckets
Read content of a small text file directly from GCS without downloading
Rename a file inside the same bucket
Upload a local file to a GCS bucket
Upload an entire local folder recursively to a GCS bucket
Parameter descriptions lack format/constraint details. E.g., 'bucket_name' is just 'Name of the bucket to create', no mention of: required length (3-63 chars per GCS rules), allowed characters (lowercase, digits, hyphens only), or validation regex. LLMs will pass invalid bucket names.
No error handling guidance. Tools have no documented error cases or recovery paths. E.g., upload_file could fail due to: file not found, insufficient permissions, bucket does not exist, quota exceeded. No guidance on retryability, user-fixable errors, or next steps.
Tool descriptions are terse and lack WHEN-to-use context. Avg description length ~80 chars, baseline is 194. E.g., 'List all GCS buckets in the GCP project' is factual but doesn't explain: Should I call this first? When? What's the next step? Lacks dependency hints and agent reasoning support.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are registered with bare Tool objects, no risk metadata. Agents cannot reason about side effects, delete_file looks identical to get_file_metadata.
Source code contains hardcoded credentials and project ID. KEY_PATH and PROJECT_ID are baked into the server, not injected via environment or vault. Credentials are committed to the repo (visible in the code sample). This is a production security failure.
Destination paths and local paths are user-supplied without sanitization. upload_file accepts local_path and destination; download_file accepts local_path; no validation against path traversal (../, absolute paths, symlinks). An LLM could be tricked into uploading from /etc/passwd or downloading to /tmp or home.