Single tool 'reviewEdit' has a clear verb-noun name and comprehensive description (195 chars, within baseline 34-392 range). Input schema is present with Zod validation and all three parameters have descriptions. However, output schema is not documented, the tool returns text content but LLMs cannot infer the structure of the response (success/failure format, field names for parsed results). Error handling returns generic error messages without recovery guidance. No parameter constraints (enums, ranges) are declared. The tool lacks idempotency documentation and does not guide the LLM on retry behavior after transient failures.

• Document the output schema explicitly. Specify that the tool returns either '{"approved": true}' or '{"approved": false, "reason": "<explanation>"}' so LLMs know how to parse the response.
• Add error categorization and recovery hints. E.g., 'File not found: <path>. Ensure the file exists and is readable.' or 'API rate limit exceeded. Retry in 30 seconds.' for transient errors.
• Add parameter constraints to descriptions. E.g., 'beforeScreenshotPath: Absolute path to a valid PNG file (must exist and be readable)' and 'editRequest: 1-2000 character description of the UI change requested.'
• Declare idempotency in the tool description. E.g., 'This tool is idempotent, calling it multiple times with the same screenshots produces the same result and is safe to retry.'
• Inject API key via environment variable (HYPERBOLIC_API_KEY) instead of command-line argument to avoid leaking secrets in process listings and logs.