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., "@ffdecmcp Decompile the SWF at C:\Users\foo\game.swf"
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.
MCP (Model Context Protocol) wrapper for JPEXS Free Flash Decompiler (FFDec) - expose SWF decompilation and analysis tools to AI assistants like Claude.
decompile_swfDecompile all ActionScript code from a SWF file to organized directory structure.
Parameters:
swf_path (required): Absolute path to SWF file
output_dir (required): Directory for decompiled scripts
timeout (optional): Timeout in seconds (default: 60)
extract_actionscriptExtract specific ActionScript classes by name (AS3 only). Faster than full decompilation when you only need specific classes.
Parameters:
swf_path (required): Absolute path to SWF file
class_names (required): List of class names (e.g., ['com.example.Main'])
output_dir (required): Directory for extracted classes
timeout (optional): Timeout in seconds (default: 60)
list_symbolsList all ActionScript classes and symbols in a SWF file. Great for exploring a SWF before full decompilation.
Parameters:
swf_path (required): Absolute path to SWF file
Returns: Structured JSON with packages, classes, and total count
extract_assetsExtract images, sounds, fonts, shapes, movie clips, and binary data from SWF.
Parameters:
swf_path (required): Absolute path to SWF file
output_dir (required): Directory for extracted assets
asset_types (optional): Types to extract - image, sound, font, shape, movie, binaryData, all (default: ["all"])
timeout (optional): Timeout in seconds (default: 60)
get_swf_metadataExtract SWF header information (dimensions, frame rate, compression, etc.). Fast and doesn't require decompilation.
Parameters:
swf_path (required): Absolute path to SWF file
Returns: JSON with version, width, height, frame_rate, frame_count, compression
deobfuscateRun FFDec's deobfuscation algorithms to remove obfuscation and anti-decompilation tricks.
Parameters:
swf_path (required): Absolute path to obfuscated SWF
output_path (required): Path for deobfuscated SWF
level (optional): Deobfuscation level - traps, deadcode, max (default: max)
timeout (optional): Timeout in seconds (default: 60)
Related MCP server: pyghidra-mcp
Prerequisites: Python 3.10+ and Java (for running the FFDec JAR).
claude mcp add ffdecmcp -- uvx ffdecmcpThat's it. On first run, FFDec will be auto-downloaded if not already installed.
Add to your config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"ffdecmcp": {
"command": "uvx",
"args": ["ffdecmcp"]
}
}
}# Just run it - FFDec will be auto-downloaded to ~/.ffdecmcp/ if needed
uvx ffdecmcp
# Or point to an existing FFDec installation
uvx ffdecmcp --ffdec-path /path/to/ffdec.jarNo installation is required when using uvx. For a permanent install:
uv pip install ffdecmcp
# or
pip install ffdecmcpFFDec is automatically downloaded on first run if not found. You can also install it manually.
The server finds FFDec in this order:
--ffdec-path CLI arg / FFDEC_PATH env var
Previously auto-downloaded JAR (~/.ffdecmcp/ffdec.jar)
Common install locations and PATH
Auto-download from GitHub
ffdecmcp [--ffdec-path PATH] [--timeout SECONDS]Option | Env Var | Description |
|
| Path to FFDec (JAR, native binary, or WSL path) |
|
| Default timeout in seconds (default: 60) |
CLI arguments take precedence over environment variables.
git clone https://github.com/sublimnl/ffdecmcp.git
cd ffdecmcp
uv pip install -e ".[dev]"You: Can you analyze this SWF file for me?
Path: C:\Users\foo\game.swf
Claude will:
1. Use get_swf_metadata to check dimensions, version, etc.
2. Use list_symbols to see what classes are present
3. Use decompile_swf to extract all ActionScript code
4. Analyze the decompiled code and provide insightsFFDec CLI Docs: https://github.com/jindrapetrik/jpexs-decompiler/wiki/Commandline-arguments
Model Context Protocol: https://modelcontextprotocol.io
FastMCP: https://github.com/jlowin/fastmcp
MIT License - see LICENSE file for details
Contributions welcome! Please open an issue or PR on GitHub.
Decompile all ActionScript code from a SWF file.
This tool extracts and decompiles all ActionScript (AS2/AS3) code from a Flash SWF file, organizing the output into a directory structure that mirrors the package hierarchy.
Args: swf_path: Absolute path to the SWF file to decompile output_dir: Directory where decompiled scripts will be saved timeout: Optional timeout in seconds (default: 60)
Returns: Dictionary with: - success: Whether decompilation succeeded - swf_path: Input SWF file path - output_dir: Output directory path - script_count: Number of ActionScript files extracted - message: Success message
Example: >>> decompile_swf("/path/to/game.swf", "/path/to/output") { "success": true, "swf_path": "/path/to/game.swf", "output_dir": "/path/to/output", "script_count": 42, "message": "Successfully decompiled 42 ActionScript files" }
| Name | Required | Description | Default |
|---|---|---|---|
| swf_path | Yes | ||
| output_dir | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the decompilation process, output structure, and timeout option. It does not mention error handling for corrupted files, but the behavior is sufficiently clear for a read-only analysis 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 well-structured with a summary, detailed paragraph, args, returns, and an example. Every sentence is valuable and efficiently conveys necessary information.
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 presence of an output schema, the description covers inputs and outputs thoroughly, and the sibling tools are distinct. No additional context is needed for effective use.
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 0%, but the description fully explains all three parameters in the Args section, including types, purposes, and optional defaults, adding substantial meaning beyond the raw 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 decompiles all ActionScript code from a SWF file, specifying the resource, action, and output structure. It distinguishes from siblings like 'extract_assets' and 'list_symbols' by focusing on full code decompilation.
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 an example but no explicit guidance on when to use this tool versus siblings like 'extract_actionscript' or 'get_swf_metadata'. Usage context is implied but not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deobfuscate a SWF file by removing obfuscation techniques.
This tool runs FFDec's deobfuscation algorithms to remove common obfuscation techniques like dead code, traps, and other anti-decompilation tricks. The output is a cleaner SWF file that's easier to decompile and analyze.
Args: swf_path: Absolute path to the obfuscated SWF file output_path: Path where the deobfuscated SWF will be saved level: Deobfuscation level - 'traps' (remove traps only), 'deadcode' (remove dead code), 'max' (full deobfuscation, default) timeout: Optional timeout in seconds (default: 60)
Returns: Dictionary with: - success: Whether deobfuscation succeeded - input_path: Input SWF file path - output_path: Output SWF file path - level: Deobfuscation level used - message: Success message
Example: >>> deobfuscate("/path/to/obfuscated.swf", "/path/to/clean.swf", level="max") { "success": true, "input_path": "/path/to/obfuscated.swf", "output_path": "/path/to/clean.swf", "level": "max", "message": "Successfully deobfuscated SWF at level 'max'" }
| Name | Required | Description | Default |
|---|---|---|---|
| swf_path | Yes | ||
| output_path | Yes | ||
| level | No | max | |
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it runs FFDec's algorithms, removes dead code/traps/anti-decompilation tricks, and produces a cleaner SWF. It also explains the level parameter options and timeout, providing comprehensive insight into the tool's operation.
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 well-structured with sections for Args, Returns, and an Example. It is front-loaded with purpose, but the example, while helpful, adds length. Overall, it is efficient and organized, though slightly verbose.
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 absence of annotations and the presence of an output schema, the description covers the tool's behavior, parameters, return values, and provides a usage example. It lacks details on error handling, prerequisites, or performance considerations, but is sufficiently complete for a deobfuscation tool.
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 provides no descriptions (0% coverage). The description adds full meaning to each parameter: swf_path and output_path are clearly defined, level lists three allowed values with defaults, and timeout includes default. The example further clarifies usage, fully compensating for the schema's lack of documentation.
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 purpose: 'Deobfuscate a SWF file by removing obfuscation techniques.' It specifies the verb 'deobfuscate' and the resource 'SWF file', and distinguishes from sibling tools like decompile_swf or extract_actionscript by focusing on removing obfuscation rather than decompilation or extraction.
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 when a SWF file is obfuscated, but does not explicitly state when to use this tool versus alternatives. It does not mention any conditions or exclusions, leaving the agent to infer context from the tool name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract specific ActionScript classes by name from a SWF file.
This tool selectively extracts only the specified ActionScript classes (AS3 only), which is faster than full decompilation when you only need specific classes.
Args: swf_path: Absolute path to the SWF file class_names: List of fully-qualified class names to extract (e.g., ['com.example.Main', 'com.example.Utils']) output_dir: Directory where extracted classes will be saved timeout: Optional timeout in seconds (default: 60)
Returns: Dictionary with: - success: Whether extraction succeeded - swf_path: Input SWF file path - output_dir: Output directory path - requested_classes: List of requested class names - extracted_files: Number of files extracted - message: Success message
Example: >>> extract_actionscript("/path/to/game.swf", ["com.game.Main", "com.game.Player"], "/path/to/output") { "success": true, "swf_path": "/path/to/game.swf", "output_dir": "/path/to/output", "requested_classes": ["com.game.Main", "com.game.Player"], "extracted_files": 2, "message": "Successfully extracted 2 ActionScript files" }
| Name | Required | Description | Default |
|---|---|---|---|
| swf_path | Yes | ||
| class_names | Yes | ||
| output_dir | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses behavior: extracts AS3 classes only, returns structured dict with success info. Doesn't mention side effects or destruction, but as a read-like operation, it's adequate.
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?
Well-structured with Args and Returns sections and an example. Slightly verbose but front-loaded with purpose. Every section adds value.
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?
Covers all parameters, return values, and provides an example. Complex tool with 4 params and 3 required, but description fully addresses usage. Output schema exists but description still includes return details.
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 0%, but description provides detailed parameter descriptions (e.g., 'fully-qualified class names', 'optional timeout'). Adds meaning beyond schema types.
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?
Clearly states it extracts specific ActionScript classes by name from a SWF file, distinguishing it from full decompilation. The verb 'extract' and resource 'ActionScript classes' are specific and differentiate from siblings like decompile_swf.
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?
Explicitly says it's 'faster than full decompilation when you only need specific classes', which guides when to use. No explicit exclusions, but context implies when not to use (if full decompilation needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract images, sounds, fonts, and other assets from a SWF file.
This tool extracts non-code assets from a SWF file, including images, sounds, fonts, shapes, movie clips, and binary data.
Args: swf_path: Absolute path to the SWF file output_dir: Directory where extracted assets will be saved asset_types: Optional list of asset types to extract. Valid types: 'image', 'sound', 'font', 'shape', 'movie', 'binaryData', 'all' (default: ['all']) timeout: Optional timeout in seconds (default: 60)
Returns: Dictionary with: - success: Whether extraction succeeded - swf_path: Input SWF file path - output_dir: Output directory path - asset_types: List of asset types extracted - extracted_count: Number of assets extracted - message: Success message
Example: >>> extract_assets("/path/to/game.swf", "/path/to/output", asset_types=["image", "sound"]) { "success": true, "swf_path": "/path/to/game.swf", "output_dir": "/path/to/output", "asset_types": ["image", "sound"], "extracted_count": 127, "message": "Successfully extracted 127 assets" }
| Name | Required | Description | Default |
|---|---|---|---|
| swf_path | Yes | ||
| output_dir | Yes | ||
| asset_types | No | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It mentions extraction and returns a dictionary, but fails to state whether the operation is read-only, what happens on failure, or prerequisites (e.g., file existence). It does not disclose potential side effects or error conditions.
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 well-structured with a one-line summary, detailed Args/Returns, and an example. It is slightly verbose due to duplicating information that could be in the output schema, but the front-loading of the main purpose is effective.
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 functionality, inputs, and outputs, including an example. However, it lacks details on error handling, timeout behavior, and prerequisites. The default inconsistency also indicates incomplete specification.
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 description adds meaning to the schema, explaining swf_path, output_dir, asset_types (with valid values), and timeout. However, it contradicts the schema defaults: description says asset_types default ['all'] and timeout default 60, while schema shows null defaults. This inconsistency undermines clarity.
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 verb 'Extract' and the resource 'assets from a SWF file', specifying asset types (images, sounds, fonts, etc.). It distinguishes itself from sibling tools like extract_actionscript (code) and decompile_swf (full decompilation), making its purpose immediately clear.
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 does not explicitly state when to use this tool over alternatives. While it implies it is for non-code assets, it lacks guidance like 'Use this when you need assets only, not code.' The sibling tool names provide context, but the description itself falls short of clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract metadata from a SWF file's header.
This tool reads the SWF file header to extract basic metadata like dimensions, frame rate, frame count, compression type, and Flash version. This is fast and doesn't require decompilation.
Args: swf_path: Absolute path to the SWF file
Returns: Dictionary with metadata including: - success: Whether extraction succeeded - swf_path: Input SWF file path - version: Flash version number - width: Stage width in pixels - height: Stage height in pixels - frame_rate: Frames per second - frame_count: Total number of frames - compression: Compression type (e.g., 'zlib', 'lzma', 'none') - Additional header fields as available
Example: >>> get_swf_metadata("/path/to/game.swf") { "success": true, "swf_path": "/path/to/game.swf", "version": 10, "width": 800, "height": 600, "frame_rate": 30, "frame_count": 1, "compression": "zlib" }
| Name | Required | Description | Default |
|---|---|---|---|
| swf_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fully discloses the operation: reads header, no decompilation, returns metadata. It does not discuss permissions or side effects, but given the read-only nature implied, it is adequate.
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 well-structured with clear sections (description, args, returns, example). It is concise, front-loaded with purpose, and each sentence adds value.
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 low parameter count and the tool's simplicity, the description is complete. It includes return fields in the description even though no output schema is provided, ensuring the agent knows what to expect.
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 single parameter swf_path is described as 'Absolute path to the SWF file', adding meaning beyond the schema which only states type string. Schema coverage is 0%, so description fully compensates.
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 extracts metadata from a SWF file header, specifying exact fields (dimensions, frame rate, etc.). It distinguishes from sibling tools like decompile_swf by noting it is fast and doesn't require decompilation.
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 for quick metadata retrieval without decompilation, providing clear context. However, it does not explicitly state when to use this tool versus siblings or list alternatives, though the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ActionScript classes and symbols in a SWF file.
This tool provides an overview of the ActionScript structure without decompiling, showing packages, classes, and the total symbol count. Useful for exploring a SWF before full decompilation.
Args: swf_path: Absolute path to the SWF file
Returns: Dictionary with: - success: Whether listing succeeded - type: ActionScript type (AS2, AS3, or Unknown) - packages: Dictionary mapping package names to class lists - classes: Complete list of fully-qualified class names - total_symbols: Total number of classes found - message: Summary message
Example: >>> list_symbols("/path/to/game.swf") { "success": true, "type": "AS3", "packages": { "com.game": ["Main", "Player", "Enemy"], "com.game.utils": ["Vector2D", "Math"] }, "classes": ["com.game.Main", "com.game.Player", ...], "total_symbols": 5, "message": "Found 5 AS3 classes in 2 packages" }
| Name | Required | Description | Default |
|---|---|---|---|
| swf_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description thoroughly explains behavior, return format, and that it's a non-destructive read operation. Lacks mention of error conditions but is sufficient.
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?
Well-structured with header, args, returns, and example; each section adds value 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?
Fully explains the tool's purpose, single parameter, and detailed return structure; output schema exists, so no need to describe return values further.
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 only specifies type string; description adds 'Absolute path to the SWF file' and provides an example, enhancing clarity 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?
Clearly states it lists ActionScript classes and symbols without decompiling, contrasting with sibling tools like decompile_swf and extract_actionscript.
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?
Explicitly suggests using 'before full decompilation' and contrasts with siblings, but could more directly state when not to use.
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.
v0.1.2decompile_swfdeobfuscateextract_actionscriptextract_assetsget_swf_metadatalist_symbolsEach tool targets a distinct aspect of SWF analysis (metadata, symbols, deobfuscation, full decompilation, selective extraction, assets). No functional overlap, so an agent can easily choose the right tool.
Most tools follow verb_noun pattern (e.g., decompile_swf, extract_assets). Only 'deobfuscate' deviates as a single verb, but it is still clear and consistent with the domain.
6 tools cover the full SWF analysis workflow from metadata to full decompilation, well-balanced and neither sparse nor bloated.
The set covers all major SWF analysis needs: metadata, structure listing, deobfuscation, full code decompilation, selective class extraction, and asset extraction. No obvious gaps for standard reverse engineering tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sublimnl/ffdecmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
