Loading ToolBench
Multi-protocol bridge server enabling seamless integration between Claude AI and external applications through Agent Client Protocol and Model Context Protocol
This server exposes 21 tools across 8 handlers (file, search, execution, notebook, terminal, web, planning, generic). While tool names follow verb_noun conventions and most have non-empty descriptions, critical gaps emerge: (1) output schemas are entirely undocumented, no return type specifications visible for any tool, (2) parameter descriptions are present but often generic and lack constraint details (format, range, enum values), (3) error handling lacks actionable recovery guidance, (4) several tools combine multiple concerns (e.g., terminal_create handles command execution, timeout, background, cwd, env, should be split), (5) security-sensitive operations (write, terminal execution) lack explicit permission checks in the schema, (6) descriptions vary widely in quality, some are detailed (read_file, edit_file), others are cryptic ('Task', 'Request permissions'). The server bridges ACP and MCP protocols, introducing complexity that muddies tool semantics. Per-tool scores reflect this: file tools (read_file, edit_file) are solid (65-75); terminal tools are dangerous with weak guidance (35-45); web tools lack constraint documentation (50-60); planning/generic tools are vague (40-50).
Edit file content with text replacement (ACP protocol tool name)
Exit plan mode and finalize planning
Search for files matching a glob pattern
Search file contents with regex or text pattern
List directory contents
Perform multiple edits on a single file (ACP protocol tool name)
Edit Jupyter Notebook content
Read Jupyter Notebook content
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields.
Terminal tools (terminal_create, terminal_output, terminal_kill) lack irreversibility warnings and permission gates. Agents can execute arbitrary commands without confirmation or audit.
Duplicate/overlapping tool definitions: Read/Edit/Write/MultiEdit are ACP protocol aliases for read_file/edit_file/multi_edit. This creates tool name confusion and wastes reasoning cycles.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Read file content (ACP protocol tool name)
Delegate a task to agents
Update TODO items and planning state
Fetch and parse web content from a URL
Search the web using a search engine
Write file content (ACP protocol tool name)
Edit or write files with precise text replacement. CRITICAL: - Prefer this tool over other edit and write tools USAGE: - EDITING: Provide oldText (exact match required) and newText - WRITING: Provide content only for full file write REQUIREMENTS: - filePath must be absolute path with extension (not directory) - oldText must exactly match existing content including whitespace/indentation - oldText must be actual file content, not pseudocode or outline - Use minimal context: unique lines need no context, non-unique lines need surrounding context - Do not escape quotes, newlines, or special characters
Perform multiple edits on a single file with precise text replacement.
Reads file content from the project. CRITICAL: - Prefer this tool over other read tools for up-to-date files content REQUIREMENTS: - filePath must be an absolute path with extension (not directory) - offset and limit parameters must be provided for line-based reading
Request permission from the user to execute a tool.
Create a new terminal process with the given command.
Terminate a terminal process.
Get output from a terminal process.
Parameter descriptions lack constraints: format, range, enum values, length limits. E.g., 'pattern' in Grep has no guidance on regex syntax or limits. Terminal timeout has no minimum/maximum.
Error handling lacks actionable recovery. Terminal tools, file tools, and web tools do not describe what the LLM should do on failure (retry, ask user, proceed with partial results).
Tool composition issues: terminal_create combines command execution, timeout, background mode, cwd, and env into one tool. Should split into terminal_create (command only) and terminal_configure (cwd, env). Also, no idempotence guarantees.
Vague descriptions: 'Task' has description 'Delegate a task to agents' (24 chars). 'Request permissions' is under-specified (no guidance on when/why to call it). 'LS' lists 'Directory contents' (22 chars) without context.
Security: edit_file, multi_edit, NotebookEdit, TodoWrite, terminal_create are destructive/sensitive but lack explicit permission checks or audit trail declarations in their schemas.
Missing pagination support: Grep, WebSearch, and LS can return large result sets. No limit, offset, or cursor parameters documented to prevent context window exhaustion.
Parameter name consistency: WebSearch uses 'allowedDomains' and 'blockedDomains' (camelCase), but most other tools use snake_case. Inconsistency forces LLM to reason about parameter naming.