Loading ToolBench
Universal MCP server that bridges AI tools to your local development application
Server has 11 tools with complete input schemas and descriptions. Naming follows verb_noun convention (get_, check_, view_, read_, edit_, patch_, list_, delete_, run_). Descriptions are substantive (100-250 chars typical), explaining WHAT and WHEN. However, output schemas are not formally documented, responses are free-text strings rather than structured objects. Error handling is present but generic ('Failed to reach', 'Access denied') without recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Parameter descriptions are good but some lack format constraints (e.g., 'port' accepts any number, no min/max). Security is strong (allowlist-based, path validation, backup before write), but no explicit permission scopes declared.
Check whether a dev server is currently running and responding on a given localhost port. Run this before view_page to confirm the server is up.
Delete a file from the project. A backup is automatically created in .mcp-backups/ before deletion. Cannot delete directories.
Write new content to a file, replacing it entirely. A timestamped backup is automatically created in .mcp-backups/ before any change. Use patch_file instead when making a small targeted change.
Shows which project is currently active — name, root path, package info, file count, and git branch. Use this to visually confirm which project the MCP server is connected to.
Make an HTTP request to an API endpoint on a local dev server and return the full response. Supports all standard HTTP methods and an optional JSON request body. Useful for testing REST APIs, checking response shapes, and verifying status codes.
Get a full overview of the project: package.json metadata, npm scripts, dependencies, detected config files, and a two-level file tree. Always call this first when starting to work on a new project.
Output schemas not documented. All tools return free-text strings instead of structured objects. LLMs cannot parse results reliably or chain downstream tool calls. E.g., get_project_info returns concatenated text; should return {name, version, scripts[], dependencies[], configFiles[], fileTree}.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. delete_file, edit_file, patch_file, run_command are marked WRITE/DESTRUCTIVE in metadata but not in tool schema. LLMs cannot infer safety constraints.
Numeric parameters lack bounds. 'port' accepts any number (should be 1 - 65535). 'timeout_ms' has default 30000 but no min/max. 'depth' in list_files accepts 1 - 5 but not enforced in schema. LLMs can pass invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
List the files and directories in the project as a tree. Use this to understand project structure before reading or editing files.
Replace a specific string or block of code within a file without rewriting the whole file. The old_string must appear exactly once in the file. A backup is created automatically before the change is applied.
Read the contents of a file in the project. Optionally limit output to a range of lines. Use list_files first if you are unsure of the file path.
Run an allowlisted shell command in the project root directory (or a subdirectory via `cwd`, useful for monorepos like frontend/ + backend/). Useful for installing dependencies, running tests, linting, type-checking, and builds. Only commands explicitly listed in ALLOWED_COMMANDS may be executed.
Fetch the HTML content and structure of a page on a running local dev server. Returns the page title, meta tags, script sources, and visible text. Optionally returns the full raw HTML.
Error messages are generic and non-actionable. 'Failed to reach localhost:5173. Is your dev server running?' does not guide recovery. Should return: 'Port 5173 is not responding. Check: (1) dev server is running, (2) port is correct, (3) firewall allows localhost. Try check_port first.'
No confirmation or dry-run for destructive operations. delete_file and run_command can cause data loss or system changes without user confirmation. Should support a 'confirm' parameter or separate 'preview' tool.