This is a proof-of-concept RCE vulnerability demonstration, not a production MCP server. The single tool 'convert_image' has a minimal description (67 chars, within range but generic), and the input schema is present with three string parameters. However, the tool is explicitly designed to be exploitable, it passes user input directly to ImageMagick without sanitization, enabling command injection. The PoC demonstrates three injection vectors (input, options, output paths). No error handling, no validation, no security gates. The tool description does not warn of the destructive/dangerous nature. This server should never be deployed to production.

• MANDATORY: Implement strict input validation. Use allowlists for file paths (e.g., /tmp/*, /home/user/images/*), reject paths with '..' or shell metacharacters. Validate options against a whitelist of safe ImageMagick flags.
• MANDATORY: Sanitize all parameters before passing to spawn(). Use parameterized execution (pass args array, not shell string) to prevent injection. Never construct shell commands from user input.
• Expand tool description to 100-200 chars explaining: (1) what it does (converts images via ImageMagick), (2) when to use it (when user requests image format conversion), (3) what it returns (path to converted file), (4) prerequisites (input file must exist and be readable).
• Add parameter descriptions: inputPath should state 'Absolute or relative path to an existing image file (e.g., /tmp/photo.jpg). Must be readable by the server process.' Options should list safe flags or link to ImageMagick docs. outputPath should state 'Absolute or relative path where the converted image will be written. Parent directory must exist and be writable.'
• Implement error handling that returns structured errors: 'File not found: /path/to/file' (user-fixable, suggest check_file_exists), 'Invalid ImageMagick option: -invalid-flag' (user-fixable, suggest valid options), 'Permission denied writing to /path' (fatal, suggest alternative path).