Loading ToolBench
MCP server providing file manipulation and terminal command execution tools
This server has critical gaps in schema definition, parameter documentation, and error handling. Of the 3 tools, only 2 have visible input schemas (read, apply). The exec tool has NO visible input schema in the source, it is inferred from description alone. Read and apply have good descriptions but parameter descriptions are minimal or missing crucial detail. Apply's schema shows an object type for 'position' with nested properties, but lacks descriptions for the nested 'begin' and 'end' fields in the schema itself (they appear only in the struct tags, not in the JSON Schema). Exec tool lacks any input schema definition, only a description. Error handling is minimal across all tools. No output schemas are documented. No tool annotations present. Security concerns exist: exec tool accepts arbitrary shell commands with no validation or allowlist enforcement (despite the codebase supporting --allowed-commands flag, the tool definition doesn't reflect it). These issues collectively place this server in the poor-to-fair range.
Apply changes to a text file. Line numbers are 1-indexed (first line is line 1). Usage examples: - Insert a new line at line 5: content: "new line content", position: {begin: 5, end: 5} - Replace lines 3-7 with new text: content: "new line 1\nnew line 2", position: {begin: 3, end: 7} - Delete lines 10-15: content: null, position: {begin: 10, end: 15}
Run executable
Read a file. Outputs text where every line has prefixed by it's number. Format: "<line_number>:<line_content>\n" Example: 1:first text line 2:second text line
exec tool has NO input schema visible in source code. Only a description 'Run executable' exists. This violates pattern:constrained-input, free-form command strings invite injection attacks and hallucinated values.
exec tool description is vague (only 14 chars: 'Run executable'). Does not explain what happens, when to use it, or that it is IRREVERSIBLE with CRITICAL security implications.
exec tool accepts arbitrary shell commands with no input validation, allowlist enforcement, or sanitization visible in tool schema. The server supports --allowed-commands flag in code (terminal/main.go line 42-49), but this is not reflected in the tool definition. Agents could be tricked via prompt injection into executing arbitrary commands, causing data loss or compromise.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
apply tool 'position' parameter is declared as type object with nested properties (begin, end), but the schema shown does not include descriptions for those nested fields at the JSON Schema level. Parameter descriptions are critical per pattern:tool-description. The ApplyPosition struct in code has jsonschema tags but these are not visible in the tool registration, only 'edit position' is documented for the object itself.
No output schemas are documented for any tool. LLMs cannot know what fields to expect in responses, making it impossible to plan downstream tool chains or extract the right data.
Error handling is minimal. Tools return generic error messages (e.g. 'io: <error>') without actionable recovery guidance. Apply tool returns 'SUCCESS\nLine numbers have been changed!' on success but does not document what failure responses look like or how an LLM should retry.
read tool parameter 'disable_lines' lacks a description. The boolean flag is documented in the struct jsonschema tag but not in a way visible to LLMs consulting the tool definition. A boolean named 'disable_lines' is ambiguous, does it mean 'omit line numbers from output' or 'skip certain lines'?
apply tool does not document the output schema. Success returns 'SUCCESS\nLine numbers have been changed!' as plain text, LLMs cannot reliably parse this. Consider returning a structured object: {"status": "success", "lines_modified": <count>}.