Single tool 'execute_command' has a name that is appropriately verb-forward and clear. However, the input schema visible in the code shows only a 'command' parameter with minimal structure. The description provided ('Execute a shell command with security validation and customizable policies') is generic and does not explain WHEN to use this tool, what it returns, what data structures are involved, or how to handle errors. The schema appears to lack comprehensive parameter documentation, type constraints (enums, ranges), and output schema definition. No parameter descriptions are visible in the input schema. The server implements substantial security logic (CommandExecutor, SecurityConfig, validation functions) internally, but this is not reflected in the tool's public interface, the LLM has no visibility into what the tool accepts, what it returns, or how to compose with it. The tool is a high-risk, write-level operation (WRITE risk declared) with no documented error handling guidance, no return schema, and no confirmation/dry-run pattern.

• Add a comprehensive output schema documenting return fields: stdout (string), stderr (string), exit_code (int), success (bool), execution_time_ms (int). Include example output.
• Expand tool description to 150 - 250 chars explaining: what shells/OS it supports, what security policies are enforced, typical use cases, and what to expect on success vs error. E.g.: 'Execute shell commands in the working directory. Only whitelisted commands are allowed. Returns stdout, stderr, and exit code. Common errors: CommandSecurityError if command is not allowed, CommandTimeoutError if execution exceeds limit.'
• Add parameter description for 'command': 'The shell command to execute. Must be a whitelisted command. Supports the following flags: [list flags from SecurityConfig]. Avoid shell operators unless ALLOW_SHELL_OPERATORS is enabled.'
• Implement a dry-run or confirmation step. Add a 'dry_run' boolean parameter (default false) that parses and validates the command without executing it. Or add a separate 'validate_command' tool that checks syntax before execution.
• Document error cases in the description with recovery guidance: 'If CommandSecurityError: the command or flag is not allowed. Check the server logs for allowed_commands and allowed_flags. If CommandTimeoutError: increase COMMAND_TIMEOUT or split into smaller commands. If CommandExecutionError: review stderr for the underlying failure.'
• Add tool annotations: mark with destructiveHint=true since it executes arbitrary commands. Consider idempotentHint=false if command side effects are non-idempotent (e.g., 'rm -rf').