Allows analysis of Java classes from Apache Commons and other Apache Maven dependencies, providing decompiled source code and documentation.
Enables analysis of Java classes from Quarkus and Quarkiverse projects, supporting decompilation and source retrieval from Maven repositories.
Provides analysis of Java classes from Spring Framework libraries, with support for sources.jar, CFR decompiler, and javap fallback.
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., "@java-class-analyzer-mcp analyze the class org.springframework.beans.factory.BeanFactory"
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.
通用Java类分析MCP工具，让AI自动分析Maven项目依赖中的类。
✅ 完整JavaDoc支持 - 自动从sources.jar读取原始源码
✅ 智能降级 - sources.jar → CFR → javap 四级降级
✅ 通用可配置 - 支持任何Maven项目和groupId
✅ 灵活配置 - 通过mcp.json或config.json配置
✅ 自动化 - CFR反编译器可选自动下载
Related MCP server: Maven Package README MCP Server
cd .cursor/java-class-analyzer
npm install有三种配置方式，按优先级：
{
"mcpServers": {
"java-class-analyzer": {
"command": "node",
"args": [".cursor/java-class-analyzer/index.js"],
"env": {
"MAVEN_REPO": "${HOME}/.m2/repository",
"GROUP_ID_MAPPINGS": "[{\"groupId\":\"com/mycompany\",\"prefix\":\"com.mycompany.\"}]"
}
}
}
}复制 config.example.json 为 config.json 并修改：
cp config.example.json config.json默认支持常见的groupId：
com.ql.*
com.qinglusaas.*
io.quarkus.*
io.quarkiverse.*
org.apache.commons.*
org.springframework.*
重启Cursor
在对话中: "请初始化Java类索引"
开始使用: "请分析 [类名]"
环境变量: MAVEN_REPO
默认值: ${HOME}/.m2/repository
{
"env": {
"MAVEN_REPO": "/custom/path/to/.m2/repository"
}
}环境变量: GROUP_ID_MAPPINGS (JSON数组)
说明: 用于识别JAR文件名中的groupId前缀
{
"env": {
"GROUP_ID_MAPPINGS": "[{\"groupId\":\"com/mycompany\",\"prefix\":\"com.mycompany.\"}]"
}
}或在config.json中：
{
"groupIdMappings": [
{ "groupId": "com/mycompany", "prefix": "com.mycompany." },
{ "groupId": "org/example", "prefix": "org.example." }
]
}环境变量: CFR_JAR_PATH
默认值: cfr.jar（当前目录）
{
"env": {
"CFR_JAR_PATH": "/path/to/cfr.jar"
}
}在config.json中配置：
{
"decompile": {
"enableSourcesJar": true,
"enableCFR": true,
"enableJavap": true
}
}工具会按以下优先级获取源码：
优先级 | 方式 | JavaDoc | 质量 | 说明 |
1 | sources.jar | ✅ | 最高 | Maven源码包 |
2 | CFR | ❌ | 高 | 反编译器 |
3 | javap | ❌ | 中 | JDK工具 |
4 | 基本信息 | ❌ | 低 | 兜底 |
java_class_indexer - 构建类索引
java_class_analyzer - 分析反编译类
java_class_search - 搜索类
✅ 所有Maven项目
✅ 任何groupId
✅ 公司内部二方包
✅ 开源第三方库
分析和反编译指定的Java类。根据类的全限定名查找对应的JAR包并进行反编译,返回源代码。
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | 要分析的类的全限定名,例如: com.qinglusaas.connect.domain.model.BizPushRecordDTO |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly explains the core operation: find the JAR by fully qualified name, decompile, and return source code. This makes the read-only nature of decompilation evident, though it does not explicitly state safety or error behavior when a class or JAR is not found.
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, compact sentence that front-loads the action ('analyze and decompile') and conveys the full workflow without any filler. Every phrase earns its place, making it highly efficient for an agent to parse quickly.
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?
For a tool with one parameter, no output schema, and no annotations, the description adequately covers the core input, action, and output ('returns source code'). It leaves out edge cases such as class-not-found or JAR-not-resolved behavior, but the overall context is sufficient for straightforward 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?
The schema already describes the single parameter with 100% coverage as the fully qualified class name. The description essentially restates this, adding only that the class name is used to locate the JAR package, which is a minor procedural detail already implied by the schema. It does not significantly elevate semantic understanding.
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 states a specific verb and resource: 'analyzes and decompiles the specified Java class,' and details the process of locating the JAR by fully qualified name and returning source code. This clearly distinguishes the tool from siblings java_class_indexer and java_class_search, which are focused on indexing and searching rather than decompilation.
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 usage: if you need decompiled source for a class, use this tool. However, it does not explicitly mention when to use it over alternatives or provide exclusions, such as 'use java_class_search to find a class first' or 'do not use if you just need metadata.' The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
构建Java项目依赖类的索引。扫描Maven依赖的所有JAR包,建立类名到JAR包的映射关系。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注释，描述需承担行为披露责任。描述只说明了扫描和建立映射，但未提及副作用（如是否写入磁盘、是否需要网络、耗时、失败行为等）。对于索引构建这类可能产生持久化影响的操作，披露不足。
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?
描述仅两句话，简洁明了，无冗余内容，结构清晰。
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?
无输出模式，描述未说明工具返回什么（如索引位置、状态消息等）。虽然无参数降低复杂性，但缺少返回信息使完整性不足。
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?
参数数量为0，架构描述覆盖率为100%，根据规则基线为4。描述无需提供参数信息，因此评分4。
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?
描述明确说明动词'构建'和资源'Java项目依赖类的索引'，并具体说明扫描Maven JAR包建立类名到JAR包的映射，与兄弟工具（analyzer、search）形成清晰区分。
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?
描述隐含了构建索引的使用场景，但未明确说明何时使用此工具而非java_class_analyzer或java_class_search，也没有提及排除条件。没有提供选择指南。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索Java类。根据关键词模糊搜索已索引的类名,返回匹配的类列表。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the fuzzy-search behavior, the reliance on indexed data, and the list return type, which is adequate for a simple read-style search tool.
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 two brief sentences with no filler. The main action ('search Java classes') is front-loaded, followed by matching behavior and return type.
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?
For a single-parameter search tool with no output schema, the description explains enough to call it correctly: what is searched, how matching works, and that a list of classes is returned. It omits optional response formatting details like pagination or ordering, but these are minor for this simple 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?
The schema already defines 'keyword' with coverage at 100%, but the description adds that the keyword is used for fuzzy matching over indexed class names, providing meaningful semantic context beyond the schema.
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 specifies a search operation over Java classes, stating it fuzzy-matches indexed class names and returns a list of matches. It is obviously distinct from the siblings (indexer/analyzer) in action, though it does not explicitly contrast them.
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?
It gives clear context for when to use the tool: when you need to find Java classes by keyword, and it implies the prerequisite that classes must already be indexed. However, it does not explicitly mention alternatives or exclusions.
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_analyzerjava_class_indexerjava_class_searchScored across 3 tools
Each tool has a clearly distinct role: one builds the index, one searches it, and one decompiles a specific class. There is no functional overlap or ambiguity between them.
All tools share the java_class_ prefix and follow the same noun-style naming pattern: indexer, analyzer, search. This creates a predictable and recognizable set.
Three tools is well-scoped for a Java class analysis server: index, search, and analyze. Each tool is necessary and the count feels complete without being bloated.
The tool surface covers the full workflow: building an index from Maven dependencies, searching indexed classes by keyword, and analyzing/decompiling a selected class. There are no obvious dead ends or missing operations for the stated purpose.
Ship better Java with your coding agent.
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
