Java JAR Decompiler & Reverse Engineering MCP Server

by sapyyy

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
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 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
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 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

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

reverse-engineering-mcp-server MCP server

Copy to your README.md:

[![reverse-engineering-mcp-server MCP server](https://glama.ai/mcp/servers/sapyyy/reverse-engineering-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/sapyyy/reverse-engineering-mcp-server)

Score Badge

Copy to your README.md:

[![reverse-engineering-mcp-server MCP server](https://glama.ai/mcp/servers/sapyyy/reverse-engineering-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/sapyyy/reverse-engineering-mcp-server)

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/sapyyy/reverse-engineering-mcp-server'

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