This server provides a comprehensive, systematic 6-phase pipeline for Java JAR decompilation, reverse engineering, and de-obfuscation. Key capabilities:
Multi-Engine Decompilation: Decompile JARs using CFR, Vineflower, Fernflower, Procyon, JADX, etc., with customizable parameters and output analytics.
Decompiler Discovery: List all decompiler binaries available in the local decompiler directory.
Output Analysis: Inspect decompiled directories to count Java files, detect warning/error comments, and preview directory structure.
Candidate Evaluation & Mavenization: Quantitatively score decompiler outputs based on file count, compilation errors, leftover .class files, and warnings; select the best candidate, and scaffold it into a Maven project with a generated pom.xml.
Compilation: Run mvn clean compile on the Maven project, capturing and formatting compilation errors for human review.
ASM Bytecode Comparison: Compare the recompiled output against the original JAR using ASM to produce File/Bytecode Match %, Business Context Similarity %, and Code Readability Score.
AST-Based Obfuscation Detection: Parse Java sources with GumTree Spoon AST diff to identify obfuscated variable/method names (e.g., synthetic identifiers, single-letter names) and infer meaningful replacements from declared types.
Variable Renaming: Apply rename operations across all source files, adding changelog comments, without modifying business logic.
Full De-obfuscation Pipeline: Execute an end-to-end workflow that copies sources, compiles, detects obfuscations, renames, verifies compilation, and confirms zero remaining obfuscations.
Fallback for Missing Logic: Automatically swap files from an alternative decompiler candidate when bytecode similarity is below a threshold, retaining only swaps that compile and improve similarity.
Guided Workflows: Predefined prompts support common tasks like mavenization, fixing compilation errors, bytecode comparison, variable renaming, and full de-obfuscation.
Allows structuring decompiled Java sources into Maven projects and compiling them with Maven, including compilation error analysis.
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 JAR Decompiler & Reverse Engineering MCP Server Decompile the target JAR and show me the best source code candidate."
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.
A production-ready Model Context Protocol (MCP) server written in Node.js for Java .jar package decompilation, multi-engine candidate benchmark evaluation, Maven project structuring, non-breaking syntax repair, GumTree Spoon AST analysis & obfuscation renaming, ASM bytecode parity metrics evaluation, and Generic Differential Logic Fallback.
Related MCP server: Java Inspector
Version 1.1.0 introduces major enhancements to AST de-obfuscation, type inference, dynamic pipeline execution, and non-overfitted post-compilation logic fallbacks:
Generic Post-Compilation Differential Logic Fallback (fallback_to_candidate_for_missing_logic):
Added a new, 100% generic tool that evaluates post-compilation Business Logic Similarity using ASM bytecode analysis.
If similarity falls below a target threshold (e.g. < 98.0%), the tool performs a differential file scan against alternative candidate decompiler outputs (e.g. CFR vs Vineflower).
Swaps candidate files, tests mvn clean compile, measures ASM bytecode similarity improvement, and retains file swaps ONLY if compilation succeeds AND the business logic similarity score increases. Completely avoids hardcoded class/variable names.
Automatic Type Extraction & Contextual Name Inference (inferMeaningfulName):
generate_ast_and_detect_obfuscation now captures the declared Java Type (declaredType) for every obfuscated identifier (var1, var2, arg0, val$x).
Automatically infers domain-meaningful replacement names (suggestedNewName) based on declared type and line context (e.g., ErrorHandler $\rightarrow$ errorHandler, LogEvent $\rightarrow$ event, Throwable $\rightarrow$ throwable, long $\rightarrow$ minLastModified).
Dynamic AST Rename Pipeline (run_ast_deobfuscation_pipeline):
Replaced static/hardcoded rename mapping arrays with dynamic, on-the-fly AST mappings generated directly from AST type inference.
Added flexible directory scanning for both root-level decompiled outputs and Maven src/main/java projects.
Deduplication & Flexible Path Resolution:
Deduplicates AST obfuscation detections by (file, line, variableName).
Updated rename_obfuscated_variables path resolution to check both src/main/java/ relative and root-relative file paths.
For every target Java .jar package, the MCP server executes a systematic 6-phase pipeline:
āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā
ā Phase 1: ā ā Phase 2: ā ā Phase 3: ā ā Phase 4: ā ā Phase 5: ā ā Phase 6: ā
ā Multi-Engine āāāā>ā Quantitative āāāā>ā Mavenization āāāā>ā Non-Breaking āāāā>ā AST De- āāāā>ā ASM Bytecode ā
ā Decompilation ā ā Evaluation ā ā & Structure ā ā Syntax Repair ā ā Obfuscation ā ā Comparison ā
āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāāPhase 1: Multi-Engine Decompilation (decompile_jar)
Decompile target JAR using multiple engine variants (CFR 0.152, Vineflower 1.12.0, Fernflower, Procyon, JADX) into isolated output directories.
Phase 2: Comparative Candidate Evaluation (evaluate_and_mavenize_sources)
Test-compile each candidate output using javac -g -parameters -proc:none -encoding UTF-8.
Calculate quantitative quality score based on Java source count, compiler error count, remaining .class files, and inline warning comments.
Phase 3: Maven Project Structuring (evaluate_and_mavenize_sources)
Copy winning candidate sources to src/main/java and resources to src/main/resources.
Generate production-ready pom.xml with source/target compliance and compiler args (-g -parameters).
Phase 4: Non-Breaking Syntax Repair (compile_maven_project & fix_compilation_errors_prompt)
Fix compilation errors reported in logs without modifying business logic (type casting, generic inference, sneaky throw casts, synthetic package-info artifacts).
Phase 5: AST Obfuscation Detection & Refactoring (run_ast_deobfuscation_pipeline)
Parse Abstract Syntax Tree using GumTree Spoon AST Diff (gumtree-spoon-ast-diff-1.124.jar).
Detect obfuscated/synthetic variable and method identifiers (var0, var1, arg0, closure captures, single-letter variables).
Apply context-aware, domain-accurate renames across files without altering functional behavior.
Re-compile and re-scan AST to confirm 0 obfuscations remain.
Phase 6: ASM Bytecode Parity & Metrics Analysis (compare_bytecode_and_analyze)
Perform ASM bytecode comparison against original JAR.
Record metrics: File/Bytecode Match %, Business Context Similarity %, and Code Readability Score in log reports.
The evaluate_and_mavenize_sources tool selects the optimal decompiled candidate engine using a quantitative multi-factor scoring formula:
$$\text{Score} = (\text{JavaFiles} \times 100) - (\text{JavacErrors} \times 200) - (\text{RemainingClassFiles} \times 50) - (\text{DecompilerWarnings} \times 10)$$
Compilation Pass Rate under Debug Flags (Weight: -200 per error):
Each candidate is test-compiled using:
javac -g -parameters -proc:none -encoding UTF-8Rationale: Penalizes engines that emit invalid syntax, generic type inference failures, or broken lambdas. Zero compilation errors provides a massive score advantage.
AST Source Coverage (Weight: +100 per .java file):
Counts total .java source files successfully reconstructed.
Rationale: Rewards decompilers that fully reconstruct class structures, inner classes, and interface hierarchies without dropping files.
Unhandled Bytecode / Remaining .class Files (Weight: -50 per .class file):
Counts .class binary files left behind in output directory.
Rationale: Severe penalty for decompiler engines that fail on complex bytecode constructs (e.g., Kotlin synthetic bridges, inner classes) and leave un-decompiled .class files.
Inline Decompiler Warning Comments (Weight: -10 per warning):
Scans top 150 lines of every .java file for issue markers:
// FAILED to decompile method ...
// Could not decompile ...
// Exception decompiling ...
/* Synthetic */
Rationale: Penalizes engines that emit partial method stubs or swallow exceptions inline.
server/
āāā bin/
ā āāā cli.js # Executable CLI entry point for NPX / global execution
āāā src/
ā āāā index.js # Main MCP server initialization & handler registration
ā āāā decompilerHandler.js # Core decompiler execution, Maven build, AST, & ASM engine
ā āāā tools/
ā ā āāā definitions.js # Structured MCP Tool declarations & JSON schemas (9 tools)
ā āāā prompts/
ā āāā definitions.js # Structured MCP Prompt declarations & templates (5 prompts)
āāā scripts/ # Utility helper scripts
āāā index.js # Forwarding entrypoint (imports src/index.js)
āāā package.json # Package manifest & configuration
āāā README.md # Server documentationNode.js: v18.0.0 or higher
Java Development Kit (JDK): JDK 8 / JDK 17 / JDK 24 (configured in JAVA_HOME or path)
Apache Maven: mvn CLI installed and available in environment path
cd server
npm installAdd the server entry to your claude_desktop_config.json:
{
"mcpServers": {
"jar-decompiler": {
"command": "node",
"args": [
"C:/Users/ghosh/OneDrive/Desktop/Decompilation/server/index.js"
]
}
}
}Add the server entry to your .gemini/antigravity-cli/mcp_config.json:
{
"mcpServers": {
"jar-decompiler": {
"command": "node",
"args": [
"C:/Users/ghosh/OneDrive/Desktop/Decompilation/server/index.js"
]
}
}
}decompile_jarDecompiles a Java .jar file into a target directory and returns comprehensive decompilation analytics, tree output, and logs.
Parameters:
jarPath (string, required): Path to .jar file.
outputDir (string, optional): Destination directory.
decompilerPath (string, optional): Explicit path to decompiler .jar.
decompilerType (string, optional): 'auto', 'cfr', 'vineflower', 'fernflower', 'procyon', 'jadx', or 'generic'.
extraArgs (array of strings, optional): Additional command-line flags.
list_decompilersLists all Java decompiler files (.jar or executables) currently found in the decompiler/ folder.
Parameters:
decompilerDir (string, optional): Path to decompiler folder.
analyze_decompilation_outputAnalyzes an existing directory containing decompiled source code to count Java files, detect decompilation warnings/errors, and produce a directory tree preview.
Parameters:
outputDir (string, required): Path to decompiled directory.
evaluate_and_mavenize_sourcesEvaluates decompiled outputs (comparing AST structure, line count, compiler warning count), chooses the optimal candidate using the quantitative scoring model, and structures it into a clean Maven project with pom.xml.
Parameters:
outputsDir (string, required): Path to directory containing candidate folders (e.g. outputs/).
targetMavenDir (string, required): Path to target directory (e.g. mavenized_merged_source/).
groupId (string, optional): Maven groupId (default: org.apache.commons).
artifactId (string, optional): Maven artifactId (default: commons-io).
version (string, optional): Maven version (default: 2.22.0).
compile_maven_projectCompiles a Maven project using mvn clean compile, parses compilation errors into a human-readable format, and writes the log file.
Parameters:
projectDir (string, required): Path to Maven project root.
logPath (string, optional): Path for compilation error log file.
compare_bytecode_and_analyzePerforms ASM bytecode analysis comparing the original JAR against the recompiled mavenized source, outputting percentage match, business context similarity, and variable readability scores.
Parameters:
originalJarPath (string, optional): Path to original JAR.
mavenDir (string, optional): Path to mavenized project root.
logPath (string, optional): Path to output comparison report.
asmJarPath (string, optional): Path to ASM library JAR.
generate_ast_and_detect_obfuscationUses GumTree Spoon AST Diff to parse Java source files, generate AST representations, and detect obfuscated or synthetic variable/method names (var0, arg1, single-letter variables, closure captures).
Parameters:
sourceDir (string, optional): Path to Java source directory.
gumtreeJarPath (string, optional): Path to GumTree Spoon JAR.
logPath (string, optional): Path to output obfuscation report.
rename_obfuscated_variablesCopies mavenized source to final output directory, applies obfuscated variable renames with meaningful names, adds changelog comments to modified files, and generates a comprehensive rename log. NEVER modifies business logic.
Parameters:
renames (array of objects, required): Array of { file, oldName, newName, line }.
sourceDir (string, optional): Source directory.
targetDir (string, optional): Target output directory.
logPath (string, optional): Output log file path.
run_ast_deobfuscation_pipelineRuns the complete end-to-end AST de-obfuscation pipeline: copies mavenized_merged_source to mavenized_final_output, compiles, parses AST via GumTree Spoon to find obfuscated vars/methods, applies context-aware renames without changing business logic, verifies compilation, re-scans AST, and outputs logs to logs/ast_renamed_variables_methods.txt.
Parameters:
sourceDir (string, optional): Source directory.
targetDir (string, optional): Target output directory.
gumtreeJarPath (string, optional): GumTree Spoon JAR path.
logPath (string, optional): Output report log file path.
renames (array of objects, optional): Custom rename entries array.
fallback_to_candidate_for_missing_logicGeneric post-compilation differential fallback. If ASM business logic similarity is below targetSimilarityThreshold (e.g. 98%), scans alternative decompiler candidate outputs (e.g. CFR), performs differential file swapping, tests compilation, and retains swaps only if business logic parity improves.
Parameters:
targetMavenDir (string, optional): Path to target mavenized project (default: mavenized_final_output).
candidateDir (string, optional): Path to fallback candidate output directory (default: outputs/avalon-logkit-2.1_cfr).
originalJarPath (string, optional): Path to original target JAR file for ASM parity analysis.
targetSimilarityThreshold (number, optional): Target Business Logic Similarity threshold percentage (default: 98.0).
logPath (string, optional): Output report log file path (default: logs/generic_logic_fallback_report.txt).
evaluate_and_mavenize_promptSystem prompt for comparing decompiled AST outputs, selecting the optimal candidate with minimal code loss, and mavenizing it.
Arguments: outputsDir, targetMavenDir
fix_compilation_errors_promptMandatory system prompt for fixing Java compilation errors without modifying business logic (syntax, generic, and type-cast fixes only).
Arguments: logFile, projectDir
compare_bytecode_promptSystem prompt for running ASM bytecode comparisons between the original JAR and recompiled mavenized project, calculating similarity metrics and debug readability scores.
Arguments: originalJarPath, mavenDir, logPath
rename_obfuscated_variables_promptSystem prompt for AST-based detection and renaming of obfuscated/synthetic variable names in decompiled Java source, preserving all business logic.
Arguments: sourceDir, targetDir, logPath
reverse_engineering_pipeline_promptSystem prompt to execute the complete reverse engineering pipeline: dual decompilation (CFR/Vineflower), metric-based evaluation, mavenization, incremental compilation, and bytecode comparison.
Arguments: jarPath, cfrOutputDir, vineflowerOutputDir, mavenDir
ast_deobfuscation_pipeline_promptComprehensive system prompt for copying source to final output, compiling baseline, building GumTree Spoon AST, detecting obfuscated vars/methods, applying context-aware renames, verifying build success, and writing log files.
Arguments: sourceDir, targetDir, logPath
Run syntax checks across all server modules:
node --check index.js; node --check src/index.js; node --check src/decompilerHandler.js; node --check src/tools/definitions.js; node --check src/prompts/definitions.js; node --check bin/cli.jsExpected Output: Exit code 0 (clean pass).
Analyzes an existing directory containing decompiled source code to count Java files, detect decompilation warnings/errors, and produce a directory tree.
| Name | Required | Description | Default |
|---|---|---|---|
| outputDir | Yes | Path to the directory containing decompiled code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the main actions (count, detect, produce tree) but does not mention side effects, directory requirements (e.g., existence, permissions), output format, or error handling. The word 'existing' hints at a read-only nature, but this is not explicit.
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, well-structured sentence that front-loads the purpose and lists the deliverables without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter analysis tool, this description covers the core functionality adequately. However, it omits details such as how results are returned (console vs. file), potential failure modes, and whether it recursively scans subdirectories. These are not critical for basic use but would improve completeness.
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 coverage is 100%, so the parameter is already well-documented (path to directory). The description adds minimal extra meaning by emphasizing 'existing' and 'decompiled', but this does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Analyzes an existing directory') and its specific outputs (count Java files, detect warnings/errors, produce directory tree). It distinguishes itself from sibling tools like decompile_jar (which creates the directory) and evaluate_and_mavenize_sources (which builds on the analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: after decompilation, on an existing directory of decompiled code. It does not explicitly name alternatives or exclusions, but the 'existing directory containing decompiled source code' gives clear context that this is a post-processing step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs ASM bytecode analysis comparing the original JAR against the recompiled mavenized source, outputting percentage match, business context similarity, and variable readability scores into a text log.
| Name | Required | Description | Default |
|---|---|---|---|
| logPath | No | Path to output comparison report file. Defaults to logs/bytecode_comparision.txt. | |
| mavenDir | No | Path to the mavenized project directory. Defaults to mavenized_merged_source. | |
| asmJarPath | No | Path to ASM library JAR file. Defaults to asm-bytecode-analysis/asm-9.10.1.jar. | |
| originalJarPath | No | Path to the original JAR file. Defaults to targeted-jars/commons-io-2.22.0.jar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions outputting to a text log and the types of scores, but it does not state whether the tool creates or overwrites files, or if any side effects occur. The description lacks details about resource usage, error handling, or required permissions, leaving uncertainty for an agent.
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, information-dense sentence with no filler. It front-loads the core action (ASM bytecode analysis) and lists all key output metrics. Every clause earns its place, making it both concise and structured.
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?
The description covers the core purpose and output sufficiently, mentioning the comparison targets and the scores written to a text log. With no output schema, it explains what the tool produces. However, it could benefit from explicitly stating the relationship to prior steps (e.g., mavenization/recompilation) and any prerequisites, but given the schema defaults and clear behavior, it is largely complete.
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 fully describes all four parameters with defaults (logPath, mavenDir, asmJarPath, originalJarPath), achieving 100% schema coverage. The description provides no additional parameter-specific semantics, so the baseline of 3 is appropriate since the schema already carries the detail.
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 function: 'Performs ASM bytecode analysis comparing the original JAR against the recompiled mavenized source' and specifies the exact outputs (percentage match, business context similarity, variable readability scores). This specific verb+resource combination distinguishes it from siblings like 'analyze_decompilation_output' which focuses on decompilation rather than bytecode comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after the mavenized source has been recompiled, as it compares the original JAR against the recompiled source. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The context is clear but not directly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compiles a Maven project using mvn clean compile, parses any compilation errors into a human-readable format, and writes the log file.
| Name | Required | Description | Default |
|---|---|---|---|
| logPath | No | Optional path to write the formatted compilation error log file. Defaults to logs/merged_source_errors_log.txt. | |
| projectDir | Yes | Path to the mavenized project root directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavior. It transparently specifies the command, error parsing, and log writing. However, it does not disclose that 'clean' removes existing build artifacts or that Maven may download dependencies, which are notable side effects for a build tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the primary action ('Compiles a Maven project') and lists subsequent steps, with no wasted words.
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?
The description covers the tool's main actions and side effects (writing a log), but lacks information about return values or when to use it in the pipeline. Given no output schema and no annotations, this is a noticeable gap, though the tool's core function is clear.
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 already provides complete descriptions for both parameters (projectDir and logPath), covering 100% of the schema. The description adds no extra parameter semantics, so the baseline score of 3 is appropriate.
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 compiles a Maven project using a specific command ('mvn clean compile') and parses errors. This distinguishes it from sibling tools focused on decompilation, AST analysis, and obfuscation, making its purpose unambiguous.
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 relative to alternatives, such as after mavenizing sources or before comparing bytecode. It also omits prerequisites like Maven installation or that the project must already be mavenized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decompiles a Java .jar file into a target directory and returns comprehensive decompilation analytics, tree output, and logs.
| Name | Required | Description | Default |
|---|---|---|---|
| jarPath | Yes | Absolute or relative path to the Java .jar file to decompile. | |
| extraArgs | No | Optional additional command-line arguments to pass directly to the decompiler engine. | |
| outputDir | No | Optional output directory path for decompiled source files. Defaults to decompiled-output/<jar_name>_<timestamp>. | |
| decompilerPath | No | Optional explicit path to the decompiler binary or .jar (e.g., decompiler/cfr.jar). If omitted, automatically detects decompilers in decompiler/. | |
| decompilerType | No | Decompiler engine type. Defaults to "auto" which detects based on filename. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions a side effect (writing to a target directory) and specifies that it returns analytics, tree output, and logs. However, it omits details about overwrite behavior, required permissions, or the nature of the analytics/logs. It provides some transparency but not comprehensive.
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, well-structured sentence that immediately states the primary action and key outputs. It is concise, front-loaded, and contains no irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description does a good job indicating what is returned (analytics, tree output, logs). It omits some operational details like decompiler auto-detection and default output directory behavior, but these are covered in the schema. Given the tool's complexity, the description provides a solid, complete enough overview.
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 already provides descriptions for all five parameters, giving 100% coverage. The description does not add detail about parameter syntax or relationships beyond the schema, so the baseline score of 3 is appropriate.
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 ('Decompiles a Java .jar file'), the resource ('.jar file'), and the destination ('into a target directory'). It also differentiates from sibling tools by specifying it produces analytics, tree output, and logs, which is unique compared to compilation or analysis tools.
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 explicit guidance on when to use this tool versus alternatives. It does not mention situations where a sibling tool (e.g., analyze_decompilation_output) would be more appropriate, nor does it state prerequisites or exclusions. The usage context is only implied by the tool name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluates decompiled outputs (comparing AST structure, line count, compiler warning count), chooses the best candidate with minimal code loss, and structures it into a clean Maven project with pom.xml.
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | No | Maven groupId. Defaults to org.apache.commons. | |
| version | No | Maven artifact version. Defaults to 2.22.0. | |
| artifactId | No | Maven artifactId. Defaults to commons-io. | |
| outputsDir | Yes | Path to the directory containing candidate decompiled output folders (e.g. outputs/). | |
| targetMavenDir | Yes | Path to target directory where the chosen source will be mavenized (e.g. mavenized_merged_source/). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the evaluation criteria and the creation of a Maven project with pom.xml. However, it does not mention potential side effects like overwriting files in targetMavenDir or whether the original decompiled outputs are modified, leaving some ambiguity for an agent.
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, well-structured sentence that efficiently conveys the tool's multi-step process without redundancy. It front-loads the primary action 'Evaluates' and uses specific criteria, making it clear and compact.
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 tool's complexity and lack of an output schema, the description covers the core evaluation and mavenization steps, including the pom.xml output. It omits return value details and overwrite behavior, but these are minor gaps in a pipeline context where the primary purpose is well communicated.
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?
All five parameters are fully described in the schema (100% coverage), so a baseline of 3 is appropriate. The description adds little beyond the schema, as it merely references 'outputsDir' and 'targetMavenDir' without explaining parameter nuances or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: evaluating decompiled outputs against AST structure, line count, and compiler warnings, selecting the best candidate, and structuring it into a Maven project. This distinctively separates it from sibling tools like analyze_decompilation_output and compile_maven_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after decompilation when multiple candidate outputs exist, and it produces a Maven project. It provides clear context but does not explicitly state when not to use it or name alternative tools for similar evaluation/selection tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uses GumTree Spoon AST Diff to parse Java source files, generate AST representations, and detect obfuscated or synthetic variable names (e.g., var0, arg1, single-letter, closure captures).
| Name | Required | Description | Default |
|---|---|---|---|
| logPath | No | Path to output the obfuscation detection report. Defaults to logs/ast_obfuscation_detection.txt. | |
| sourceDir | No | Path to the Java source directory to analyze. Defaults to mavenized_merged_source/src/main/java. | |
| gumtreeJarPath | No | Path to the GumTree Spoon AST Diff JAR. Defaults to gumtree-ast-diff/gumtree-spoon-ast-diff-1.124.jar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose that a report is written to logPath, whether the tool is read-only, or what the output format is. The mention of generating ASTs is vague about side effects.
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?
A single, information-dense sentence with no filler. It front-loads the key action and gives specific examples, earning its place without 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?
With no output schema and no annotations, the description should explain return values and side effects. It does not mention that the tool produces a report file (logPath), nor does it integrate with the pipeline context of sibling tools, leaving significant gaps for an agent.
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 coverage is 100%, so the baseline is 3. The description adds context for gumtreeJarPath by naming GumTree Spoon AST Diff, but does not explain logPath behavior beyond the schema. It provides marginal added value.
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 parses Java source files, generates ASTs, and detects obfuscated variable names with concrete examples. This distinguishes it from siblings like rename_obfuscated_variables and run_ast_deobfuscation_pipeline.
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 purpose implies when to use (for detecting obfuscation in Java sources), but it lacks explicit guidance on when to use this tool versus alternatives like analyze_decompilation_output or compare_bytecode_and_analyze. No exclusions or preferred order is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all Java decompiler files (.jar or executables) currently found in the decompiler folder.
| Name | Required | Description | Default |
|---|---|---|---|
| decompilerDir | No | Optional path to the decompiler folder. Defaults to the decompiler/ directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states files are 'currently found,' implying a dynamic snapshot, but it does not disclose whether paths are relative or absolute, how subdirectories are handled, sorting order, or behavior when the folder is missing or empty.
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, front-loaded sentence that directly states the action and resource. Every word earns its place, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter, the description covers the basic purpose, but it lacks explicit output format details (e.g., returns file names, full paths, or a structured list). Since no output schema exists, the description could clarify what the agent should expect as a return value.
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%, and the parameter decompilerDir is fully described with its optional nature and default value. The description reinforces this by mentioning the folder context, but adds no additional meaning beyond what the schema already provides.
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 uses the specific verb 'Lists' and clearly identifies the resource as 'Java decompiler files (.jar or executables) in the decompiler folder.' This distinguishes the tool from sibling tools like decompile_jar or analyze_decompilation_output, which perform different actions on decompilers.
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?
No guidance is provided for when to use this tool versus alternatives. The description only states what the tool does, without mentioning any exclusions or contextual triggers that would help an agent decide between list_decompilers and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copies mavenized source to final output directory, applies obfuscated variable renames with meaningful names, adds changelog comments to modified files, and generates a comprehensive rename log. NEVER modifies business logic.
| Name | Required | Description | Default |
|---|---|---|---|
| logPath | No | Path to output the rename changelog. Defaults to logs/variable_rename_changelog.txt. | |
| renames | Yes | Array of rename operations. Each entry: { file: "relative/path.java", oldName: "var1", newName: "testCount", line: 42 }. | |
| sourceDir | No | Path to the source mavenized project to copy from. Defaults to mavenized_merged_source. | |
| targetDir | No | Path to the target output directory. Defaults to mavenized_final_output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behaviors: it copies source (not in-place), applies renames, adds changelog comments, and generates a log. The explicit 'NEVER modifies business logic' provides a strong safety guarantee. However, it does not mention potential overwriting of target files, error handling, or edge cases such as missing line numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary actions, and includes a concise safety warning. Every word earns its place; no fluff 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?
The description covers the main workflow and side effects (copy, rename, comment, log) and includes a critical safety constraint. Lacking an output schema, it doesn't describe return values, but it mentions the rename log as an artifact. It could benefit from explicitly stating prerequisites (e.g., source must be mavenized) and relationship to sibling tools, but overall is sufficiently complete for a specialized operation.
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 the schema fully documents all parameters including the renames array structure, sourceDir, targetDir, and logPath. The tool description adds no parameter-specific details, remaining at the baseline of 3.
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 function with specific verbs: copies mavenized source, applies obfuscated variable renames, adds changelog comments, and generates a rename log. This distinguishes it from sibling tools like decompile_jar or compile_maven_project, which focus on different pipeline stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage within a deobfuscation pipeline ('Copies mavenized source') but does not explicitly state when to use this tool over alternatives or provide exclusions. It notes 'NEVER modifies business logic,' which hints at safe usage, but lacks explicit guidance like 'use this after mavenization' or 'prefer run_ast_deobfuscation_pipeline for full handling.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the complete end-to-end AST de-obfuscation pipeline: copies mavenized_merged_source to mavenized_final_output, compiles, parses AST via GumTree Spoon to find obfuscated vars/methods, applies context-aware renames without changing business logic, verifies compilation, re-scans AST, and outputs logs to logs/ast_renamed_variables_methods.txt.
| Name | Required | Description | Default |
|---|---|---|---|
| logPath | No | Path to output the comprehensive AST rename report log. Defaults to logs/ast_renamed_variables_methods.txt. | |
| renames | No | Optional custom rename entries array. If omitted, uses default AST-analyzed renames. | |
| sourceDir | No | Path to source mavenized project directory. Defaults to mavenized_merged_source. | |
| targetDir | No | Path to target final output directory. Defaults to mavenized_final_output. | |
| gumtreeJarPath | No | Path to GumTree Spoon AST Diff JAR. Defaults to gumtree-ast-diff/gumtree-spoon-ast-diff-1.124.jar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the pipeline steps and states that renames occur 'without changing business logic', which is a safety property. It also mentions the output log path. However, it doesn't cover potential side effects like overwriting the target directory or failure behavior. Given no annotations, this is reasonable transparency.
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 long sentence but front-loads the purpose and enumerates steps efficiently. It is not overly verbose, though it could be improved with bullet points for better readability.
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?
This is a complex tool with 5 parameters and no output schema. The description covers the pipeline flow and the log output, but does not describe the function's return value or how success is indicated. More detail on the return/output would enhance completeness.
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 already provides descriptions for all 5 parameters (100% coverage). The tool description adds no extra parameter-specific details, such as how the optional 'renames' array interacts with default detection. Baseline score of 3 is appropriate.
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 runs the complete end-to-end AST deobfuscation pipeline, listing specific steps (copy, compile, parse, rename, verify, re-scan). This distinguishes it from sibling tools that handle individual steps like generate_ast_and_detect_obfuscation or rename_obfuscated_variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for full end-to-end deobfuscation but does not explicitly state when to use it over individual steps. No alternatives or exclusions are mentioned, though 'complete end-to-end' hints at its comprehensive nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyze_decompilation_outputcompare_bytecode_and_analyzecompile_maven_projectdecompile_jarevaluate_and_mavenize_sourcesgenerate_ast_and_detect_obfuscationlist_decompilersrename_obfuscated_variablesrun_ast_deobfuscation_pipelineEach tool targets a distinct stage of the decompilation workflow (decompile, list, analyze, AST, mavenize, compile, compare, rename, pipeline). Despite some conceptual overlap between standalone tools and the pipeline, the descriptions clearly differentiate their scope and usage.
All tool names follow a consistent snake_case verb_noun pattern (e.g., decompile_jar, list_decompilers, compile_maven_project). The naming style is uniform and predictable across the entire set.
9 tools is well-scoped for a decompilation and reverse engineering server, covering each necessary step without being excessive. The count falls comfortably within the ideal 3-15 range.
The tool surface covers the full reverse engineering lifecycle: decompile, analyze, generate AST, mavenize, compile, compare, and rename. No obvious gaps hinder the core workflow, and the pipeline tool provides an end-to-end path.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ship better Java with your coding agent.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
MCP server for static security analysis of Android source code
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sapyyy/reverse-engineering-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
