Loading ToolBench
Production-grade MCP server that gives AI agents safe access to your local dev environment: filesystem, databases, processes, and OpenAPI specs.
This MCP server defines 15 tools covering filesystem, database, process, and API operations. However, critical gaps in schema completeness and parameter descriptions severely limit usability. The server's source reveals tools registered with descriptions in src/tools/index.ts, but the actual input schemas are NOT visible in the provided code, only empty `{"type":"object","properties":{}}` objects are shown for 14 of 15 tools. This is a catastrophic scoring issue: per HARD SCORING RULES, tools with no visible input schema must score 0 for schema. Only echo_test has a file reference to its actual definition. The tool descriptions are present (e.g., 'Read a text file inside the configured scope...') but lack parameter-level guidance, constraint documentation, and error recovery hints. The server demonstrates good architecture (tool-registry.ts with type-safe tool definitions via Zod, structured error handling, audit logging) but the public tool contracts are severely underspecified. Most tools cannot be scored above 50 overall because their schemas are invisible and parameters are undocumented.
Invoke an operation defined in an OpenAPI spec.
Return column metadata for a table in a configured database connection.
Return environment variables (process env or .env file) with optional masking.
Return metadata (size, type, MIME, line count, symlink info) for a file or directory.
List directory entries inside the configured scope, with optional recursion and glob filtering.
List running processes, optionally filtered by name or listening port.
Input schemas completely absent from visible source. All 14 tools (except echo_test) show empty schema objects with no properties. This violates the HARD SCORING RULE: 'If a tool has NO input schema at all: its schema score MUST be 0.' Per DIMENSION 1.D (SCHEMAS & OUTPUT), LLMs cannot plan downstream calls or validate inputs without knowing the expected parameters. The actual Zod schemas exist in src/tools/index.ts but are not included in the code excerpt, making them invisible to evaluation.
Parameter-level descriptions missing. Tool descriptions state WHAT the tool does (e.g., 'Read a text file inside the configured scope. Optionally restrict to a line range.') but do not describe individual parameters. Per DIMENSION 1.B and 1.C (DESCRIPTIONS, PARAMETERS), every parameter requires a description explaining what it controls, acceptable values, and format constraints. An LLM calling read_file cannot determine if it expects a file path, glob pattern, or file object handle without parameter documentation.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2025-06-18+ | v2 |
List tables in a configured database connection.
Parse an OpenAPI spec and return a summary of operations.
Execute a parameterized SQL query against a configured database connection. Read-only by default.
Read a text file inside the configured scope. Optionally restrict to a line range.
Read the tail of a configured log file with optional filter.
Spawn a process from the configured allowedCommands list. Captures stdout/stderr with caps and a timeout.
Search for a pattern (literal or regex) across files inside the configured scope.
Write a file atomically inside the configured scope (writes to a temp file then renames).
Output schemas not documented. DIMENSION 1.D (SCHEMAS & OUTPUT) requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' None of the 15 tools have visible output schema documentation. Example: does query_db return rows as an array? Does each row have a 'columns' field? Without this, agents cannot compose queries correctly or extract results.
Missing error recovery guidance. DIMENSION 1.E (ERROR HANDLING) requires 'Error responses must tell the LLM what to do next.' No tools document what errors they can raise, what conditions trigger them, or what recovery steps an agent should attempt. Example: run_command (IRREVERSIBLE risk) provides no guidance on timeouts, permission denied, command not found, or how to retry. This violates the recovery-guide pattern.
Dangerous operations lack confirmation or dry-run support. write_file and run_command are destructive/irreversible but have no dry-run, confirmation, or preview capability. Per DIMENSION 1.E (ERROR HANDLING), 'Irreversible operations (delete, send, publish) should support a dry-run or confirmation step. Agents make mistakes, a confirm_before_execute pattern prevents catastrophic errors.'
No pagination or result limit guidance. Tools like list_directory, search_files, list_processes, and query_db offer no pagination parameters or documented result limits. Per DIMENSION 1.D (SCHEMAS & OUTPUT): 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor. Without pagination, large results blow the context window.' An agent searching a large codebase could receive thousands of matches, exhausting context.
Ambiguous or incomplete tool descriptions. Several tools use generic language that does not specify scope or behavior. Example: 'Search for a pattern (literal or regex) across files inside the configured scope' does not explain whether the pattern parameter expects PCRE, ECMAScript regex, or plain string literals. 'Search for a pattern in files inside the configured scope. Accepts literal strings or POSIX ERE regex. Returns file paths, line numbers, and matching text.' would be stronger.
get_env tool exposes sensitive data. DIMENSION 1.F (SECURITY) states: 'Tool responses must not include tokens, session IDs, or internal secrets. Anything in the response enters the LLM context and could be echoed to the user or logged.' The tool description mentions 'optional masking' but provides no guarantee that secrets (API_KEY, DB_PASSWORD, SLACK_TOKEN) are actually masked by default. Masked secrets should be the default behavior, not optional.
Missing permission declarations. Per DIMENSION 1.F (SECURITY), 'Each tool should declare what permissions it requires (e.g. 'read:email', 'write:calendar').' None of the 15 tools declare required permissions or scopes. This makes it impossible to configure least-privilege agent access. Example: query_db should declare 'database:read' or 'database:write' based on the query type; run_command should declare the specific command allowlist.
No tool annotations (destructiveHint, readOnlyHint, idempotentHint). Per DIMENSION 2 (PROTOCOL READINESS), current MCP spec rewards tool annotations to indicate whether a tool modifies state, is safe to retry, or is read-only. These are absent, forcing LLMs to infer safety from descriptions alone, increasing error risk.