Skip to main content
Glama
deenesjakoruzh
abdessamad-elamrani

MalwareAnalyzerMCP

by abdessamad-elamrani
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

MalwareAnalyzerMCP

Claude Desktop을 위한 특수 MCP 서버로, 악성 소프트웨어 분석을 위한 터미널 명령을 실행할 수 있습니다.

특징

  • 구성 가능한 시간 초과로 터미널 명령 실행

  • 실행 중이거나 완료된 프로세스의 출력을 읽습니다.

  • 전문화된 악성 소프트웨어 분석 명령( file , strings , hexdump , objdump , xxd )

  • 우아한 종료로 깔끔한 프로세스 관리

  • 순수 JavaScript 구현 - 빌드 단계 필요 없음

Related MCP server: Desktop Commander MCP

설치

지엑스피1

용법

서버 실행

# Start the server directly
node index.js

# Or use npm script
npm start

# With debugging proxy (logs all communications)
npm run debug

Claude Desktop과 통합

이 MCP 서버를 Claude Desktop과 통합하려면:

  1. Claude Desktop의 설정을 엽니다(Claude 메뉴 → 설정)

  2. "개발자"를 클릭한 다음 "구성 편집"을 클릭하세요.

  3. 다음을 포함하도록 구성을 업데이트하세요.

{
  "mcpServers": {
    "MalwareAnalysisMCP": {
      "command": "node",
      "args": [
        "/path/to/MalwareAnalysisMCP/index.js"
      ]
    }
  }
}

참고 : /path/to/MalwareAnalysisMCP 프로젝트 디렉토리의 실제 경로로 바꾸세요.

  1. Claude Desktop을 다시 시작하세요

디버깅

Claude Desktop과 MCP 서버 간의 모든 통신을 보려면:

  1. 디버그 프록시를 사용하도록 Claude Desktop 구성을 업데이트하세요.

{
  "mcpServers": {
    "MalwareAnalysisMCP": {
      "command": "node",
      "args": [
        "/path/to/MalwareAnalysisMCP/mcp-debug-proxy.js"
      ]
    }
  }
}

  1. logs 디렉토리에서 로그를 확인하세요

호환성 참고 사항

  • Node.js 18 이상이 필요합니다.

  • ESM 모듈을 사용하여 Node.js v22+와 호환 가능

API

기본 도구

shell_command

터미널 명령을 실행하고 프로세스 ID, 출력, 차단 상태를 반환합니다.

매개변수:

  • command (문자열): 터미널에서 실행할 명령

  • timeout_ms (숫자, 선택 사항): 밀리초 단위의 시간 초과(기본값: 30000)

보고:

  • pid (숫자): 프로세스 ID

  • output (문자열): 명령 출력

  • isBlocked (부울): 명령 실행이 차단되었거나 시간이 초과되었는지 여부

읽기_출력

실행 중이거나 완료된 프로세스의 출력을 읽습니다.

매개변수:

  • pid (숫자): 출력을 읽을 프로세스 ID

보고:

  • output (문자열 | null): 프로세스 출력 또는 프로세스를 찾을 수 없는 경우 null

전문화된 맬웨어 분석 도구

다음은 맬웨어 분석에 사용할 수 있는 전문 도구입니다.

파일

파일을 분석하고 유형을 확인합니다.

매개변수:

  • target (문자열): 분석할 대상 파일

  • options (문자열, 선택 사항): 추가 명령줄 옵션

예:

{
  "target": "suspicious.exe",
  "options": "-b"
}

현악기

파일에서 인쇄 가능한 문자열을 추출합니다.

매개변수:

  • target (문자열): 분석할 대상 파일

  • minLength (숫자, 선택 사항): 표시할 최소 문자열 길이

  • encoding (문자열, 선택 사항): 문자열 인코딩(s=7비트, S=8비트, b=16비트 빅 엔디안, l=16비트 리틀 엔디안 등)

  • options (문자열, 선택 사항): 추가 명령줄 옵션

예:

{
  "target": "suspicious.exe",
  "minLength": 10,
  "encoding": "l"
}

헥스덤프

16진수 형식으로 파일 내용을 표시합니다.

매개변수:

  • target (문자열): 분석할 대상 파일

  • length (숫자, 선택 사항): 표시할 바이트 수

  • offset (숫자, 선택 사항): 파일의 시작 오프셋

  • options (문자열, 선택 사항): 추가 명령줄 옵션

예:

{
  "target": "suspicious.exe",
  "length": 256,
  "offset": 1024
}

objdump

개체 파일의 정보를 표시합니다.

매개변수:

  • target (문자열): 분석할 대상 파일

  • disassemble (부울, 선택 사항): 실행 가능한 섹션을 분해합니다.

  • headers (부울, 선택 사항): 섹션 헤더의 내용을 표시합니다.

  • options (문자열, 선택 사항): 추가 명령줄 옵션

예:

{
  "target": "suspicious.exe",
  "disassemble": true
}

xxd

ASCII 표현으로 16진수 덤프를 만듭니다.

매개변수:

  • target (문자열): 분석할 대상 파일

  • length (숫자, 선택 사항): 표시할 바이트 수

  • offset (숫자, 선택 사항): 파일의 시작 오프셋

  • cols (숫자, 선택 사항): 지정된 수의 열로 출력을 포맷합니다.

  • bits (부울, 선택 사항): 비트(바이너리) 덤프로 전환

  • options (문자열, 선택 사항): 추가 명령줄 옵션

예:

{
  "target": "suspicious.exe",
  "cols": 16,
  "bits": true
}

특허

아이에스씨

Available Tools

7 tools
fileC

Analyze a file and determine its type

Example usage:

  • Basic file identification: { "target": "suspicious.exe" }

  • With options: { "target": "suspicious.exe", "options": "-b" }

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYesTarget file or data to analyze
optionsNoAdditional 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
NameRequiredDescriptionDefault
targetYesTarget file or data to analyze
optionsNoAdditional command-line options
lengthNoNumber of bytes to display
offsetNoStarting 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
NameRequiredDescriptionDefault
targetYesTarget file or data to analyze
optionsNoAdditional command-line options
disassembleNoDisassemble executable sections
headersNoDisplay 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
NameRequiredDescriptionDefault
pidYesThe 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
NameRequiredDescriptionDefault
commandYesThe command to execute in the terminal
timeout_msNoOptional 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
NameRequiredDescriptionDefault
targetYesTarget file or data to analyze
optionsNoAdditional command-line options
minLengthNoMinimum string length to display
encodingNoString 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
NameRequiredDescriptionDefault
targetYesTarget file or data to analyze
optionsNoAdditional command-line options
lengthNoNumber of bytes to display
offsetNoStarting offset in the file
colsNoFormat output into specified number of columns
bitsNoSwitch 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.

  1. 7 tool updates
    • First observedfile
    • First observedhexdump
    • First observedobjdump
    • First observedread_output
    • First observedshell_command
    • First observedstrings
    • First observedxxd
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored across 7 tools

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

Related MCP Connectors

Related MCP Servers

  • Desktop Commander MCP

    MrGNSS
    A
    license
    A
    quality
    D
    maintenance
    A 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.
    19
    204,381 npm
    6
    MIT

  • Arkana

    JameZUK
    A
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that provides 294 malware analysis tools behind an AI-driven interface, enabling natural language investigation of binaries.
    243
    MIT

  • Kawaiidra MCP

    wagonbomb
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server that integrates Ghidra for binary analysis, enabling decompilation, disassembly, and advanced reverse engineering tasks through Claude Code.
    16
    MIT

Appeared in Searches