Single tool 'rector_process' has a clear verb-noun name and solid description (89 chars). Input schema is present with two parameters (path, dryRun), both typed and described. However, output schema is only documented in the PHP docblock return type annotation, not in the MCP tool registration itself, LLMs cannot see this. The tool performs a destructive operation (file rewrites) but lacks explicit dry-run/confirmation guidance in the description. Security containment is well-implemented (path validation, working-dir pinning) but not surfaced in the tool description for the LLM. Error handling returns structured objects with error_class and trace fields, which is good, but lacks actionable recovery guidance (e.g., 'If warm_boot=true and error occurs, the container may be corrupted, retry with a fresh server instance').

• Add explicit output schema documentation to the MCP tool registration (via McpTool attribute or SDK equivalent). Include all fields: exit_code (int), output (string), warm_boot (bool), error (string, optional), error_class (string, optional), trace (string, optional).
• Enhance tool description to emphasize destructive behavior: 'Run Rector refactoring on a path. When dryRun=false, modifies PHP files on disk, use dryRun=true to preview changes first. Config and working directory are pinned at server startup.'
• Add recovery guidance to error responses. When warm_boot=true and an error occurs, include: 'The warm container may be corrupted (e.g., PHPStan scope cache mismatch). The server will automatically retry once. If the error persists, restart the server.'
• Clarify path containment in parameter description: 'Absolute path to file or directory. Must be within the server's working directory (set at startup via --working-dir flag). Paths outside this boundary are rejected for security.'
• Add tool annotation hints to the McpTool attribute: destructiveHint=true when dryRun=false, idempotentHint=true for dry-run mode, to signal to clients the nature of the operation.