Single tool 'check_code_quality' has a basic schema and description but lacks depth required for production use. Description is 104 chars (within range but generic). Input schema is present with proper type and description for the 'code' parameter. However, output schema is completely undocumented, the tool returns a JSON object with 'score', 'findings', and 'summary' fields, but this structure is never formally declared. No error handling guidance, no parameter constraints (e.g., max code length), no documentation of what 'findings' array contains or how 'score' is calculated. The tool performs static analysis but provides no recovery guidance when issues are detected. Missing descriptions for output fields and no indication of which errors are retryable vs. fatal.

• Add formal output schema documenting {score: number (0-10), findings: [{type: string, rule: string, message: string, severity: enum('Critical'|'High'|'Low')}], summary: string}
• Constrain 'code' parameter: add maxLength (e.g., 50000 chars), add description of supported languages (JavaScript, Python, etc.), add note about encoding (UTF-8 only)
• Enhance tool description: add 'When to use' section explaining this is for static analysis only, not runtime testing; clarify scoring algorithm (e.g., 'Starts at 10, deductions for eval, secrets, etc.')
• Add error handling: return {error: string, recoveryHint: string} for invalid input; distinguish 'no issues' from 'analysis failed' with explicit status field
• Document findings severity enum and rule categories in description or via a separate discovery tool (e.g., 'list_code_review_rules') so LLM knows valid values

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

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