Java Decompiler MCP Server

by RuoJi6

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
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.
Average 3.6/5 across 6 of 6 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![java-decompile-mcp MCP server](https://glama.ai/mcp/servers/RuoJi6/java-decompile-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RuoJi6/java-decompile-mcp)

Score Badge

Copy to your README.md:

[![java-decompile-mcp MCP server](https://glama.ai/mcp/servers/RuoJi6/java-decompile-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RuoJi6/java-decompile-mcp)

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