Loading ToolBench
Reusable utilities for MCP servers handling binary blob transfers through shared Docker volumes
6 tools with consistent structure and reasonable descriptions. All tools have explicit schemas with typed parameters and descriptions. Naming follows verb_noun convention (upload_blob, get_blob_*, list_blobs, delete_blob). However, descriptions are generic and lack LLM-optimization detail, most are 50-150 chars when best practice is 50-200 chars with clear action/context. Parameter descriptions are present but minimal (10-40 chars typically). No enum constraints despite opportunities (e.g., mime_type filtering could enumerate common types). Output schemas not documented, LLMs don't know what fields to expect in responses. Error handling absent; no guidance on how LLMs should recover from failures. Schemas are well-formed JSON with proper types, but lack depth (missing examples, bounds, format hints). No security annotations (permissions, scope declarations). The tool suite is focused and single-purpose (good composition), but lacks the polish and LLM-specific optimizations expected of production-grade tools.
Delete a blob and its metadata.
Retrieve blob content as base64-encoded data. Note: This is implemented as a tool instead of an MCP resource endpoint. Template resources (blob://{blob_id}) are not well-supported by some MCP clients and can cause compatibility issues. The tool-based approach provides better compatibility across all MCP clients.
Get the filesystem path for a blob (for local server access). This is useful when multiple MCP servers share the same Docker volume and need to access blobs directly from the filesystem.
Retrieve metadata for a blob without downloading its content.
List blobs with optional filtering and pagination.
Upload a binary blob and receive a resource identifier.
No output schemas documented. LLMs cannot predict response structure, forcing them to reason about downstream tool compatibility without information. For example, does list_blobs return an array of {blob_id, filename, created_at, tags}? Or a paginated object with {items, total, next_cursor}?
Descriptions lack LLM-optimization. Most descriptions (40-100 chars) are too brief to guide tool selection. Missing context on WHEN to use each tool vs. alternatives. E.g., get_blob_content vs. get_blob_file_path, when does an LLM choose one over the other? Current descriptions don't explain the trade-off (base64 transfer vs. filesystem path).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Parameter descriptions are minimal and lack constraint details. Example: 'mime_type' parameter in list_blobs has description 'Filter by MIME type (supports wildcards like "image/*")', but the example value might be treated literally by LLMs. Should formalize as: 'Filter by MIME type. Supports wildcards (e.g., image/*, text/*). Leave empty to skip filtering.' Also missing: what happens if an invalid MIME type is passed?
No error handling guidance. delete_blob (destructive operation) has no mention of recovery strategy if the blob doesn't exist or permission is denied. No recovery suggestions (e.g., 'Call list_blobs first to confirm the blob exists'). Agents have no way to self-correct on failure.
Destructive tool (delete_blob) lacks confirmation/dry-run pattern. No mechanism to prevent accidental deletion. Agents make mistakes, a dry_run parameter or explicit confirmation step would reduce risk.
Parameter naming inconsistency. Some tools use blob_id (with format hints in description), others could benefit from clearer type suffixes. E.g., upload_blob has 'filename' (human-friendly string) vs. get_blob_metadata expects 'blob_id', but get_blob_content also expects 'blob_id'. Format of blob_id not specified (is it always 'blob://...' or can it be a raw hash?).
No pagination metadata returned from list_blobs. Response should include 'total' count and 'next_cursor' or indicate whether more results exist. Without this, agents cannot reliably iterate through large blob collections.
No enumeration of valid MIME types or tag formats. upload_blob accepts tags as an array but no schema specifies what constitutes a valid tag (length, allowed characters, reserved names). LLMs will guess and may pass invalid tags.