Security-first MCP server that empowers AI agents to perform automated reverse engineering, malware analysis, forensics, vulnerability research, and SAST — powered by Radare2, YARA, LIEF, Capstone, and more.
Reversecore MCP shows significant gaps in definition quality across all five tools. While tool names follow verb-noun conventions (export_, import_, run_, detect_), descriptions are inconsistent in depth and structure. Most critically, input schemas are not directly visible in the provided source code, only tool names and descriptions are evident from the cache_tools.py and capa_tools.py file references. Parameter types (string for file_path, output_name, pack_path; enum for output_format) are inferred from the schema snippets shown, but complete JSON Schema definitions are not provided in the excerpts. Output schemas are entirely undocumented. Error handling guidance is absent. The server appears functional for reverse-engineering workflows but lacks the rigor expected in production agent toolkits.
Detect packers, protectors, and compilers using comprehensive analysis including Shannon entropy calculation, section anomaly heuristics, binary overlay inspection, deep signature matching, and PE/ELF header parsing.
Export decompilation cache for a specific binary to a JSON file. Extracts cached decompilation results from the SQLite/Redis store and saves them as a portable .rcpack file.
Import a decompilation cache from a portable .rcpack JSON file. Loads the cached results into the SQLite/Redis store, enabling fast cache hits for previously analyzed binaries.
Analyze binary capabilities using CAPA (Mandiant FLARE). CAPA identifies capabilities in executable files and provides high-level behavioral information such as encrypt data using AES, delete files, communicate via HTTP, and create persistence via registry.
Quick CAPA scan returning only high-risk capabilities. Faster than full run_capa, focuses on anti-analysis techniques, persistence mechanisms, C2 communication, data exfiltration, and impact capabilities.
Input schemas not directly visible in source code; inferred from parameter descriptions only. Cannot verify complete JSON Schema with type definitions, constraints, or descriptions for all parameters.
Output schemas completely undocumented. No structured documentation of what fields each tool returns, their types, or how downstream tools can chain results. LLMs cannot plan multi-tool workflows without knowing response structure.
No error handling guidance. Tools do not specify what errors are retryable, what the LLM should do if a binary file is not found, or how to recover from analysis failures. Error responses will be opaque.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Parameter descriptions lack precision. 'output_format' in run_capa lists three options but does not explain when to use each or what the output differences are. 'output_name' description is vague about the default naming convention.
Missing parameter constraints and validation guidance. No min/max for numeric values, no regex patterns for file paths, no explicit enum declarations for string parameters. LLMs will guess valid values.
Dependency documentation missing. Tools reference external analysis engines (CAPA, entropy analysis, signature matching) but do not document prerequisites, expected file formats, or what to do if the underlying tool is unavailable or times out.