How do I use Java Decompiler MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Java Decompiler MCP Server decompile the /path/to/app.jar file into the /src/decompiled directory" 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 Decompiler MCP Server

by RuoJi6

Overview Schema Related Servers Score Discussions

Python

Local

Java Decompiler MCP Server

一个基于 MCP (Model Context Protocol) 的 Java 反编译工具，使用 CFR 反编译器对 .class 和 .jar 文件进行反编译。

功能特性

✅ 单个文件反编译（.class / .jar）
✅ 多个文件批量反编译
✅ 目录递归扫描反编译
✅ 自定义输出目录
✅ 自动下载 CFR 反编译器
✅ 直接保存到文件系统（避免 token 限制）
✅ 实时进度显示
✅ 详细统计信息
✅ 多线程并发处理（大幅提升速度）

Related MCP server: Kawaiidra MCP

改进亮点

🚀 解决大文件/大量文件反编译问题

问题： 当反编译大量文件时，如果将所有结果作为字符串返回，可能超过 MCP 的 token 限制（例如 413,072 字符）。

解决方案：

直接保存到文件系统（推荐）
- 新增 save_to_file 参数（默认 true）
- 反编译结果直接写入指定目录
- 仅返回摘要信息（成功数、失败数、输出路径等）
- 避免通过 MCP 传输大量内容
实时进度显示
- 新增 show_progress 参数（默认 true）
- 显示当前处理进度：[1/46] 处理中: Controller.class
- 实时反馈处理状态
详细统计报告
- 成功/失败/跳过文件数
- 生成的 .java 文件总数
- 输出目录路径
- 清晰的格式化输出

使用示例

场景 1：反编译大量文件（推荐方式）

# 使用 8 个线程并发处理，大幅提升速度
decompile_directory(
    directory_path="/path/to/classes",
    output_dir="/path/to/output",
    save_to_file=True,      # 默认值
    show_progress=True,     # 显示进度
    max_workers=8           # 8 线程并发
)

场景 2：反编译少量文件并查看内容

# 返回反编译内容（仅适用于小文件）
decompile_file(
    file_path="/path/to/MyClass.class",
    save_to_file=False      # 返回内容而不是保存
)

场景 3：静默批量处理

# 不显示详细进度，仅返回统计，单线程处理
decompile_files(
    file_paths=[...],
    show_progress=False,    # 仅显示统计信息
    max_workers=1           # 单线程
)

环境要求

Python >= 3.10
Java Runtime Environment (JRE)
uv (Python 包管理器)

安装

方式一：通过 uvx 直接使用（推荐）

无需安装，直接在 MCP 配置中使用(可让ai自动下载cfr-0.152.jar然后你手动配置路径)：

{
  "mcpServers": {
    "java-decompiler": {
      "type": "stdio",
      "command": "uvx",
      "args": ["java-decompile-mcp"],
      "env": {
        "CFR_PATH": "/你的路径/cfr-0.152.jar"
      },
      "disabled": false
    }
  }
}

方式二：本地开发

# 克隆项目
git clone <repository-url>
cd java-decompile-mcp

# 创建虚拟环境并安装依赖
uv venv
source .venv/bin/activate  # macOS/Linux
# 或 .venv\Scripts\activate  # Windows

uv pip install "mcp>=1.0.0"

MCP 配置

方式一：使用 uvx（推荐，已发布到 PyPI）

在 .kiro/settings/mcp.json 或 claude_desktop_config.json 中添加：

{
  "mcpServers": {
    "java-decompiler": {
      "command": "uvx",
      "args": ["java-decompile-mcp"],
      "disabled": false
    }
  }
}

方式二：本地开发模式

在 .kiro/settings/mcp.json 中添加：

{
  "mcpServers": {
    "java-decompiler": {
      "command": "uv",
      "args": [
        "--directory",
        "/项目路径",
        "run",
        "main.py"
      ],
      "disabled": false,
      "autoApprove": []
    }
  }
}

⚠️ 本地开发模式需要将路径替换为实际的项目路径

项目地址

GitHub: https://github.com/RuoJi6/java-decompile-mcp

可用工具

1. decompile_file

反编译单个文件

参数：

file_path (必需): 要反编译的文件路径
output_dir (可选): 输出目录，默认为文件所在目录下的 decompiled 文件夹
save_to_file (可选): 是否直接保存到文件系统，默认 true（推荐）

示例：

反编译 /path/to/MyClass.class 到 /output/dir

返回结果：

✅ 反编译成功
源文件: /path/to/MyClass.class
输出目录: /output/dir
生成文件数: 1
提示: 反编译结果已保存到文件系统

2. decompile_files

批量反编译多个文件（支持多线程）

参数：

file_paths (必需): 文件路径列表
output_dir (可选): 输出目录
save_to_file (可选): 是否直接保存到文件系统，默认 true
show_progress (可选): 是否显示详细进度，默认 true
max_workers (可选): 最大并发线程数，默认 4（设为 1 则单线程）

示例：

反编译以下文件：
- /path/to/Class1.class
- /path/to/Class2.class
- /path/to/app.jar
使用 8 个线程并发处理

返回结果：

✅ [1/3] 成功: Class1.class
✅ [2/3] 成功: Class2.class
✅ [3/3] 成功: app.jar

============================================================
📊 反编译完成统计
============================================================
✅ 成功: 3
❌ 失败: 0
⏭️  跳过: 0
📁 总计: 3 个文件
📄 生成: 46 个 .java 文件
📂 输出目录: /output/dir
🔧 并发线程: 4
============================================================
💾 反编译结果已保存到文件系统

3. decompile_directory

反编译目录下所有 .class 和 .jar 文件（支持多线程）

参数：

directory_path (必需): 目录路径
output_dir (可选): 输出目录
recursive (可选): 是否递归子目录，默认 true
save_to_file (可选): 是否直接保存到文件系统，默认 true
show_progress (可选): 是否显示详细进度，默认 true
max_workers (可选): 最大并发线程数，默认 4

示例：

反编译 /path/to/classes 目录下的所有 class 文件，使用 8 个线程

返回结果：

📂 扫描目录: /path/to/classes
🔍 找到 46 个文件待反编译
📤 输出目录: /path/to/classes/decompiled
🔧 并发线程: 4

✅ [1/46] 成功: Controller1.class
✅ [2/46] 成功: Controller2.class
...
✅ [46/46] 成功: Utils.class

============================================================
📊 反编译完成统计
============================================================
✅ 成功: 46
❌ 失败: 0
⏭️  跳过: 0
📁 总计: 46 个文件
📄 生成: 46 个 .java 文件
📂 输出目录: /path/to/classes/decompiled
🔧 并发线程: 4
============================================================
💾 反编译结果已保存到文件系统

4. download_cfr_tool

下载 CFR 反编译器

参数：

target_dir (可选): 下载目标目录，默认当前工作目录

5. check_cfr_status

检查 CFR 反编译器状态

6. get_java_version

获取 Java 版本信息

CFR 配置

CFR 反编译器查找顺序：

环境变量 CFR_PATH
项目目录下的 cfr-*.jar
自动下载（首次调用反编译工具时）

方式一：MCP 配置中指定（推荐）

在 mcp.json 的 env 中设置：

{
  "mcpServers": {
    "java-decompiler": {
      "command": "uv",
      "args": ["--directory", "/项目路径", "run", "main.py"],
      "env": {
        "CFR_PATH": "/你的路径/cfr-0.152.jar"
      }
    }
  }
}

方式二：放到项目目录

将 cfr-*.jar 文件放到项目根目录，会自动识别。

方式三：自动下载

调用 download_cfr_tool 工具，会自动从镜像下载到项目目录。

手动运行测试

# 激活虚拟环境
source .venv/bin/activate

# 运行 MCP 服务器
uv run main.py

许可证

MIT License

Available Tools

6 tools

check_cfr_statusC

检查 CFR 反编译器状态

Returns:
    CFR 状态信息

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 only states that the tool checks status and returns information, without detailing aspects like whether it's read-only, requires authentication, has rate limits, or what specific status information is included. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with two short lines: one stating the purpose and another indicating the return. It's front-loaded with the main action and wastes no words, though the structure could be slightly improved by integrating the return statement more seamlessly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is an output schema (which should cover return values), no parameters, and no annotations, the description provides a basic purpose but lacks details on behavioral context. It's minimally adequate for a simple status-check tool but doesn't fully compensate for the absence of annotations, leaving some completeness gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. This meets the baseline for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as '检查 CFR 反编译器状态' (check CFR decompiler status), which provides a clear verb ('check') and resource ('CFR decompiler status'). However, it doesn't differentiate from sibling tools like 'get_java_version' or 'download_cfr_tool' that might also provide status-related information, making it somewhat vague in context.

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 offers no guidance on when to use this tool versus alternatives. There are sibling tools such as 'decompile_directory' or 'get_java_version' that might overlap in functionality, but the description lacks any explicit when-to-use or when-not-to-use instructions, leaving usage unclear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

decompile_directoryA

反编译指定目录下的所有 .class 和 .jar 文件（支持多线程）

Args:
    directory_path: 要扫描的目录路径
    output_dir: 输出目录，默认为目标目录下的 decompiled 文件夹
    recursive: 是否递归扫描子目录，默认为 True
    save_to_file: 是否直接保存到文件系统（推荐），默认为 True
    show_progress: 是否显示详细进度信息，默认为 True
    max_workers: 最大并发线程数，默认为 4（设为 1 则单线程处理）

Returns:
    反编译结果信息

ParametersJSON Schema

Name	Required	Description	Default
`directory_path`	Yes
`output_dir`	No
`recursive`	No
`save_to_file`	No
`show_progress`	No
`max_workers`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: multi-threading support, file system operations (saving to files), and progress display. However, it lacks details on error handling, resource consumption, or what '反编译结果信息' (decompilation result information) entails beyond the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a purpose statement followed by parameter explanations. Every sentence adds value, though the Chinese-to-English translation might slightly affect clarity. It's appropriately sized for a tool with 6 parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, file operations, multi-threading) and no annotations, the description does well by covering parameters and basic behavior. The existence of an output schema means return values needn't be detailed. However, it could better address error cases or performance implications.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It provides clear semantics for all 6 parameters, explaining their purposes, defaults, and implications (e.g., 'recommended' for save_to_file, effect of max_workers=1). This adds significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('反编译' - decompile) and target resources ('.class and .jar files in a directory'), distinguishing it from sibling tools like 'decompile_file' (single file) and 'decompile_files' (multiple files). It explicitly mentions multi-threading support, which further clarifies its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through parameter explanations (e.g., 'recommended' for save_to_file, default values indicating typical usage). However, it doesn't explicitly state when to use this tool versus alternatives like 'decompile_file' or 'decompile_files', nor does it mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

decompile_fileA

反编译单个 .class 或 .jar 文件

Args:
    file_path: 要反编译的文件路径（.class 或 .jar）
    output_dir: 输出目录，默认为文件所在目录下的 decompiled 文件夹
    save_to_file: 是否直接保存到文件系统（推荐），默认为 True。设为 False 时会返回反编译内容

Returns:
    反编译结果信息或内容

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes
`output_dir`	No
`save_to_file`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's behavior regarding output handling (saving to file system vs returning content) and default behavior, but doesn't mention potential side effects, error conditions, performance characteristics, or security implications of decompilation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, Args, Returns) and uses efficient language. However, the Chinese-to-English translation creates some minor awkwardness, and the '推荐' (recommended) note in the save_to_file parameter could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (decompilation operation), no annotations, and the presence of an output schema (which handles return values), the description provides good coverage. It explains the core functionality, parameters, and output behavior adequately, though additional context about decompilation limitations or requirements would enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description provides comprehensive semantic information for all 3 parameters: 'file_path' specifies acceptable file types (.class or .jar), 'output_dir' explains the default behavior, and 'save_to_file' clarifies the trade-off between file output and direct return. This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('反编译' - decompile) and the target resources ('.class 或 .jar 文件'), distinguishing it from siblings like 'decompile_directory' and 'decompile_files' which handle multiple files or directories. The verb+resource combination is precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (for single files) versus alternatives like 'decompile_directory' for directories, but doesn't explicitly state when NOT to use it or compare with all siblings like 'decompile_files'. The guidance is helpful but not exhaustive regarding alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

decompile_filesA

反编译多个 .class 或 .jar 文件（支持多线程）

Args:
    file_paths: 要反编译的文件路径列表
    output_dir: 输出目录，默认为当前目录下的 decompiled 文件夹
    save_to_file: 是否直接保存到文件系统（推荐），默认为 True
    show_progress: 是否显示详细进度信息，默认为 True
    max_workers: 最大并发线程数，默认为 4（设为 1 则单线程处理）

Returns:
    反编译结果信息

ParametersJSON Schema

Name	Required	Description	Default
`file_paths`	Yes
`output_dir`	No
`save_to_file`	No
`show_progress`	No
`max_workers`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses multi-threading capability, progress display options, file output behavior with default directory, and recommended settings. However, it doesn't mention error handling, performance implications, or what '反编译结果信息' (decompilation result information) contains beyond the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with purpose statement, Args section with 5 parameters clearly explained, and Returns section. Every sentence adds value, though the Chinese language might require slightly more processing. It's appropriately sized for a 5-parameter tool with no annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameters and basic behavior. The existence of an output schema means it doesn't need to detail return values. However, for a multi-threaded file processing tool, it could better explain error handling, file format limitations, or performance tradeoffs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate fully. It provides clear semantics for all 5 parameters: explains 'file_paths' as list of files to decompile, 'output_dir' default location, 'save_to_file' recommendation, 'show_progress' as detailed progress info, and 'max_workers' as concurrent thread count with single-threaded option. This adds substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool '反编译多个 .class 或 .jar 文件' (decompiles multiple .class or .jar files), specifying both the verb (decompile) and resources (.class/.jar files). It distinguishes from sibling tools like 'decompile_file' (singular) and 'decompile_directory' by emphasizing multi-file processing with multi-threading support.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through multi-threading support and parameter defaults, but doesn't explicitly state when to use this tool versus alternatives like 'decompile_file' or 'decompile_directory'. It mentions '推荐' (recommended) for 'save_to_file', providing some guidance, but lacks clear when/when-not scenarios or sibling tool comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

download_cfr_toolB

下载 CFR 反编译器到指定目录

Args:
    target_dir: 下载目标目录，默认为当前工作目录

Returns:
    下载结果信息

ParametersJSON Schema

Name	Required	Description	Default
`target_dir`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the download action but doesn't cover critical aspects: where the tool is downloaded from (e.g., a remote repository), authentication needs, network dependencies, error handling, or what '下载结果信息' (download result information) entails. For a tool that likely involves external resources and file system changes, this is insufficient transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with three sentences: a purpose statement, parameter explanation, and return value note. It's front-loaded with the main action. While efficient, the return statement is vague ('下载结果信息'), and some redundancy exists between the purpose and parameter sections, preventing a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (download operation with one parameter) and the presence of an output schema (which should cover return values), the description is minimally adequate. It explains the parameter but lacks behavioral details like source location or error conditions. With no annotations and an output schema, it meets basic needs but leaves gaps in operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaningful context for the single parameter 'target_dir', explaining it as the download target directory with a default to the current working directory. Since schema description coverage is 0% (the schema only provides a title 'Target Dir' without explanation), this compensates well by clarifying the parameter's purpose and default behavior. However, it doesn't detail format constraints (e.g., path validity), keeping it at 4.

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 ('下载' meaning 'download') and the resource ('CFR 反编译器' meaning 'CFR decompiler'), making the purpose specific and understandable. It distinguishes from siblings like 'check_cfr_status' or decompilation tools by focusing on downloading the tool itself rather than using it. However, it doesn't explicitly differentiate from potential non-sibling download tools, keeping it at 4 instead 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 prerequisites (e.g., whether CFR needs to be installed first), when this is necessary compared to using existing installations, or how it relates to sibling tools like 'check_cfr_status'. The lack of usage context leaves the agent without clear decision-making criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_java_versionB

获取当前系统的 Java 版本信息

Returns:
    Java 版本信息

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/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 the tool '获取当前系统的 Java 版本信息' (gets Java version information from the current system), which implies a read-only operation, but doesn't specify whether it requires system access, permissions, or has any side effects. For a tool with zero annotation coverage, this is a significant gap in 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with the main purpose stated first ('获取当前系统的 Java 版本信息') followed by a brief note on returns. There's no wasted text, though the structure could be slightly improved by integrating the return note more seamlessly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits like system dependencies or error handling. The presence of an output schema means the description doesn't need to explain return values, but it could still benefit from more context about usage scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain any parameters, so it appropriately focuses on the tool's purpose. A baseline score of 4 is given for zero-parameter tools when the description is clear about the action.

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 with a specific verb ('获取' meaning 'get') and resource ('Java 版本信息' meaning 'Java version information'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish itself from sibling tools like 'check_cfr_status' or 'decompile_file', which appear to be related to Java decompilation rather than version checking.

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 any prerequisites, context for usage, or comparisons to sibling tools like 'check_cfr_status', leaving the agent to infer usage based on the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.3.1Feb 6, 2026
- Addedcheck_cfr_status
- Addeddecompile_directory
- Addeddecompile_file
- Addeddecompile_files
- Addeddownload_cfr_tool
- Addedget_java_version

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation3/5

The tools have clear distinctions between checking status, downloading, decompiling files/directories, and getting Java version, but decompile_file and decompile_files have overlapping purposes that could cause confusion. The directory vs. file distinction is clear, but the single vs. multiple file tools are functionally similar with minor parameter differences.

Naming Consistency5/5

All tools follow a consistent snake_case pattern with clear verb_noun structure (check_cfr_status, decompile_directory, decompile_file, decompile_files, download_cfr_tool, get_java_version). The naming is predictable and follows the same convention throughout.

Tool Count5/5

With 6 tools, this is well-scoped for a Java decompiler server. Each tool serves a distinct purpose in the decompilation workflow, from setup (download, check status) to core operations (decompile files/directories) to system information (Java version).

Completeness4/5

The toolset covers the essential decompilation workflow comprehensively: tool setup (download, status check), decompilation operations at different granularities (file, files, directory), and system verification (Java version). A minor gap is the lack of configuration tools for CFR options or cleanup operations for decompiled output.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

doc2mcp
io.github.doc2mcp
MCP server for doc2mcp documentation, generated by doc2mcp.
Documentation Access Developer Tools AI & Machine Learning
22
developer
io.github.doc2mcp
MCP server for developer documentation, generated by doc2mcp.
Documentation Access Developer Tools
24
JFrog Remote MCP Server
io.github.jfrog
MCP Server for JFrog, providing tools for development and artifact management.
Developer Tools CI/CD & DevOps Cloud Platforms
215
Git Diff Mcp
io.github.varvararatta
MCP server for git_diff_mcp
Version Control Developer Tools
2

Related MCP Servers

easy-code-reader
Developer Tools Code Analysis
FangYuan33
A
license
Not graded
quality
D
maintenance
An MCP server for intelligently reading Java source code, supporting extraction from Maven dependencies and local projects with dual decompilers.
Updated 6 months ago (2026-03-01 05:38 UTC)
155
Apache 2.0
Kawaiidra MCP
Code Analysis Penetration Testing
wagonbomb
A
license
Not graded
quality
D
maintenance
MCP server that integrates Ghidra for binary analysis, enabling decompilation, disassembly, and advanced reverse engineering tasks through Claude Code.
Updated 6 months ago (2026-03-09 04:37 UTC)
15
MIT
dejared-mcp
Code Analysis Developer Tools
hqkh4nh
A
license
Not graded
quality
A
maintenance
A Model Context Protocol (MCP) server for exploring, analyzing, and decompiling Java JAR files.
Updated 16 days ago (2026-08-21 17:40 UTC)
271
5
MIT
re-llm-decompile
Code Analysis AI & Machine Learning
Heretek-RE
A
license
Not graded
quality
C
maintenance
MCP server that exposes an AI decompiler via an OpenAI-compatible API, enabling decompilation, explanation, and variable renaming of disassembly for binary analysis.
Updated 3 months ago (2026-06-10 19:50 UTC)
MIT

Appeared in Searches

MCP server that supports JAR decompilation

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/RuoJi6/java-decompile-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server