Skip to main content
Glama
handsomestWei

Java Class Analyzer MCP Server

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 build

MCP服务配置

方法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服务器的命令,这里使用 node

  • args: 传递给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.QueryBizOrderDO

  • projectPath (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/: 临时文件目录(按包名结构)

工作流程

  1. 自动索引: 首次调用analyze_classdecompile_class时,自动检查并创建索引

  2. 智能缓存: 反编译结果按包名结构缓存,支持缓存控制

  3. 分析类: 使用analyze_classdecompile_class获取类的详细信息

  4. LLM分析: 将反编译的源码提供给LLM进行代码分析

技术架构

核心组件

  • DependencyScanner: 负责扫描Maven依赖和建立类索引

  • DecompilerService: 负责反编译.class文件

  • JavaClassAnalyzer: 负责分析Java类结构

  • MCP Server: 提供标准化的MCP接口

依赖扫描流程

  1. 执行mvn dependency:tree获取依赖树

  2. 解析每个JAR包,提取所有.class文件

  3. 建立"类全名 -> JAR包路径"的映射索引

  4. 缓存索引到.mcp-class-index.json文件

反编译流程

  1. 根据类名查找对应的JAR包路径

  2. 检查缓存,如果存在且启用缓存则直接返回

  3. 从JAR包中提取.class文件到.mcp-class-temp目录(按包名结构)

  4. 使用CFR工具反编译.class文件

  5. 保存反编译结果到缓存.mcp-decompile-cache目录(按包名结构)

  6. 返回Java源码

故障排除

常见问题

  1. Maven命令失败

    • 确保Maven已安装并在PATH中

    • 检查项目是否有有效的pom.xml文件

  2. CFR反编译失败

    • 确保CFR jar包已下载(支持任意版本号)

    • 检查Java环境是否正确配置

    • 可通过cfrPath参数指定CFR路径

  3. 类未找到

    • 程序会自动检查并创建索引

    • 检查类名是否正确

    • 确保项目依赖已正确解析

测试说明

构建项目

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 tools
analyze_classC

分析Java类的结构、方法、字段等信息

ParametersJSON Schema
NameRequiredDescriptionDefault
classNameYes要分析的Java类全名
projectPathYesMaven项目根目录路径

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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源码

ParametersJSON Schema
NameRequiredDescriptionDefault
classNameYes要反编译的Java类全名,如:com.example.QueryBizOrderDO
projectPathYesMaven项目根目录路径
useCacheNo是否使用缓存,默认true
cfrPathNoCFR反编译工具的jar包路径,可选

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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包的映射索引

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesMaven项目根目录路径
forceRefreshNo是否强制刷新索引

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

B3.2/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness3/5

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

ActivityStale
ResponsivenessSyncing

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

Related MCP Servers

Latest Blog Posts

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