Loading ToolBench
Use your Claude Code MAX/PRO subscription from any MCP client. Exposes Claude CLI over HTTP+SSE.
Claude Bridge MCP has clear, action-verb tool names and reasonable descriptions, but suffers from incomplete parameter documentation and missing output schemas. All four tools are explicitly defined in src/tools.ts with inputSchema objects. Descriptions are present and 80-150 characters (within baseline range). However, parameter descriptions are sparse or missing details about constraints and formats. No output schema documentation exists, LLMs cannot determine what fields to expect from responses. Error handling returns plain text error messages rather than structured guidance. Security concerns exist around path validation and command execution with user input.
Execute a task using Claude Code on the remote PC. Spawns Claude CLI with full coding capabilities (read/write files, run commands, git ops). Returns structured JSON output.
Get git status of a repository on the PC. Returns branch, staged/unstaged changes, and recent commits.
Ask Claude Code a question without making changes. Read-only, fast. Good for code analysis, explanations, or quick lookups.
Read a file from the PC filesystem. Returns the file contents as text.
No output schema documentation. LLMs cannot determine what fields responses contain. All tools return {'content': [{'type': 'text', 'text': string}]} but downstream agents cannot rely on structured output fields or compose results into subsequent tool calls.
Parameter 'workingDirectory' lacks constraints and validation guidance. Description says 'must be in allowed list' but does not explain what the allowed list contains or how to discover valid directories. LLMs cannot reason about which directories are safe.
Parameter 'timeout' for claude_execute lacks minimum/maximum bounds or units clarity. Default is stated (120000) but no constraints prevent LLMs from passing absurd values (e.g., timeout: 999999999). No documentation of timeout behavior or retry guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Error responses are plain text strings, not structured. Code at src/tools.ts line handleTool() returns Error: <message> as a text response. LLMs cannot parse error classification (retryable vs user-fixable vs fatal) or extract actionable recovery guidance.
Parameter 'encoding' for claude_read_file has no validation. LLMs can pass invalid encodings (e.g., 'utf-999'). No error guidance on what encodings are supported or how to self-correct.
Path validation uses isPathAllowed() and isRealPathAllowed() but error message is generic: 'Path not allowed'. LLMs receive no context about why a path was rejected or what paths would be valid. No enrichment with available directories.
Tool 'claude_execute' spawns Claude CLI with full shell access (read/write files, run commands). No dry-run or confirmation pattern. Destructive operations (delete files, run rm -rf) execute immediately without agent confirmation or rollback option.
execSync() calls for git operations lack stderr capture and detailed error context. If 'git status' fails (e.g., not a repo, permission denied), the exception bubbles as a generic error. No actionable message for the LLM.