Related Servers

While many tools have distinct purposes, there are several overlapping ones: e.g., get_type_at_position, get_symbol_info, and get_hover_info all return type/symbol info; analyze_file vs get_document_symbols+get_diagnostics overlaps; get_type_usage_summary vs find_type_instantiations/find_casts etc. Also, find_unused_code and find_unreachable_code are conceptually similar. The detailed descriptions help but an agent might struggle to pick the right one.

Tool names mostly follow a verb_noun pattern (load_project, search_symbols, get_*, find_*, analyze_*, extract_*). However, there is inconsistency: some use 'get_' (get_type_at_position) and others use 'analyze_' (analyze_type) for similar operations; also 'find_*' is used for both searching usages (find_references) and finding issues (find_possible_bugs). Mixing verbs like 'get', 'find', 'analyze', 'extract', 'inline', 'change', 'apply' is natural but the distinction is not always clear.

75 tools is excessive for a typical MCP server. Many tools are micro-optimizations or fine-grained variants (e.g., multiple get_*_at_position tools, and many find_* for each usage type). This makes the tool set overwhelming and increases selection complexity. It would be more appropriate to have 10-20 well-defined tools covering the same functionality.

The tool set covers a broad range of Java analysis and refactoring operations: navigation, references, hierarchy, diagnostics, refactoring (rename, extract, inline, pull up/push down), and code quality analysis (complexity, dependency, circular deps). It is quite complete for a language server, with minor gaps like lacking a tool for global code search (only search_symbols) or a way to list all files.