F
licenseNot graded
qualityD
maintenanceAn MCP server that allows AI assistants like Claude to execute terminal commands on the user's computer and return the output, functioning like a terminal through AI.
89
-
MalwareAnalyzerMCP
The MalwareAnalyzerMCP server provides tools for executing terminal commands and performing specialized malware analysis on files:
Execute terminal commands with configurable timeouts and manage processes
Read output from running or completed processes by their ID
Analyze files using specialized malware analysis tools:
file: Identify file typesstrings: Extract printable strings with configurable encoding and minimum lengthhexdump: Display file contents in hexadecimal format with options for length and offsetobjdump: Disassemble and analyze object files, show headersxxd: Create hexdumps with ASCII representation and column formatting
Integrate with Claude Desktop for seamless malware analysis workflows
Offers a Node.js-based implementation for malware analysis capabilities, requiring Node.js 18 or higher with compatibility for Node.js v22+ using ESM modules.
Provides a secure interface to execute terminal commands with configurable timeouts and process management for malware analysis tasks.
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., "@MalwareAnalyzerMCPanalyze suspicious.exe with strings and show me any URLs found"
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.
MalwareAnalyzerMCP
A specialized MCP server for Claude Desktop that allows executing terminal commands for malware analysis.
Features
Execute terminal commands with configurable timeouts
Read output from running or completed processes
Specialized malware analysis commands (
file,strings,hexdump,objdump,xxd)Clean process management with graceful shutdowns
Pure JavaScript implementation - no build step required
Related MCP server: Desktop Commander MCP
Installation
# Install dependencies
npm installUsage
Running the Server
# Start the server directly
node index.js
# Or use npm script
npm start
# With debugging proxy (logs all communications)
npm run debugIntegration with Claude Desktop
To integrate this MCP server with Claude Desktop:
Open Claude Desktop's settings (Claude menu → Settings)
Click on "Developer" and then "Edit Config"
Update your configuration to include:
{
"mcpServers": {
"MalwareAnalysisMCP": {
"command": "node",
"args": [
"/path/to/MalwareAnalysisMCP/index.js"
]
}
}
}Note: Replace
/path/to/MalwareAnalysisMCPwith the actual path to your project directory.
Restart Claude Desktop
Debugging
To see all communication between Claude Desktop and the MCP server:
Update your Claude Desktop configuration to use the debug proxy:
{
"mcpServers": {
"MalwareAnalysisMCP": {
"command": "node",
"args": [
"/path/to/MalwareAnalysisMCP/mcp-debug-proxy.js"
]
}
}
}Check the logs in the
logsdirectory
Compatibility Notes
Requires Node.js 18 or higher
Compatible with Node.js v22+ using ESM modules
API
Basic Tools
shell_command
Executes a terminal command and returns its process ID, output, and blocked status.
Parameters:
command(string): The command to execute in the terminaltimeout_ms(number, optional): Timeout in milliseconds (default: 30000)
Returns:
pid(number): Process IDoutput(string): Command outputisBlocked(boolean): Whether the command execution is blocked/timed out
read_output
Reads output from a running or completed process.
Parameters:
pid(number): The process ID to read output from
Returns:
output(string | null): The process output, or null if the process is not found
Specialized Malware Analysis Tools
The following specialized tools are available for malware analysis:
file
Analyze a file and determine its type.
Parameters:
target(string): Target file to analyzeoptions(string, optional): Additional command-line options
Example:
{
"target": "suspicious.exe",
"options": "-b"
}strings
Extract printable strings from a file.
Parameters:
target(string): Target file to analyzeminLength(number, optional): Minimum string length to displayencoding(string, optional): String encoding (s=7-bit, S=8-bit, b=16-bit big-endian, l=16-bit little-endian, etc.)options(string, optional): Additional command-line options
Example:
{
"target": "suspicious.exe",
"minLength": 10,
"encoding": "l"
}hexdump
Display file contents in hexadecimal format.
Parameters:
target(string): Target file to analyzelength(number, optional): Number of bytes to displayoffset(number, optional): Starting offset in the fileoptions(string, optional): Additional command-line options
Example:
{
"target": "suspicious.exe",
"length": 256,
"offset": 1024
}objdump
Display information from object files.
Parameters:
target(string): Target file to analyzedisassemble(boolean, optional): Disassemble executable sectionsheaders(boolean, optional): Display the contents of the section headersoptions(string, optional): Additional command-line options
Example:
{
"target": "suspicious.exe",
"disassemble": true
}xxd
Create a hexdump with ASCII representation.
Parameters:
target(string): Target file to analyzelength(number, optional): Number of bytes to displayoffset(number, optional): Starting offset in the filecols(number, optional): Format output into specified number of columnsbits(boolean, optional): Switch to bits (binary) dumpoptions(string, optional): Additional command-line options
Example:
{
"target": "suspicious.exe",
"cols": 16,
"bits": true
}License
ISC
Available Tools
7 toolsfileC
Analyze a file and determine its type
Example usage:
Basic file identification: { "target": "suspicious.exe" }
With options: { "target": "suspicious.exe", "options": "-b" }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file or data to analyze | |
| options | No | Additional command-line options |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it states the tool analyzes files and determines their type, it doesn't describe what happens during analysis (e.g., does it read file contents, check magic bytes, or run external commands?), what permissions are needed, whether it's destructive, or what the output format looks like. The example mentions command-line options but doesn't explain their effects.
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 appropriately sized with a clear purpose statement followed by example usage. The structure is front-loaded with the core functionality, though the example section could be slightly more concise by combining the two usage patterns into one more general example.
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?
For a tool with 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis entails, what kind of output to expect, or how this differs from sibling tools. The lack of behavioral context and output information leaves significant gaps for an AI agent trying to use this tool effectively.
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 already documents both parameters adequately. The description adds minimal value beyond the schema by showing example usage patterns, but doesn't provide additional semantic context about what 'target' should be (e.g., file path vs. raw data) or what 'options' might include beyond '-b'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Analyze a file and determine its type', which is a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling tools like 'strings' or 'xxd', which might also analyze files but for different purposes.
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 example usage patterns but offers no guidance on when to use this tool versus alternatives like 'strings' or 'objdump'. There's no mention of what makes this tool appropriate for file type analysis versus other analysis tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hexdumpA
Display file contents in hexadecimal format
Example usage:
Standard hexdump: { "target": "suspicious.exe" }
With length limit: { "target": "suspicious.exe", "length": 256 }
With offset: { "target": "suspicious.exe", "offset": 1024 }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file or data to analyze | |
| options | No | Additional command-line options | |
| length | No | Number of bytes to display | |
| offset | No | Starting offset in the file |
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it shows example usage patterns, it doesn't describe important behavioral aspects like: whether this reads files safely or modifies them, what permissions are needed, how large files are handled, what the output format looks like, or any rate limits. The description is functional but lacks critical operational context.
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 perfectly structured: a clear purpose statement followed by three specific usage examples. Every sentence earns its place by showing different parameter combinations. No wasted words, and the information is front-loaded with the core functionality stated first.
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?
Given no annotations and no output schema, the description provides basic functionality but lacks completeness for a file analysis tool. It shows how to invoke the tool but doesn't describe what the output looks like, error conditions, file size limitations, or security considerations. The examples help but don't compensate for missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value through concrete usage examples that demonstrate how parameters work together (target with length, target with offset), showing practical combinations beyond what the schema provides. However, it doesn't explain the 'options' parameter's purpose or format.
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 purpose with a specific verb ('Display') and resource ('file contents in hexadecimal format'), distinguishing it from sibling tools like 'file' (general file info), 'strings' (extract text), and 'xxd' (similar but different hex tool). The description immediately communicates what the tool does without ambiguity.
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 provides example usage scenarios that imply when to use the tool (for hex analysis of files), but it doesn't explicitly state when to choose this tool over alternatives like 'xxd' or 'objdump'. The examples show different parameter combinations but lack guidance on tool selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
objdumpB
Display information from object files
Example usage:
Display file headers: { "target": "suspicious.o" }
Disassemble code: { "target": "suspicious.exe", "disassemble": true }
Show section headers: { "target": "suspicious.exe", "headers": true }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file or data to analyze | |
| options | No | Additional command-line options | |
| disassemble | No | Disassemble executable sections | |
| headers | No | Display the contents of the section headers |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what the tool does (display information) but doesn't disclose behavioral traits like whether it's read-only, what permissions are needed, if it modifies files, error handling, or output format. The examples show parameter usage but lack broader context.
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 appropriately sized with a clear purpose statement followed by three concise examples. Each example earns its place by demonstrating different use cases. However, the structure could be slightly improved by front-loading more explicit guidance before the examples.
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?
Given 4 parameters, no annotations, and no output schema, the description is moderately complete. It covers the basic purpose and provides usage examples, but lacks information about behavioral aspects, error conditions, or what the output looks like. For a tool with this complexity, more context would be helpful.
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 already documents all 4 parameters well. The description adds value through examples that illustrate how parameters like 'disassemble' and 'headers' work in practice, but doesn't provide additional semantic meaning beyond what the schema descriptions offer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Display information from object files' which is a specific verb+resource combination. However, it doesn't explicitly differentiate this from sibling tools like 'file' or 'hexdump' which might also analyze files, though the examples hint at specialized object file analysis.
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 provides usage examples that imply when to use this tool (for object file analysis, disassembly, or section header viewing), but doesn't explicitly state when to choose this over alternatives like 'file' for file type identification or 'hexdump' for raw hex output. The guidance is practical but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_outputC
Read output from a running or completed process.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID to read output from |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action 'read output' but does not specify whether this is a read-only operation, if it requires specific permissions, what happens if the PID is invalid, or if there are rate limits. This leaves significant gaps in understanding the tool's behavior.
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, clear sentence that efficiently conveys the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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?
Given the complexity of interacting with processes and no annotations or output schema, the description is incomplete. It lacks details on what the output looks like (e.g., text, binary), error handling, or how it differs from sibling tools, making it insufficient for full contextual understanding.
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 has 100% description coverage, with the 'pid' parameter clearly documented as 'The process ID to read output from'. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'read' and the resource 'output from a running or completed process', making the purpose specific and understandable. However, it does not explicitly distinguish this tool from sibling tools like 'file' or 'shell_command', which might also involve reading process output in some contexts, so it misses full sibling differentiation.
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 versus alternatives. It does not mention any prerequisites, such as needing a valid PID, or compare it to siblings like 'shell_command' for command execution or 'file' for file reading, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shell_commandB
Execute a command in the terminal with timeout. Command will continue running in background if it doesn't complete within timeout.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to execute in the terminal | |
| timeout_ms | No | Optional timeout in milliseconds (default: 30000) |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about timeout handling and background execution, which are useful behavioral traits. However, it lacks details on permissions, error handling, or output format, leaving gaps in transparency for a potentially risky 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 front-loaded and concise, consisting of two sentences that directly convey the core functionality and a key behavioral trait (timeout and background execution). Every sentence earns its place without unnecessary details, making it efficient and well-structured.
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?
Given the complexity of executing shell commands (potentially risky with no annotations or output schema), the description is moderately complete. It covers the basic action and timeout behavior but lacks information on security implications, error responses, or how to handle output, which are important for such a tool.
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 already documents both parameters ('command' and 'timeout_ms') adequately. The description implies timeout behavior but does not add significant meaning beyond what the schema provides, such as default values or usage examples, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('execute a command in the terminal') and the resource ('command'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'read_output' or 'file', which might also involve terminal operations, so it lacks sibling differentiation.
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 versus alternatives such as 'read_output' or other siblings. It mentions a timeout feature but does not specify scenarios where this tool is preferred or when it should be avoided, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stringsB
Extract printable strings from a file
Example usage:
Basic strings extraction: { "target": "suspicious.exe" }
With minimum length: { "target": "suspicious.exe", "minLength": 10 }
With encoding: { "target": "suspicious.exe", "encoding": "l" }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file or data to analyze | |
| options | No | Additional command-line options | |
| minLength | No | Minimum string length to display | |
| encoding | No | String encoding (s=7-bit, S=8-bit, b=16-bit big-endian, l=16-bit little-endian, etc.) |
TDQS
B3.4/5.0
Behavior2/5
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 mentions what the tool does but lacks behavioral details such as permissions needed, rate limits, output format, or error handling. The examples hint at functionality but do not disclose operational traits.
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 front-loaded with the core purpose, followed by concise examples. Each sentence serves a purpose, though the example formatting could be slightly more structured. Overall, it is efficient with little waste.
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?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters. It covers basic usage but lacks details on behavioral aspects and output format, which are important for an extraction tool. It is adequate but has clear gaps.
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 already documents all parameters. The description adds minimal value by providing usage examples that illustrate parameter combinations but does not explain semantics beyond what the schema provides. Baseline 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 specific action ('Extract printable strings') and resource ('from a file'), distinguishing it from sibling tools like 'hexdump' or 'objdump' which perform different analyses. The purpose is immediately apparent and specific.
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 provides example usage scenarios but does not explicitly state when to use this tool versus alternatives like 'file' or 'hexdump'. Usage is implied through examples rather than direct guidance on context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xxdA
Create a hexdump with ASCII representation
Example usage:
Standard xxd dump: { "target": "suspicious.exe" }
With length limit: { "target": "suspicious.exe", "length": 256 }
With column formatting: { "target": "suspicious.exe", "cols": 16 }
Binary bits mode: { "target": "suspicious.exe", "bits": true }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file or data to analyze | |
| options | No | Additional command-line options | |
| length | No | Number of bytes to display | |
| offset | No | Starting offset in the file | |
| cols | No | Format output into specified number of columns | |
| bits | No | Switch to bits (binary) dump |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core functionality (hexdump creation) and shows example parameter combinations, but doesn't mention important behavioral aspects like file access permissions, error handling, output format details, or performance characteristics that would be helpful for an AI 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 perfectly structured: a clear purpose statement followed by specific, well-organized examples. Every sentence serves a purpose - the initial statement defines the tool, and each example demonstrates a different parameter combination. No wasted words or redundant information.
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 tool with 6 parameters, no annotations, and no output schema, the description provides adequate basic information but lacks completeness. It explains what the tool does and shows parameter usage, but doesn't cover behavioral aspects, error conditions, or output format details that would help an AI agent use it effectively in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters well. The description adds value through concrete usage examples that illustrate how parameters combine in practice (e.g., 'With length limit', 'With column formatting', 'Binary bits mode'), providing practical context beyond the schema's technical descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a hexdump with ASCII representation'. This is a specific verb+resource combination that distinguishes it from some siblings like 'file' or 'strings'. However, it doesn't explicitly differentiate from 'hexdump' which might serve a similar function.
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 provides example usage patterns which imply when to use certain parameters, but it doesn't explicitly state when to use this tool versus alternatives like 'hexdump' or 'objdump'. The examples show different scenarios but lack explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
7 tool updates
- First observed
file - First observed
hexdump - First observed
objdump - First observed
read_output - First observed
shell_command - First observed
strings - First observed
xxd
TDQS
B3/5.0
Disambiguation2/5
Several tools have overlapping purposes that could cause confusion. The 'hexdump' and 'xxd' tools both create hexadecimal representations of files with similar options, making them difficult to distinguish. Additionally, 'read_output' and 'shell_command' both deal with process execution but have unclear boundaries, as 'shell_command' mentions background execution while 'read_output' focuses on output reading.
Naming Consistency3/5
The naming conventions are mixed but still readable. Most tools use descriptive names like 'file', 'hexdump', 'objdump', and 'strings', which follow a consistent noun-based pattern. However, 'read_output' uses a verb_noun format while 'shell_command' uses a noun_noun format, creating minor inconsistency. The overall naming is functional but lacks a unified pattern.
Tool Count4/5
With 7 tools, the count is reasonable for a malware analysis server, falling within the typical 3-15 range. It covers core analysis tasks like file identification, hex dumping, and string extraction. However, it feels slightly thin for comprehensive malware analysis, as it lacks tools for network analysis, behavior monitoring, or threat intelligence integration, which are common in this domain.
Completeness2/5
There are significant gaps in the tool surface for malware analysis. While basic file inspection tools are present, there is no coverage for dynamic analysis (e.g., sandbox execution), network traffic analysis, registry monitoring, or malware classification. The server focuses on static analysis only, leaving agents unable to perform common malware investigation workflows, which will likely cause failures in real-world scenarios.
Maintenance
ActivityInactive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for ScanMalware.com URL scanning, malware detection, and analysis.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
A paid remote MCP for ClawManager, built to return verdicts, receipts, usage logs, and audit-ready J
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Related MCP Servers
- AlicenseAqualityDmaintenanceA server that lets Claude desktop app execute terminal commands on your computer and edit files through Model Context Protocol, featuring command execution, process management, and advanced file operations.1948,6086MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server that provides 294 malware analysis tools behind an AI-driven interface, enabling natural language investigation of binaries.216MIT
- AlicenseNot gradedqualityDmaintenanceMCP server that integrates Ghidra for binary analysis, enabling decompilation, disassembly, and advanced reverse engineering tasks through Claude Code.15MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/abdessamad-elamrani/MalwareAnalyzerMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server