Loading ToolBench
Secure local API for Claude mobile app to access code files with approval gating. Exposes local file operations as MCP tools with explicit user approval required for all file access.
Claude Local Bridge exposes 6 file/approval management tools with explicit FastMCP registration, clear naming conventions, and detailed descriptions. Tools follow verb_noun patterns (browse_files, request_file_access, read_file, write_file, list_approvals, revoke_approval). Descriptions are consistently detailed (100-250 chars each), explaining WHAT each tool does, WHEN to use it, and dependencies. Input schemas are present with typed parameters and descriptions. However, output schemas are NOT documented in the source code, tool return types are inferred as strings from the function signatures, but no structured output format is specified. Error handling includes descriptive recovery guidance ('Use request_file_access first'). Security approach is noteworthy: approval gating, audit logging, and path validation are implemented. Main gaps: no output schema documentation, no parameter constraints (enums), minimal per-parameter validation hints, and no batch operations despite common patterns that would benefit from them.
Browse the workspace file tree. Returns a directory listing showing files and folders in the connected workspace. No approval is needed to browse — this only shows names and structure, not file contents.
List all current approvals. Shows which files/directories are approved, pending, or denied.
Read the contents of a file. Requires an active READ approval. If you don't have one, use request_file_access first.
Request approval to access a file or directory. The workspace owner must approve before you can read or write. This call BLOCKS until the owner approves, denies, or it times out (5 min).
Revoke an existing approval. After revoking, you'll need to request access again.
Write content to a file. Requires an active WRITE or READ_WRITE approval. If you don't have one, use request_file_access first.
Output schemas are not documented. Tools return free-form strings (e.g., `_format_tree(nodes)`, formatted headers). LLMs cannot parse unstructured output reliably, forcing them to extract data via string parsing rather than structured field access.
Parameter constraints are missing. 'scope' parameter in request_file_access accepts 'file', 'directory', 'directory_shallow' but is defined as a bare string, not an enum. Similarly, 'access' and 'reason' lack explicit constraints. LLMs may hallucinate invalid values.
Numeric parameter bounds are not specified. 'depth' in browse_files is clamped to 1-10 via code (max(1, min(10, depth))), but the parameter description does not state this range. 'ttl_minutes' in request_file_access lacks range documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 76 | <=2025-11-25 | v2 |
Error handling is descriptive but not categorized. Errors guide recovery ('Use request_file_access first') but do not classify failures as retryable vs. user-fixable vs. fatal. LLMs lack explicit retry semantics.
No dry-run or confirmation pattern for destructive operations. write_file and revoke_approval modify state but lack a confirm_before_execute or dry_run parameter. Agents cannot preview the outcome before committing.