javalens-mcp
JavaLens: AI-First Code Analysis for Java
An MCP server providing 63 semantic analysis tools for Java, built directly on Eclipse JDT for compiler-accurate code understanding.
Built for AI Agents
JavaLens exists because AI systems need compiler-accurate insights that reading source files cannot provide. When an AI uses grep or Read to find usages of a method, it cannot distinguish:
A method call from a method with the same name in an unrelated class
A field read from a field write
An interface implementation from an unrelated class
A cast to a type from other references to that type
This leads to incorrect refactorings, missed usages, and incomplete understanding of code behavior.
Compiler-Accurate Analysis
JavaLens provides compiler-accurate code analysis through Eclipse JDT—the same engine that powers Eclipse IDE. Unlike text search, JDT understands:
Type resolution across inheritance hierarchies
Method overloading and overriding
Generic type arguments
Import resolution and classpath dependencies
Example: Finding all places where UserService.save() is called:
Approach | Result |
| Returns 47 matches including |
| Returns exactly 12 calls to |
AI Training Bias Warning
⚠️ Important for AI developers and users
AI models may exhibit trained bias toward native tools (Grep, Read, LSP) over MCP server tools, even when semantic analysis provides better results. This happens because:
Training data contains extensive grep/text-search patterns
Native tools are "always available" in the model's experience
The model may not recognize when semantic analysis is superior
To get the best results:
Add guidance to your project instructions or system prompt (e.g., CLAUDE.md for Claude Code):
## Code Analysis Preferences
For Java code analysis, prefer JavaLens MCP tools over text search:
- Use `find_references` instead of grep for finding usages
- Use `find_implementations` instead of text search for implementations
- Use `analyze_type` to understand a class before modifying it
- Use refactoring tools (rename_symbol, extract_method) for safe changes
Semantic analysis from JDT is more accurate than text-based search,
especially for overloaded methods, inheritance, and generic types.What is JavaLens?
JavaLens is an MCP server that gives AI assistants deep understanding of Java codebases. It provides semantic analysis, navigation, refactoring, and code intelligence tools that go beyond simple text search.
Why Not LSP?
Language Server Protocol was designed for IDE autocomplete and basic navigation—not for AI agent workflows that require deep semantic analysis.
Capability | Native LSP | JavaLens |
Find all | ❌ | ✅ |
Find all | ❌ | ✅ |
Find all casts to a type | ❌ | ✅ |
Distinguish field reads from writes | ❌ | ✅ |
Detect circular package dependencies | ❌ | ✅ |
Calculate cyclomatic complexity | ❌ | ✅ |
Find unused private methods | ❌ | ✅ |
Detect possible null pointer bugs | ❌ | ✅ |
JavaLens wraps Eclipse JDT Core directly via OSGi, providing:
16 fine-grained reference types: Find specifically casts, annotations, throws clauses, catch blocks, instanceof checks, method references, type arguments
Read vs write access distinction: Track where fields are mutated vs just read
Indexed search: 10x faster than AST walking for large codebases
Full AST access: Direct manipulation for complex refactorings
Installation
Prerequisites
Java 21 or later (must be on PATH or set JAVA_HOME)
JavaLens is an analytical server, not a compiler. It uses Eclipse JDT 2024-09 to parse and understand Java source code from version 1.1 through 23. Java 21 is required only as the server runtime.
Install via npm
{
"mcpServers": {
"javalens": {
"command": "npx",
"args": ["-y", "javalens-mcp"],
"env": {
"JAVA_PROJECT_PATH": "/path/to/your/java/project"
}
}
}
}The distribution (~19 MB) is downloaded and cached on first run.
Download
Download from Releases:
Platform | File |
All platforms |
|
Extract to a location of your choice (e.g., /opt/javalens or C:\javalens).
Configure MCP Client
Add to your MCP configuration (e.g., .mcp.json for Claude Code):
{
"mcpServers": {
"javalens": {
"command": "java",
"args": ["-jar", "/path/to/javalens/javalens.jar", "-data", "/path/to/javalens-workspaces"]
}
}
}The -data argument specifies where JavaLens stores its workspace metadata. See How Workspaces Work below.
Auto-Load a Project
Set JAVA_PROJECT_PATH to auto-load a project when the server starts:
{
"mcpServers": {
"javalens": {
"command": "java",
"args": ["-jar", "/path/to/javalens/javalens.jar", "-data", "/path/to/javalens-workspaces"],
"env": {
"JAVA_PROJECT_PATH": "/path/to/your/java/project"
}
}
}
}Note: Project loading happens asynchronously in the background. The MCP server responds immediately while the project loads. Use
health_checkto monitor loading status—it will show"project.status": "loading"until complete, then"loaded"when ready.
How Workspaces Work
Unlike in-memory code models, Eclipse JDT requires a workspace directory to store:
Search indexes for fast symbol lookup
Compilation state and caches
Project metadata
Workspaces Are Outside Your Source
JavaLens creates its workspace outside your source project to keep your codebase clean:
Your Java Project (unchanged)
├── src/main/java/
├── pom.xml
└── (no Eclipse files added)
JavaLens Workspace (specified by -data)
└── {session-uuid}/
├── .metadata/ <- JDT indexes and state
└── javalens-project/ <- Links to your source (not copies)Why this matters:
No pollution: Your source tree stays clean—no
.projector.classpathfilesNo conflicts: Works alongside any build system without interference
Session isolation: Each MCP session gets its own workspace, enabling concurrent analysis
Session Lifecycle
JavaLens starts and creates a unique workspace:
{base}/{uuid}/load_projectcreates linked folders pointing to your sourceJDT builds indexes in the workspace (not in your project)
When the session ends, the workspace is cleaned up
Tools
Navigation (10 tools)
Tool | Description |
| Search types, methods, fields by glob pattern |
| Navigate to symbol definition |
| Find all usages of a symbol |
| Find interface/class implementations |
| Get inheritance chain |
| Get all symbols in a file |
| Get detailed symbol information at position |
| Get type details at cursor |
| Get method details at cursor |
| Get field details at cursor |
Fine-Grained Reference Search (9 tools)
These use JDT's unique reference type constants—not available through LSP:
Tool | Description |
| Find all |
| Find all |
| Find all |
| Find all |
| Find all |
| Find all |
| Find all |
| Find all |
| Find |
Analysis (16 tools)
Tool | Description |
| Get compilation errors and warnings |
| Fast syntax-only validation |
| Find all callers of a method |
| Find all methods called by a method |
| Find where fields are mutated |
| Discover JUnit/TestNG test methods |
| Find unused private members |
| Detect null risks, empty catches, resource leaks |
| Get documentation/signature for symbol |
| Get parsed Javadoc |
| Get method signature at call site |
| Get containing method/class at position |
| Blast radius — all files and call sites affected by changing a symbol |
| Variable read/write/declaration tracking within a method |
| Branching, loops, return/throw points, nesting depth |
| Find Spring DI registrations (@Component, @Bean, @Autowired, @Inject) |
Compound Analysis (4 tools)
Combine multiple queries to reduce round-trips:
Tool | Description |
| Get imports, types, diagnostics in one call |
| Get members, hierarchy, usages, diagnostics |
| Get signature, callers, callees, overrides |
| Get instantiations, casts, instanceof counts |
Refactoring (10 tools)
All refactoring tools return text edits rather than applying changes directly:
Tool | Description |
| Rename across entire project |
| Sort and clean imports |
| Extract expression to local variable |
| Extract code block to new method |
| Extract to |
| Create interface from class methods |
| Replace variable with its initializer |
| Replace call with method body |
| Modify params/return, update all callers |
| Convert anonymous class to lambda |
Quick Fixes (3 tools)
Tool | Description |
| Find import candidates for unresolved type |
| List available fixes for problem at position |
| Apply fix by ID (add import, remove import, add throws, try-catch) |
Metrics (5 tools)
Tool | Description |
| Cyclomatic/cognitive complexity, LOC per method |
| Package/type dependencies as nodes and edges |
| Detect package cycles using Tarjan's SCC algorithm |
| Find types exceeding method/field/line count thresholds |
| Check against Java naming conventions |
Project & Infrastructure (6 tools)
Tool | Description |
| Server status and capabilities |
| Load Maven/Gradle/Bazel/plain Java project |
| Get package hierarchy |
| Get classpath entries |
| Get members by type name |
| Find overridden method in superclass |
Usage
Basic Workflow
1. load_project(projectPath="/path/to/java/project")
2. search_symbols(query="*Service", kind="Class")
3. find_references(filePath="...", line=10, column=15)
4. analyze_type(typeName="com.example.UserService")Coordinate System
All line/column parameters are zero-based:
Line 0, Column 0 = first character of file
Path Handling
Response paths are relative by default
All paths use forward slashes for cross-platform consistency
Input paths can be relative or absolute
Important Notes
No Live File Watching
JavaLens analyzes code at load time and does not watch for file changes. This is by design—the AI coding agent is responsible for maintaining synchronization:
Event | Agent Action |
After writing/editing files | Call |
Before complex refactoring | Call |
After external changes (git pull, etc.) | Call |
Why not automatic watching?
AI agents make discrete edits with clear boundaries—auto-sync adds complexity without benefit
The agent controls when analysis should reflect changes
Avoids race conditions between file writes and index updates
Recommended pattern:
1. Use JavaLens tools to analyze
2. Write changes to files
3. Call load_project to refresh
4. Use JavaLens tools to verify changesRefactoring Returns Edits
Refactoring tools return text edits but don't modify files. This gives visibility into what would change before applying.
Session Isolation
Each MCP session is independent with its own workspace UUID. Multiple sessions can analyze the same project concurrently.
Build System Support
System | Detection |
Maven |
|
Gradle |
|
Bazel |
|
Plain Java |
|
Configuration
Environment Variable | Description | Default |
| Auto-load project on startup | (none) |
| Operation timeout | 30 |
| TRACE/DEBUG/INFO/WARN/ERROR | INFO |
| JVM options, e.g. | (default: 512m via eclipse.ini) |
Building from Source
git clone https://github.com/pzalutski-pixel/javalens-mcp.git
cd javalens-mcp
./mvnw clean verifyDistributions are output to org.javalens.product/target/products/.
Build Requirements
Java 21+ (server runtime)
Maven 3.9+ (wrapper included)
Architecture
┌─────────────────────────────────────────────────────────┐
│ MCP Client │
└─────────────────────────────────────────────────────────┘
│ JSON-RPC over stdio
┌─────────────────────────────────────────────────────────┐
│ org.javalens.mcp │
│ McpProtocolHandler → ToolRegistry → 56 Tools │
└─────────────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────────────┐
│ org.javalens.core │
│ JdtServiceImpl → WorkspaceManager, SearchService │
└─────────────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────────────┐
│ Eclipse JDT Core (via OSGi/Equinox) │
│ IWorkspace, IJavaProject, SearchEngine, ASTParser │
└─────────────────────────────────────────────────────────┘License
MIT License - see LICENSE for details.
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pzalutski-pixel/javalens-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server