Loading ToolBench
MCP server for comprehensive Java code review, static analysis, dependency analysis, architecture validation, JBCT methodology compliance, and Spring Framework best practices checking
Java Code Review MCP has 11 tools with moderate definition quality. Most tools have basic descriptions (10-200 chars range), but parameter documentation is inconsistent. Schemas are partially visible in the code but lack formal enum constraints for select parameters. Error handling returns generic 'Error: {str(e)}' messages without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) are present. The server uses string return types for all tools rather than structured JSON responses, forcing LLMs to parse markdown/SARIF manually. Naming follows verb_noun convention (review_*, analyze_*, get_*), which is good, but several tools conflate multiple concerns (e.g., review_java_project includes architecture AND dependency analysis).
Analyze Maven or Gradle dependencies.
Run static analysis on a Java file.
Analyze a Java file (or project directory) for Spring Boot / Spring Framework issues. Checks for: - @Transactional on non-public methods (silently ignored by Spring proxy) - @Autowired field injection (prefer constructor injection) - Missing @Service/@Repository/@Component stereotypes - @RestController methods returning raw types instead of ResponseEntity - @Value with hardcoded fallbacks that mask missing config - Circular @Autowired dependencies Args: file_path: Path to a Java file or project directory. output_format: markdown, json, or sarif.
Get the current configuration.
Get current JBCT configuration.
Get the code review checklist.
No enum constraints on select parameters. 'output_format' accepts markdown|json|sarif but is defined as plain string with description only; 'review_level' accepts full|quick|security similarly. LLMs hallucinate invalid formats without enum enforcement.
All tools return unstructured string output (markdown, JSON, or SARIF as text). LLMs must parse plain-text responses rather than consuming structured JSON. This wastes tokens and invites parsing errors. Baseline practice: return {status, data, errors} JSON with typed fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Load a custom configuration file.
Review a single Java file.
Review Java changes from git diff. By default reviews uncommitted (unstaged) changes. Args: repo_path: Path to git repository root. output_format: markdown, json, or sarif. review_level: full | quick | security. ref: Compare against a git ref (e.g. HEAD~1, main, a SHA). Mutually exclusive with staged. staged: When True, review only staged changes (git diff --cached).
Review an entire Java project (includes architecture analysis). Args: project_path: Path to Java project root. output_format: markdown, json, or sarif. review_level: full | quick | security. include_deps: Whether to analyse Maven/Gradle dependencies. use_cache: Cache per-file results keyed by mtime (skip unchanged files).
Review Java file for JBCT methodology compliance. JBCT (Java Backend Coding Technology) is a methodology for writing predictable, testable Java backend code. This tool checks for: - Return types (T, Option, Result, Promise) - Exception handling (use Cause, not exceptions) - Value object patterns (factory methods) - Lambda complexity rules - Functional iteration patterns - Architecture (no I/O in domain) - Naming conventions - Zone-based method naming Args: file_path: Path to Java file or project directory output_format: Output format - markdown, json, or sarif profile: JBCT profile - basic or full
Error handling returns bare exception strings ('Error: {str(e)}') with no recovery guidance. Per the rubric, errors should categorize as retryable vs user-fixable and include actionable next steps. Example: 'File not found at /path/to/file.java. Verify the path and try again, or call list_project_files() to see available files.'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Per current MCP spec (2026-07-28), read-only tools like get_current_config should declare readOnlyHint=true; load_custom_config should declare destructiveHint=true. These hints guide agent safety planning.
review_java_project conflates two concerns: file-by-file review AND architecture analysis AND optional dependency analysis. Per composition pattern, split into separate tools (review_java_project_files, analyze_project_architecture, analyze_dependencies) so agents compose as needed.
Parameter 'tools' in analyze_java_static accepts string 'all' or 'specific tool name' but no enum list of valid tools is provided. LLMs cannot know which tool names are accepted. Should be: enum with known options (e.g., ['checkstyle', 'spotbugs', 'errorprone', 'pmd', 'all']).
get_current_config, get_jbct_config, and get_review_checklist return markdown-formatted strings. No output schema documented. LLMs cannot plan downstream operations on config/checklist data without parsing plain text.
Parameter 'build_tool' in analyze_java_dependencies accepts 'auto', 'maven', or 'gradle' but no enum constraint enforces valid values. LLM might pass 'ant' or 'gradle-wrapper'.