mcp-system-control presents a broad toolkit for system operations (16 tools spanning file, command, and system introspection) with serviceable but below-baseline naming and descriptions. Naming is verb-forward (getSystemTime, createFile, deleteDirectory, executeCommand), satisfying pattern:tool conventions. However, descriptions are generic and lack LLM-optimized context. Most tool descriptions are 15 - 40 characters ('Get the current system time', 'Create a new file on the user's system'), falling below the 10 - 1024 baseline and leaving selection ambiguity. Critical gaps: (1) No tool descriptions explain WHEN to use each tool instead of alternatives, dependencies, or prerequisites, LLMs cannot disambiguate between changeMode, changeOwner, and changeTimes. (2) Parameter descriptions are minimal; 'permission' in changeMode is described as 'The permission mode (e.g., 0755, 644)' but omits format validation, octal vs. decimal clarification, or constraints. (3) No documented output schemas; callers cannot plan downstream tool chaining. (4) No error handling guidance; a failed file deletion returns nothing actionable. (5) High-risk tools (deleteFile, deleteDirectory, executeCommand) lack dry-run, confirmation, or audit trail patterns. Per-tool analysis: read-only tools (getSystemTime, getSystemInformation, getEnvironment, readTextFile, getStats) have minimal but present descriptions and simple empty or path-based schemas, these score ~35 - 40. File manipulation tools (createFile, deleteFile, appendFile, etc.) have parameter descriptions but lack safety context, output schemas, or dependency hints, these score ~35 - 50. System-altering tools (changeMode, changeOwner, changeTimes, deleteDirectory, executeCommand) lack risk acknowledgment, confirmation patterns, or audit guidance, these score ~20 - 35. The approval system (seen in server.go) wraps tools post-definition, so security patterns are not reflected in tool descriptions themselves, violating pattern:permission-gate and pattern:audit-trail which expect declarations at definition time.

• Expand all tool descriptions to 50 - 200 characters. Include WHAT the tool does, WHEN to use it, and what it returns. Example: 'changeMode: Modify file or directory permissions. Accepts octal notation (e.g., 0755). Returns success or error. Use before sharing files to restrict access. Does not apply recursively; use separately for each file/directory.'
• Add enums and regex patterns to parameter schemas. For 'permission', define enum: ['0644', '0755', '0777', '0444'] or pattern: '^0[0-7]{3}$'. For 'command', add a pattern to reject shell metacharacters or document which shells are safe.
• Document output schemas for all tools. Example for readTextFile: '{"content": "string", "encoding": "utf-8", "line_count": integer, "truncated": boolean}'. This enables LLMs to parse results and plan chaining.
• Add dry-run or confirmation parameters to deleteFile, deleteDirectory, and executeCommand. Example: 'executeCommand with dry_run=true returns what would execute without running it.' Wrap handlers to require explicit confirmation from the user before executing irreversible operations.
• Declare required permissions in tool metadata. Add a 'scopes' array to tool definitions: 'changeMode': ['write:file'], 'executeCommand': ['execute:system']. This enables least-privilege agent configurations.
• Provide error recovery guidance in tool responses. When a file is not found, return: 'Path /foo/bar not found. Hint: call getStats with the parent directory to verify existence and permissions.' When command execution fails, return the exit code and stderr, not just a generic error.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry