Loading ToolBench
Local-first Shelby MCP server with a production-minded layered architecture for managing blobs, accounts, and sandbox operations.
Shelby MCP demonstrates solid foundational quality with consistent naming patterns (verb_noun), comprehensive parameter schemas using Zod, and structured output envelopes. All 18 tools have descriptions and input schemas. However, descriptions are terse (avg ~80 chars, below the 194-char baseline), parameter descriptions lack actionable constraints (e.g., no format hints for 'path' or 'targetName'), and error handling lacks recovery guidance. Tool composition is clean (single responsibility), but output schemas are not explicitly documented in the source, and several tools accept ambiguous identifiers (id vs key for blobs) without clear guidance on when to use each.
Return active provider information, configured account context, and current capability status.
Upload multiple local files to Shelby in one operation.
Return machine-readable provider capability flags for the active Shelby provider.
Delete a Shelby blob when destructive tools are enabled.
Download a Shelby blob to a local output path or the configured temp directory.
Fetch metadata for a Shelby blob by id or key.
Parameter descriptions lack actionable constraints. 'path' and 'targetName' parameters have minimal guidance on format, length, or character restrictions. LLMs cannot infer constraints from names alone.
Ambiguous blob identifier pattern: tools accept both 'id' and 'key' parameters as mutually exclusive alternatives, but descriptions do not clarify when to use each or how they differ. This forces LLMs to guess.
Tool descriptions are terse (avg ~80 chars vs 194-char baseline). Descriptions lack context on WHEN to use each tool and dependencies between tools (e.g., 'Call shelby_list_blobs first to discover blob keys').
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2025-06-18+ | v2 |
Return a provider URL for retrieving a blob when the provider supports it.
Show the current Shelby sandbox root and active narrowed safe path.
Return the active Shelby upload policy, including strict metadata requirements and streaming support.
Perform a lightweight healthcheck and return safe configuration and provider readiness details.
List blobs for the current Shelby account or provider context.
Inspect a local directory and list candidate files before a Shelby batch upload.
Read a Shelby blob as text when the content type is text-safe.
Narrow the active safe working scope to a subdirectory inside the current Shelby sandbox.
Upload a local filesystem file into Shelby storage using streaming reads where supported.
Upload inline text content as a Shelby blob.
Verify remote blob integrity and optionally compare it with a local file checksum.
Serialize JSON content and upload it as a Shelby blob.
Error handling in tool registry (tool-registry.ts) logs errors but does not return actionable recovery guidance to the LLM. Error responses should suggest next steps (e.g., 'Try shelby_list_blobs() to find valid blob keys').
Output schemas are not explicitly documented in the source code. While Zod schemas exist (e.g., healthcheckResultSchema), the actual field structure and types are not visible in the provided code, making it impossible to verify completeness.