Single tool 'analyze_repo' has a basic description (67 chars) but critical gaps in schema documentation, parameter descriptions, and error handling. Input schema visible in code shows only 'repo_path' as string with minimal description. No output schema documented. Tool performs multiple distinct analyses (spelling, checkstyle, javadoc, naming) suggesting composition issues. Error handling returns plain strings rather than structured guidance. No parameter validation, no enum constraints, no pagination despite potentially large result sets.

• Split analyze_repo into four focused tools: check_spelling(repo_path) → {issues: [{file, line, word, suggestion}]}, lint_checkstyle(repo_path) → {violations: [{file, line, rule, message}]}, validate_javadoc(repo_path) → {missing: [{file, line, type}]}, validate_naming(repo_path) → {violations: [{file, issue}]}. Each returns structured JSON with typed fields.
• Add parameter description for repo_path: 'Absolute or relative path to a local Git repository (must contain .git folder). Supports ~/home and relative paths.'
• Document output schema in tool description: 'Returns a structured object with four arrays (spelling_issues, checkstyle_violations, javadoc_missing, naming_violations), each containing file, line, and message fields for LLM parsing.'
• Replace plain-text error strings with structured errors: {error: 'not_a_git_repo', message: 'Path does not contain .git folder', recovery: 'Verify repo_path points to a Git repository root'} so LLM can programmatically handle failures.
• Expand tool description to 150-200 chars: 'Analyzes a local Git repository's Java files for code quality issues. Checks spelling (via codespell), style violations (via checkstyle), missing Javadoc, and naming conventions. Requires codespell and checkstyle installed. Returns structured results for each check type.'

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

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