Loading ToolBench
MCP server for markdown editing and management with file system operations, terminal command execution, and process management
This server has 19 tools with significant quality gaps. Most tools have descriptions (good), but many descriptions are verbose and lack actionable guidance for LLM selection. Parameter schemas are present but inconsistently detailed, many lack type constraints, enums, or range limits. Critical security issues: set_config_value allows full filesystem access via empty allowedDirectories array, and no evidence of permission gates or audit logging. Error handling is minimal; no recovery guidance. Tool composition is reasonable (single responsibilities), but output schemas are not documented. The server conflates markdown editing with a full desktop commander (file ops, process management, shell execution), which is scope creep.
Create a new directory at the specified path. Creates parent directories as needed.
Edit a specific block of text in a file by finding and replacing content.
Force terminate a running process.
Get the complete server configuration as JSON. Config includes fields for: - blockedCommands (array of blocked shell commands) - defaultShell (shell to use for commands) - allowedDirectories (paths the server can access) - fileReadLineLimit (max lines for read_file, default 1000) - fileWriteLineLimit (max lines per write_file call, default 50) - telemetryEnabled (boolean for telemetry opt-in/out) - version (version of the DesktopCommander) - systemInfo (operating system and environment details)
Get information about a file or directory.
set_config_value allows full filesystem access when allowedDirectories is set to empty array ([]). This is a critical security vulnerability that bypasses access controls. No permission gates or validation prevent an agent from disabling all restrictions.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. For example, read_file should document return type (text content, line count, encoding), and start_process should document sessionId format for use with read_process_output.
Destructive/irreversible tools (force_terminate, kill_process, write_file with mode='rewrite') lack confirmation or dry-run support. Agents can accidentally terminate critical processes or overwrite files without recovery options.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Send input to a running process.
Kill a process by PID.
List the contents of a directory.
List all running processes.
List all active process sessions.
Move or rename a file or directory.
Read the contents of a file from the file system or a URL with optional offset and length parameters. Prefer this over 'execute_command' with cat/type for viewing files. Supports partial file reading with: - 'offset' (start line, default: 0) * Positive: Start from line N (0-based indexing) * Negative: Read last N lines from end (tail behavior) - 'length' (max lines to read, default: configurable via 'fileReadLineLimit' setting, initially 1000) * Used with positive offsets for range reading * Ignored when offset is negative (reads all requested tail lines) Examples: - offset: 0, length: 10 → First 10 lines - offset: 100, length: 5 → Lines 100-104 - offset: -20 → Last 20 lines - offset: -5, length: 10 → Last 5 lines (length ignored) Performance optimizations: - Large files with negative offsets use reverse reading for efficiency - Large files with deep positive offsets use byte estimation - Small files use fast readline streaming When reading from the file system, only works within allowed directories. Can fetch content from URLs when isUrl parameter is set to true (URLs are always read in full regardless of offset/length). Handles text files normally and image files are returned as viewable images. Recognized image types: PNG, JPEG, GIF, WebP.
Read the contents of multiple files simultaneously. Each file's content is returned with its path as a reference. Handles text files normally and renders images as viewable content. Recognized image types: PNG, JPEG, GIF, WebP. Failed reads for individual files won't stop the entire operation. Only works within allowed directories.
Read output from a running process.
Search for code patterns using ripgrep with regex support.
Search for files matching a pattern in a directory.
Set a specific configuration value by key. WARNING: Should be used in a separate chat from file operations and command execution to prevent security issues. Config keys include: - blockedCommands (array) - defaultShell (string) - allowedDirectories (array of paths) - fileReadLineLimit (number, max lines for read_file) - fileWriteLineLimit (number, max lines per write_file call) - telemetryEnabled (boolean) IMPORTANT: Setting allowedDirectories to an empty array ([]) allows full access to the entire file system, regardless of the operating system.
Start a new process or shell command.
Write or append to file contents. CHUNKING IS STANDARD PRACTICE: Always write files in chunks of 25-30 lines maximum. This is the normal, recommended way to write files - not an emergency measure. STANDARD PROCESS FOR ANY FILE: 1. FIRST → write_file(filePath, firstChunk, {mode: 'rewrite'}) [≤30 lines] 2. THEN → write_file(filePath, secondChunk, {mode: 'append'}) [≤30 lines] 3. CONTINUE → write_file(filePath, nextChunk, {mode: 'append'}) [≤30 lines] ALWAYS CHUNK PROACTIVELY - don't wait for performance warnings! WHEN TO CHUNK (always be proactive): 1. Any file expected to be longer than 25-30 lines 2. When writing multiple files in sequence 3. When creating documentation, code files, or configuration files HANDLING CONTINUATION ("Continue" prompts): If user asks to "Continue" after an incomplete operation: 1. Read the file to see what was successfully written 2. Continue writing ONLY the remaining content using {mode: 'append'} 3. Keep chunks to 25-30 lines each Files over 50 lines will generate performance notes but are still written successfully. Only works within allowed directories.
Parameter descriptions are often minimal (under 50 chars) and lack actionable constraints. For example, start_process 'command' param has no guidance on allowed commands, shell injection risks, or blocked command list. search_files 'pattern' lacks glob syntax documentation.
No error handling guidance. Tools return errors but do not tell LLMs what to do next (retry, ask user, abort). For example, if read_file fails due to permission denied, should the agent try a different path, request elevated privileges, or fail the task?