An MCP server that provides command execution and filesystem access capabilities with process management, output streaming, and web management interface
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server implements 13 tools across filesystem and command execution domains. While all tools have names, descriptions, and schemas, the descriptions are written in Chinese and are extremely terse (typically 6-12 characters), falling well below the production baseline of 194 characters. Schemas are present but lack depth, many parameters are missing descriptions entirely or have minimal ones. Parameter type definitions exist but constraints (enums, ranges, formats) are absent. No output schemas are documented. Error handling is not visible in the tool definitions. The server uses STDIO transport, which is a hard cap of 50 for protocol readiness. Overall, this is a mediocre implementation that would require significant work to meet production standards.
All tool descriptions are under 20 characters and written in Chinese. Production baseline is 194 characters. Descriptions must explain WHAT the tool does, WHEN to use it, and any prerequisites in English to serve English-speaking LLMs. Example: 'Read a text file from the filesystem. Returns file contents as a string. Use this to retrieve configuration files, source code, or logs. Specify encoding if non-UTF-8.'
Parameter descriptions are missing or minimal. For example, 'edits' in fs_edit_text_file lists 'each operation includes oldText and newText' but does not explain the schema of each edit object, whether regex is supported, or behavior on overlap. Production tools describe every parameter field with type, constraints, and examples.
Recommendations
Rewrite all tool descriptions in English, expand to 100-200 characters, and follow the pattern: WHAT it does, WHEN to use it, WHAT it returns, and any prerequisites. Example: 'Read a text file from the filesystem and return its contents. Use this to retrieve configuration files, logs, or source code. Supports custom encoding (default: UTF-8). Returns {content: string, size_bytes: integer, encoding: string}.'
Add descriptions to all parameters currently lacking them. Use precise language: 'The path to the file to read. Absolute paths are searched directly; relative paths are resolved against the working directory. Supports ~ expansion.' Not 'The file path.'
Document output schemas for all 13 tools. Create a structured response object for each and include it in the tool description. Example for fs_read_text_file: 'Returns {"content": string (file contents), "encoding": string (detected or specified), "size_bytes": integer, "path": string (resolved absolute path)}'.
Add validation constraints to parameters: (1) 'encoding' should be an enum: [UTF-8, ASCII, UTF-16, ISO-8859-1] or a pattern constraint. (2) 'timeout' should have bounds: 1-3600 seconds. (3) 'max_bytes' for images: 1-104857600 (100MB). (4) 'tail' for process output: 1-10000 lines. (5) 'grep_mode' should be an enum: [line, content].
Add dry-run or confirmation mechanisms to all destructive operations. For fs_write_text_file and fs_edit_text_file, add a 'confirm' boolean parameter that returns a diff/preview without committing. For cmd_stop_process and cmd_clean_process, require explicit 'confirmed: true' with a reason string logged for audit.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No output schemas are documented. LLMs cannot plan downstream tool calls or extract data if they don't know what fields to expect. For each tool, document the return structure: field names, types, and meanings. Example: 'Returns {"content": string, "encoding": string, "size_bytes": integer}'.
No constraints on parameters. Examples: 'encoding' accepts any string without validation; 'timeout' has no min/max; 'max_bytes' for images has no bounds; 'args' array for cmd_start_process has no item type or count limits. Add constraints to prevent invalid inputs and guide LLM reasoning.
Destructive operations (fs_write_text_file, fs_edit_text_file, cmd_stop_process, cmd_clean_process) lack dry-run or confirmation mechanisms. fs_edit_text_file has a 'dry_run' parameter, but write and stop operations do not. An agent mistake could delete or corrupt files irreversibly. Add confirmation patterns or dry-run support across all write/delete tools.
No error handling guidance visible. Tool descriptions do not explain what errors can occur, when they are retryable, or what the LLM should do next. For example, if fs_read_text_file fails with 'File not found', should the LLM try a different path, ask the user, or retry?
No security documentation. These tools operate on the filesystem and execute arbitrary commands, high-risk operations. No mention of: permission checks, which paths are accessible, whether command injection is prevented, what user/agent permissions are required. Add security scoping: 'Accessible paths: /tmp, /home/{user}/projects. Blocked: /etc, /sys. Requires fs:read scope.'
Tools that return lists (fs_read_multiple_text_files, fs_read_multiple_images, cmd_list_processes) lack pagination parameters and result count limits. If a directory contains 10,000 files or a system has 5,000 processes, returning all results will blow the context window. Add limit, offset, and return a 'total_count' field.
Encoding parameter in file tools defaults to nothing and is optional, but the description mentions '如果路径是相对路径，则是相对 roots 的相对路径' (relative to roots), yet 'roots' is not a tool parameter. This references a deprecated MCP pattern (Roots) that was removed. File tools should accept a base_path or current_working_directory parameter instead, or document how paths are resolved.
cmd_get_process_output has a 'grep' parameter that accepts regex, but the description is minimal and does not explain regex syntax, whether it is PCRE/POSIX, or what happens if the regex is invalid. Complex parameters need detailed guidance.
cmd_get_process_output
Document error responses and recovery guidance. Add a 'Errors' section to each tool description. Example: 'Returns 404 if file not found, suggest checking the path or listing the directory. Returns 403 if access denied, user may need elevated permissions. Returns 413 if file exceeds max_bytes, suggest splitting or sampling the file.'
Add security and permission scoping to tool descriptions. Specify: accessible path ranges (/tmp, /home, /workspace), blocked paths (/etc, /sys, /root), required scopes (fs:read, fs:write, cmd:exec), and whether the agent runs as a specific user with restrictions.
Implement pagination for multi-result tools. fs_read_multiple_text_files and fs_read_multiple_images should accept 'limit' (default 20, max 100) and 'offset' (default 0), return 'total_count', and include pagination metadata. cmd_list_processes should accept 'limit' (default 50, max 1000) and 'offset'.
Remove or replace references to the deprecated 'roots' pattern. Instead: (1) Add a 'base_path' or 'cwd' parameter to file tools, or (2) Document that relative paths are resolved against the current working directory (specify what it is), or (3) Accept only absolute paths and require the agent to construct full paths.
Add detailed parameter guidance for complex inputs like 'edits' (fs_edit_text_file) and 'grep' (cmd_get_process_output). Specify: regex dialect (PCRE/POSIX), whether oldText uses regex or literal strings, overlap behavior, maximum operation count per call.
Add examples to descriptions (NOT as parameter values, but as illustrative context). Example: 'fs_write_text_file: Write config.yaml to /tmp/. Tool returns {path: string, size_bytes: integer, overwritten: boolean}.'
Implement logging and audit trails. Every tool call should log: who (user/agent ID), what (tool name + parameters), when (timestamp), result (success/failure + data volume). Critical for security review when agents modify files or execute commands.
Consider adding tool annotations (currently missing): Mark fs_read_* as readOnlyHint=true; mark fs_write_*, cmd_stop_*, cmd_clean_* as destructiveHint=true. Mark idempotent tools (cmd_get_process_info, cmd_list_processes) as idempotentHint=true for safety.
Decouple filesystem and command tools conceptually. Consider if agents should have both at once, or if command execution should require additional permission tokens. Document the risk model.