Java Class Analyzer MCP Server
Click on "Install 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 Serveranalyze the structure of com.example.QueryBizOrderDO in my project"
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 Class Analyzer MCP Server
一个基于Model Context Protocol (MCP)的Java类分析服务,可以扫描Maven项目依赖、反编译Java类文件、获取class方法列表等详细信息,并提供给LLM进行代码分析。
适用场景
Cursor等AI工具直接生成调用二方(内部调用)、三方包(外部调用)接口的代码,但因AI无法读取未在当前工程中打开的依赖源码,导致生成的代码错误频出,甚至出现幻觉式编码。
为解决此问题,一般会直接拷贝源码内容喂给LLM;或者先将源码文件放到当前工程内,再在对话中引用。
而使用本地反编译MCP方案最有效,能精准解析jar包中的类与方法,显著提升代码生成的准确性和可用性。
Related MCP server: maven-indexer-mcp
功能特性
🚀使用方便:mcp服务基于TypeScript实现,使用npm打包,方便分发和安装,弱环境依赖。
🔍 依赖扫描: 自动扫描Maven项目的所有依赖JAR包
📦 类索引: 建立类全名到JAR包路径的映射索引
🔄 反编译: 使用CFR工具(已内置有)实时反编译.class文件为Java源码
📊 类分析: 分析Java类的结构、方法、字段、继承关系等
💾 智能缓存: 按包名结构缓存反编译结果,支持缓存控制
🚀 自动索引: 执行分析前自动检查并创建索引
⚙️ 灵活配置: 支持外部指定CFR工具路径
🤖 LLM集成: 通过MCP协议为LLM提供Java代码分析能力
使用示例
在IDE中注册mcp服务

在智能体对话中使用mcp

使用说明
mcp服务安装
全局安装(推荐)
npm install -g java-class-analyzer-mcp-server安装后可以直接使用 java-class-analyzer-mcp 命令。
本地安装
npm install java-class-analyzer-mcp-server从源码安装
git clone https://github.com/handsomestWei/java-class-analyzer-mcp-server.git
cd java-class-analyzer-mcp-server
npm install
npm run buildMCP服务配置
方法1:使用生成的配置(推荐)
运行以下命令生成配置模板:
java-class-analyzer-mcp config -o mcp-client-config.json然后将生成的配置内容添加到你的MCP客户端配置文件中。
方法2:手动配置
参考以下配置示例,添加到MCP客户端配置文件中:
全局安装后的配置:
{
"mcpServers": {
"java-class-analyzer": {
"command": "java-class-analyzer-mcp",
"args": ["start"],
"env": {
"NODE_ENV": "production",
"MAVEN_REPO": "D:/maven/repository",
"JAVA_HOME": "C:/Program Files/Java/jdk-11"
}
}
}
}本地安装后的配置:
{
"mcpServers": {
"java-class-analyzer": {
"command": "node",
"args": [
"node_modules/java-class-analyzer-mcp-server/dist/index.js"
],
"env": {
"NODE_ENV": "production",
"MAVEN_REPO": "D:/maven/repository",
"JAVA_HOME": "C:/Program Files/Java/jdk-11"
}
}
}
}参数说明
command: 运行MCP服务器的命令,这里使用nodeargs: 传递给Node.js的参数,指向npm run build编译后的dist文件夹内文件env: 环境变量设置
环境变量说明
NODE_ENV: 运行环境标识production: 生产环境,减少日志输出,启用性能优化development: 开发环境,输出详细调试信息test: 测试环境
MAVEN_REPO: Maven本地仓库路径(可选)如果设置,程序会使用指定的仓库路径扫描JAR包
如果未设置,程序会使用默认的
~/.m2/repository路径
JAVA_HOME: Java安装路径(可选)如果设置,程序会使用
${JAVA_HOME}/bin/java执行Java命令(用于CFR反编译)如果未设置,程序会使用PATH中的
java命令
CFR_PATH: CFR反编译工具的路径(可选,程序会自动查找)
可用的工具
1. scan_dependencies
扫描Maven项目的所有依赖,建立类名到JAR包的映射索引。
参数:
projectPath(string): Maven项目根目录路径forceRefresh(boolean, 可选): 是否强制刷新索引,默认false
示例:
{
"name": "scan_dependencies",
"arguments": {
"projectPath": "/path/to/your/maven/project",
"forceRefresh": false
}
}2. decompile_class
反编译指定的Java类文件,返回Java源码。
参数:
className(string): 要反编译的Java类全名,如:com.example.QueryBizOrderDOprojectPath(string): Maven项目根目录路径useCache(boolean, 可选): 是否使用缓存,默认true。避免每次都重复生成。cfrPath(string, 可选): CFR反编译工具的jar包路径。已内置有,可以额外指定版本。
示例:
{
"name": "decompile_class",
"arguments": {
"className": "com.example.QueryBizOrderDO",
"projectPath": "/path/to/your/maven/project",
"useCache": true,
"cfrPath": "/path/to/cfr-0.152.jar"
}
}3. analyze_class
分析Java类的结构、方法、字段等信息。
参数:
className(string): 要分析的Java类全名projectPath(string): Maven项目根目录路径
示例:
{
"name": "analyze_class",
"arguments": {
"className": "com.example.QueryBizOrderDO",
"projectPath": "/path/to/your/maven/project",
}
}缓存文件
在当前工程,会生成以下缓存目录和文件。
.mcp-class-index.json: 类索引缓存文件.mcp-decompile-cache/: 反编译结果缓存目录(按包名结构).mcp-class-temp/: 临时文件目录(按包名结构)
工作流程
自动索引: 首次调用
analyze_class或decompile_class时,自动检查并创建索引智能缓存: 反编译结果按包名结构缓存,支持缓存控制
分析类: 使用
analyze_class或decompile_class获取类的详细信息LLM分析: 将反编译的源码提供给LLM进行代码分析
技术架构
核心组件
DependencyScanner: 负责扫描Maven依赖和建立类索引
DecompilerService: 负责反编译.class文件
JavaClassAnalyzer: 负责分析Java类结构
MCP Server: 提供标准化的MCP接口
依赖扫描流程
执行
mvn dependency:tree获取依赖树解析每个JAR包,提取所有.class文件
建立"类全名 -> JAR包路径"的映射索引
缓存索引到
.mcp-class-index.json文件
反编译流程
根据类名查找对应的JAR包路径
检查缓存,如果存在且启用缓存则直接返回
从JAR包中提取.class文件到
.mcp-class-temp目录(按包名结构)使用CFR工具反编译.class文件
保存反编译结果到缓存
.mcp-decompile-cache目录(按包名结构)返回Java源码
故障排除
常见问题
Maven命令失败
确保Maven已安装并在PATH中
检查项目是否有有效的pom.xml文件
CFR反编译失败
确保CFR jar包已下载(支持任意版本号)
检查Java环境是否正确配置
可通过
cfrPath参数指定CFR路径
类未找到
程序会自动检查并创建索引
检查类名是否正确
确保项目依赖已正确解析
测试说明
构建项目
npm install
npm run build测试工具使用
项目提供了独立的测试工具,可以直接测试MCP服务的各个功能,无需通过MCP客户端。
# 测试所有工具
node test-tools.js
# 测试特定工具
node test-tools.js --tool decompile_class --class com.alibaba.excel.EasyExcelFactory --project /path/to/project
# 不使用缓存
node test-tools.js --tool decompile_class --no-cache
# 指定CFR路径
node test-tools.js --tool decompile_class --cfr-path /path/to/cfr.jar测试工具参数
-t, --tool <工具名>: 指定要测试的工具 (scan|decompile|analyze|all)-p, --project <路径>: 项目路径-c, --class <类名>: 要分析的类名--no-refresh: 不强制刷新依赖索引--no-cache: 不使用反编译缓存--cfr-path <路径>: 指定CFR反编译工具的jar包路径-h, --help: 显示帮助信息
日志级别控制
通过 NODE_ENV 环境变量控制日志输出:
development: 输出详细调试信息production: 只输出关键信息
Available Tools
3 toolsanalyze_classC
分析Java类的结构、方法、字段等信息
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | 要分析的Java类全名 | |
| projectPath | Yes | Maven项目根目录路径 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does (analyzes class structure) but doesn't describe behavioral traits such as whether it's read-only, what permissions are needed, how it handles errors, or what the output format looks like. For a tool with no annotations, this leaves significant gaps in understanding its operation.
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, efficient sentence in Chinese: '分析Java类的结构、方法、字段等信息'. It's front-loaded with the core purpose and wastes no words, making it highly concise and well-structured for quick 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 the complexity of analyzing Java classes, the lack of annotations, and no output schema, the description is incomplete. It doesn't cover what information is returned, how the analysis is performed, or any behavioral context. For a tool with two required parameters and no structured output, more detail is needed to guide 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?
The input schema has 100% description coverage, with clear parameter descriptions in Chinese. The tool description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter interactions, constraints, or usage examples. With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract.
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's purpose: '分析Java类的结构、方法、字段等信息' (analyze Java class structure, methods, fields, etc.). It specifies the verb 'analyze' and the resource 'Java class', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'decompile_class' or 'scan_dependencies', which prevents a score of 5.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or any context for choosing this analysis tool over decompilation or dependency scanning. There's no information about prerequisites or exclusions, leaving usage entirely implied from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decompile_classC
反编译指定的Java类文件,返回Java源码
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | 要反编译的Java类全名,如:com.example.QueryBizOrderDO | |
| projectPath | Yes | Maven项目根目录路径 | |
| useCache | No | 是否使用缓存,默认true | |
| cfrPath | No | CFR反编译工具的jar包路径,可选 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the output (Java source code) but doesn't cover important aspects like whether this is a read-only operation, potential performance impacts, error handling, or that it uses CFR tooling (only hinted in the schema). The description is minimal and lacks behavioral context.
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 extremely concise - a single sentence that directly states the tool's purpose and output. Every word earns its place with no wasted text. It's appropriately sized for a straightforward decompilation tool.
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 annotations, no output schema, and a 4-parameter tool with mutation implications (decompilation typically involves processing/transformation), the description is insufficient. It doesn't explain what the tool actually does beyond the basic purpose, doesn't mention the CFR tool dependency, and provides no information about return format or error conditions.
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%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, with no value added by the description.
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 action ('反编译' - decompile) and resource ('指定的Java类文件' - specified Java class file), and specifies the output ('返回Java源码' - returns Java source code). It doesn't explicitly differentiate from sibling tools like analyze_class or scan_dependencies, but the decompilation purpose is distinct enough to avoid confusion.
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 provides no guidance on when to use this tool versus the sibling tools (analyze_class, scan_dependencies). There's no mention of prerequisites, alternatives, or specific contexts where decompilation is preferred over analysis or dependency scanning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_dependenciesC
扫描Maven项目的所有依赖,建立类名到JAR包的映射索引
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Maven项目根目录路径 | |
| forceRefresh | No | 是否强制刷新索引 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (scanning and indexing) but lacks critical behavioral details: it doesn't specify whether this is a read-only operation, what permissions are required, whether it modifies any files, how long it might take, or what the output format is. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, with every word contributing to understanding the core functionality. There's no wasted verbiage or 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?
Given the complexity of scanning and indexing dependencies, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., a mapping structure, file location, or error handling), nor does it cover behavioral aspects like performance or side effects. For a tool that likely involves file system operations and data processing, more context is needed.
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 description coverage is 100%, meaning the input schema already fully documents both parameters ('projectPath' and 'forceRefresh'). The description adds no additional parameter semantics beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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's purpose: '扫描Maven项目的所有依赖,建立类名到JAR包的映射索引' (Scan all dependencies of a Maven project, build a class name to JAR package mapping index). It uses specific verbs ('扫描' - scan, '建立' - build) and identifies the resource (Maven project dependencies). However, it doesn't explicitly differentiate from sibling tools like 'analyze_class' or 'decompile_class', which appear to be related but distinct operations.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites might be needed, or how it relates to the sibling tools ('analyze_class' and 'decompile_class'). The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose with no overlap: analyze_class examines class structure, decompile_class converts bytecode to source code, and scan_dependencies maps dependencies in a project. An agent can easily distinguish between analyzing structure, decompiling, and dependency scanning.
All tool names follow a consistent verb_noun pattern in snake_case (analyze_class, decompile_class, scan_dependencies), with clear, descriptive verbs that indicate the action performed on the target noun. There are no deviations or mixed conventions.
With only 3 tools, the set feels thin for a Java class analyzer server, potentially lacking operations like listing classes, updating analyses, or handling specific Java features. While the tools cover core functions, more tools might be expected for comprehensive analysis.
The tools cover key areas (analysis, decompilation, dependency scanning) but have notable gaps, such as no create, update, or delete operations for classes or dependencies, and no tools for handling multiple classes or projects. This could limit agents in complex workflows.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Related MCP Servers
- AlicenseAqualityAmaintenanceDecompiles Maven dependencies into readable Java source directly inside your AI agent.102631Apache 2.0
- AlicenseNot gradedqualityAmaintenanceIndexes local Maven and Gradle caches to enable AI agents to search for Java classes, method signatures, and source code, including from internal or obscure libraries.15422ISC
- AlicenseAqualityFmaintenanceDecompiles Java .class files, packages, and JARs into readable source code, enabling AI assistants to inspect Java bytecode.34220ISC
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to look up Java class definitions and list dependencies from Maven projects by analyzing local JAR files via the Model Context Protocol.204MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/handsomestWei/java-class-analyzer-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server