Loading ToolBench
Server has 9 tools with complete JSON Schema input definitions and descriptions. However, descriptions are minimal (10-150 chars, well below the 194-char baseline), lack actionable context for LLM selection, and omit prerequisites or recovery guidance. Parameter descriptions exist but are sparse. Output schemas are not documented. Error handling is present but does not guide recovery. Tool naming follows verb_noun convention (java_start, java_get_definition) but lacks clarity on when to use similar tools (e.g., java_get_definition vs java_get_references). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Composition is reasonable, each tool has one responsibility, but chaining context is missing (e.g., java_open_file should document that it must precede java_get_definition).
Get definition location for a symbol.
Get diagnostics (errors/warnings) for a file. This tool now attempts to pull diagnostics actively from the server if supported (LSP 3.17+), otherwise falls back to cached results from asynchronous publishing.
Get hover information for a symbol.
Get references for a symbol.
Pull diagnostics for the entire workspace (LSP 3.17+). Note: This may not be supported by all language server versions.
Load a Maven Java project into the language server workspace. This causes JDTLS to index the project, resolving dependencies and symbols across the entire project without needing to open files individually.
Descriptions lack actionable context. Most are 10 - 50 chars, well below the 194-char baseline. They state WHAT the tool does but omit WHEN to use it, prerequisites, or recovery guidance. E.g., 'Get definition location for a symbol' does not explain that java_open_file must be called first, or what to do if the symbol is not found.
Output schemas are not documented. Tools return results but LLMs cannot see the structure of responses (e.g., what fields does java_get_definition return? Is it a single location or an array?). This forces LLMs to guess and wastes tokens on trial-and-error.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Notify the language server that a file is open (didOpen).
Restart the Java Language Server (JDT.LS).
Start the Java Language Server (JDT.LS). Required before other commands. If already running, it will restart.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. java_start and java_restart are marked WRITE but lack destructiveHint. java_get_* tools are READ_ONLY but lack readOnlyHint. Annotations enable agents to reason about safety and retry logic.
Tool chaining context is missing. java_open_file must precede java_get_definition, but this dependency is not documented in descriptions. LLMs may call tools in wrong order, causing failures.
Error handling does not guide recovery. Code shows error throwing (e.g., 'JDT.LS plugins directory not found') but tool descriptions do not explain what the LLM should do next (retry, check configuration, call a different tool). Errors lack actionable guidance.