Loading ToolBench
MCP server for using the REMnux malware analysis toolkit via AI assistants
REMnux MCP server demonstrates strong overall definition quality with comprehensive tool coverage for malware analysis. Most tools have clear, action-verb naming and non-empty descriptions. Input schemas are present and mostly well-structured with type definitions and parameter descriptions. However, several tools show incomplete output schema documentation and some parameter descriptions lack actionable detail. The server follows good composition practices with specialized tools and clear tool chaining (e.g., list_files → run_tool). Error handling is present but recovery guidance is minimal in some tools. Security considerations are addressed via tool selection (READ_ONLY vs WRITE annotations) but not explicitly in descriptions.
Performs comprehensive malware analysis on a file by running multiple tools in sequence at varying depth levels (quick, standard, or deep) and summarizing findings
Verifies whether a binary contains capability indicators required to execute a specified behavior (e.g., clipboard hijacking, C2 communication, persistence)
Verifies which malware analysis tools are installed on the REMnux system by checking command availability via 'which'
Downloads a file from the output directory to the host machine, optionally wrapped in a password-protected ZIP archive
Downloads a file from a URL (HTTP/HTTPS) into the samples directory using curl or thug (with JavaScript execution)
Extracts files from archives (ZIP, 7Z, RAR, TAR, GZIP, BZIP2, XZ) with optional password support and common password list
Extracts indicators of compromise (IOCs) such as hashes, IP addresses, domains, and URLs from text output
run_tool description is 431 characters but lacks actionable constraint details on output truncation behavior, the truncation_notice field is mentioned but not clearly linked to what triggers it or how LLM should handle it. Should clarify truncation threshold (102,400 chars) upfront and specify recovery actions.
download_from_url 'method' parameter description does not explain consequences of each option or when to use 'thug' vs 'curl', LLM must infer this from names alone, inviting wrong selection. Should state: 'curl' for static content, 'thug' for sites requiring JavaScript/DOM interaction.
Output schema documentation missing or incomplete for several tools (analyze_file, extract_archive, get_report_guidance, get_osint_guidance). Without documented output structure, LLMs cannot reliably parse results or plan downstream tool calls. Each tool should document returned fields, types, and structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Retrieves detailed file information including size, modification time, and MIME type for a file in the samples directory
Returns OPSEC tradecraft, IOC lookup workflows, and a catalog of free/paid OSINT resources organized by indicator type
Returns writing guidelines, confidence levels, capability frameworks, and anti-patterns for malware analysis reports
Returns a markdown template for malware analysis reports with section structure and guidance
Reports the MCP server version, connector mode (docker/ssh/local), transport type, and REMnux distro version
Retrieves help documentation for a specified malware analysis tool by running its --help or -h flag
Lists files in the samples or output directory
Executes a malware analysis tool command with support for pipes, input files, and output capture up to 100 KiB
Recommends appropriate REMnux malware analysis tools based on the file type of the sample being analyzed
Uploads a file from the host machine running the MCP server into the samples directory
Locates a string in a binary and cross-references it against decompiled code to verify if it is actually used or just data
Error handling descriptions missing or vague across most tools. No guidance on how LLM should recover from common failures (timeout, archive password required, tool not found, file not found). Should include recovery steps: 'If tool not found, call check_tools() first. If timeout, increase timeout_per_tool parameter or use depth=quick.'
get_report_guidance and get_osint_guidance 'topic' enums have 7+ values but descriptions do not explain the semantic difference between similar options (e.g., 'writing' vs 'frameworks' vs 'profiles'). LLM must guess intent. Should add guidance like: 'Use writing for report structure, frameworks for TTPs/MITRE, profiles for actor/family context.'
check_behavior_prerequisites 'behavior' parameter description lists 13 behavior values inline but does not explain what each means or when to use each. Should brief: 'clipboard_hijacking: read/write clipboard. http_c2_wininet: HTTP command & control. registry_persistence_run: RunKey persistence. etc.' Current format requires LLM to parse and guess semantic intent.
Parameter descriptions for upload_from_host and download_file lack clarity on path resolution and sandbox rules. upload_from_host description mentions --sandbox mode and --ingest-root but does not explain what happens if path is outside sandbox, or how agent should form paths when sandbox is active. Should state: 'Resolved path must be inside ingest_root when --sandbox is enabled; outside sandbox, accepts any readable path. Relative paths are relative to server working directory.'
Tool composition: analyze_file + get_report_template + get_report_guidance form a multi-step guidance workflow, but descriptions do not hint at the typical sequence or when to call each. Should add: 'For structured reporting: (1) analyze_file to gather findings, (2) get_report_template for structure, (3) get_report_guidance for confidence rules and anti-patterns.'
Security risk annotation (READ_ONLY vs WRITE) is present but not formally documented in tool descriptions. Descriptions do not explicitly state whether a tool modifies state, can be retried safely, or has irreversible consequences. Should add: 'READ_ONLY: safe to retry. WRITE: modifies state, retry only if error indicates incomplete execution (not user-visible).'