Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jdtls-mcp find implementation of 'processOrder' method"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides Java language support by wrapping the Eclipse JDT Language Server (JDTLS).
This server allows AI assistants to understand Java codebases, search symbols, navigate code (definition, references, implementations), and read third-party .class files natively.
This server exposes the following MCP tools:
java_workspace_symbols: Search for classes, interfaces, and methods across the entire workspace.
java_document_symbols: Get the hierarchical outline of a specific file.
java_definition: Find the definition of a symbol at a specific location.
java_references: Find usages of a symbol at a specific location.
java_implementations: Find implementations of a symbol at a specific location.
java_hover: Get Javadoc and type signature for a symbol.
java_class_content: Fetch the source code for a class located inside a third-party jar (handles jdt:// URIs).
Related MCP server: jons-mcp-java
Node.js: v16 or higher.
JDTLS: Eclipse JDT Language Server must be installed on your machine and the jdtls executable must be available in your system's PATH.
We recommend building and linking the package globally. This makes the jdtls-mcp command available everywhere and makes future updates easy.
# Clone the repository
git clone https://github.com/Kicey/jdtls-mcp.git
cd jdtls-mcp
# Install dependencies
npm install
# Build the TypeScript code
npm run build
# Link the package globally
npm linkTo update the server later, simply run git pull followed by npm run build in the repository folder.
Below are configuration examples for adding this MCP server to various AI coding assistants now that it is linked globally.
Add the following to your claude_desktop_config.json file:
{
"mcpServers": {
"jdtls": {
"command": "jdtls-mcp",
"args": []
}
}
}To use with Cursor, open Settings > Features > MCP Servers and add a new server:
Type: command
Name: jdtls
Command: jdtls-mcp
If you are using the official claude CLI, you can add the server by running:
claude mcp add jdtls -- jdtls-mcpFor VS Code extensions that support MCP (like Roo Code / Cline), configure the server in your MCP settings file (typically cline_mcp_settings.json):
{
"mcpServers": {
"jdtls": {
"command": "jdtls-mcp",
"args": []
}
}
}The server manages jdtls processes automatically per workspace.
The processes will gracefully shut down after 30 minutes of inactivity to save resources.
Required workspacePath arguments should be absolute paths to the root of the target Java project.
Fetch the source code for a class located inside a third-party jar (handles jdt:// URIs).
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | The jdt:// URI returned by definition/reference tools. | |
| workspacePath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool fetches source code and handles jdt:// URIs, but lacks details on failure modes, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 16 words that efficiently conveys the tool's purpose and special handling, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description covers the core functionality but omits error handling, prerequisites, and return value details, which would be helpful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'uri' parameter by linking it to jdt:// URIs from third-party jars, but does not clarify the 'workspacePath' parameter. Schema coverage is 50%, and description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches source code for a class inside a third-party jar and specifically handles jdt:// URIs, distinguishing it from sibling tools that deal with definitions, references, symbols, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used after obtaining a jdt:// URI from definition/reference tools, but does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the definition of a symbol at a specific location.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | 0-indexed line number | |
| fileUri | Yes | ||
| character | Yes | 0-indexed character offset | |
| workspacePath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It fails to disclose what happens if the symbol is not found, whether the operation is read-only, or any side effects. The minimal description does not compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but not structured. It lacks any front-loading or organization; every word earns its place, but it is under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 required parameters, no output schema), the description is incomplete. It does not hint at the return value or behavior when the symbol definition exists or not, which is critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (line and character have descriptions, workspacePath and fileUri do not). The description adds no parameter meaning beyond the schema, failing to clarify the expected format for workspacePath and fileUri.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the definition of a symbol at a specific location. This distinguishes it from sibling tools like java_references (references) and java_implementations (implementations), providing a specific verb-resource pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks context on prerequisites, when not to use it, or comparison with siblings, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the hierarchical outline of a specific file.
| Name | Required | Description | Default |
|---|---|---|---|
| fileUri | Yes | The absolute file path or file:// URI. | |
| workspacePath | Yes | Absolute path to the Java project root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It only states it returns a 'hierarchical outline' but does not disclose read-only nature, error conditions, performance characteristics, or what 'hierarchical outline' entails (e.g., nesting levels, included symbols).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise, though slightly underspecified for full understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's purpose (returning a structured outline), the description should explain what the outline contains (e.g., classes, methods) and potential file restrictions. It lacks this completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The tool description adds no extra meaning to the parameters beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the hierarchical outline of a specific file' clearly specifies the action (get) and resource (hierarchical outline of a file). It distinguishes from siblings like java_workspace_symbols (workspace-level) and java_references (cross-file usage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing a file's structural overview, but provides no explicit guidance on when to use this vs alternatives like java_class_content or java_workspace_symbols. No 'when not to use' or context hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Javadoc and type signature for a symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| fileUri | Yes | ||
| character | Yes | ||
| workspacePath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No disclosure of what happens if symbol not found, no mention of read-only nature or side effects; description is too brief to cover behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but omits essential information; does not earn its place due to lack of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 required parameters and no output schema, the description provides no context on coordinate system, file path format, or return structure; completely inadequate for complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage; description does not explain workspacePath, fileUri, line, or character, leaving their meanings and required format unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves Javadoc and type signature for a symbol, distinguishing it from siblings that provide definitions, references, or class content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like java_definition or java_class_content; missing context for cursor position usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find implementations of a symbol at a specific location.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| fileUri | Yes | ||
| character | Yes | ||
| workspacePath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'find', implying a read operation, but lacks details on behavior like return format, handling of missing symbols, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it trades off informativeness for brevity. It could be expanded with key details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters and no output schema, the description is inadequate. It does not explain how to specify the location or what constitutes a symbol, and it lacks information about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for the 4 required parameters. The parameter names alone are insufficient for an agent to understand their format or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds implementations of a symbol at a specific location, which is a specific verb+resource. It distinguishes from siblings like java_references and java_definition, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Siblings such as java_references and java_definition are named but not differentiated in usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find usages of a symbol at a specific location.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | ||
| fileUri | Yes | ||
| character | Yes | ||
| workspacePath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states 'find usages', but does not mention that it is a read-only operation, potential performance costs, or whether it supports all symbol types. This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the purpose. However, it sacrifices necessary detail for brevity, making it minimally adequate. A bit more structure (e.g., listing parameters briefly) would improve clarity without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the description is incomplete. It does not mention return format, whether results are ordered, or any completion status indicators. The description leaves critical gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the meaning of each parameter. It mentions 'specific location' but fails to clarify line/character indexing (0-based?), the role of workspacePath, or fileUri format. The description adds minimal value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds usages of a symbol at a specific location, which is a specific verb+resource. However, it does not explicitly differentiate from sibling tools like java_implementations or java_definition, which also deal with symbol relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as java_definition for definitions or java_hover for documentation. The description lacks any context about preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for classes, interfaces, and methods across the entire workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query (e.g., class name). | |
| workspacePath | Yes | Absolute path to the Java project root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states it searches across workspace, but does not disclose any behavioral traits like side effects, authentication, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and description lacks details on return format, pagination, or empty results. For a workspace-wide search, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so description adds no additional meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches for classes, interfaces, and methods across the entire workspace. Verb 'search' and resource 'workspace symbols' are specified, and it distinguishes from siblings like java_class_content and java_definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of exclusions or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0java_class_contentjava_definitionjava_document_symbolsjava_hoverjava_implementationsjava_referencesjava_workspace_symbolsScored across 7 tools
Each tool targets a distinct operation: fetching class content, finding definitions, document outline, hover info, implementations, references, and workspace symbol search. No overlap in purposes.
All tools follow a consistent 'java_<noun>' pattern with snake_case naming. The prefix and noun structure is uniform across the set.
7 tools is an appropriate number for a code navigation server. It covers essential browsing operations without being excessive or insufficient.
The tool set covers core code exploration: definition, references, implementations, hover, document outline, and symbol search. Missing features like code completion or diagnostics, but the set is reasonable for static analysis.
Ship better Java with your coding agent.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
