Provides tools for scanning, detecting, and removing Java memory shells on Linux systems, including process management, system information retrieval, and remote command execution via SSH.
Provides tools for scanning, detecting, and removing Java memory shells on macOS systems, including process management, system information retrieval, and remote command execution via SSH.
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., "@Memory Shell Detector MCP scan Java process 1234 for suspicious memory shells"
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.
基于 FastMCP 构建的 Java 内存马检测和清理工具 MCP 服务器，支持本地执行和 SSH 远程执行。
项目地址：https://github.com/RuoJi6/memory-shell-mcp
功能 | 工具名称 | 对应命令 |
执行命令（本地/SSH） |
| - |
下载检测工具 |
| - |
列出Java进程 |
|
|
扫描指定进程 |
|
|
查看可疑类代码 |
|
|
移除内存马 |
|
|
导出检测报告 |
|
|
获取系统信息 |
| - |
检测网络状态 |
| - |
Related MCP server: jumpserver-ssh-mcp
移除内存马前会先获取源代码供 AI 分析确认
需要 AI 确认后（ai_confirmed=True）才会执行移除操作
自动处理移除确认提示
Python 3.10+
JDK 1.8+（目标机器）
uv（Python 包管理器）
发布到 PyPI 后，直接使用 uvx 运行，无需安装：
uvx memory-shell-mcp支持 MCP 的客户端：本工具可配置到任何支持 Model Context Protocol 的 AI 客户端，包括但不限于：
AI 助手：Claude Desktop、Claude Code
以下是常用客户端的配置示例：
在 .kiro/settings/mcp.json 中添加：
{
"mcpServers": {
"memory-shell-detector": {
"command": "uvx",
"args": ["memory-shell-mcp"],
"env": {},
"disabled": false,
"autoApprove": []
}
}
}在 claude_desktop_config.json 中添加：
{
"mcpServers": {
"memory-shell-detector": {
"command": "uvx",
"args": ["memory-shell-mcp"],
"env": {}
}
}
}说明：
env中的环境变量均为可选配置。不配置时，工具会下载到系统临时目录，SSH 参数可通过 AI 对话传入。
git clone https://github.com/RuoJi6/memory-shell-mcp.git
cd memory-shell-mcp
# 创建虚拟环境并安装依赖
uv venv --python python3.12
source .venv/bin/activate # Linux/macOS
# .venv\Scripts\activate # Windows
uv pip install -e .# 激活虚拟环境后
memory-shell-mcp{
"mcpServers": {
"memory-shell-detector": {
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/memory-shell-mcp",
"memory-shell-mcp"
],
"env": {}
}
}
}说明：
env中的环境变量均为可选配置。不配置时，工具会下载到系统临时目录，SSH 参数可通过 AI 对话传入。
变量 | 说明 |
| 检测工具（JAR 文件）存放目录，不设置则下载到系统临时目录 |
| SSH 主机地址 |
| SSH 用户名 |
| SSH 密码 |
| SSH 私钥路径（与密码二选一） |
| SSH 端口（默认 22） |
| JDK 路径（可选） |
所有环境变量均为可选，不配置也可正常使用
设置环境变量后，调用工具时无需每次传入对应参数
如果
TOOLS_DIR目录中已存在工具文件，download_detector_tools会跳过下载SSH 参数也可以通过 AI 对话动态传入，优先级高于环境变量
1. 调用 download_detector_tools 下载检测工具
2. 调用 list_java_processes 列出所有 Java 进程，找到目标进程 PID3. 调用 scan_process(pid=目标PID) 扫描目标进程
4. 扫描结果会列出所有可疑类，记录完整类名5. 对每个可疑类调用 view_class_code(class_name="类名", pid=PID) 反编译查看源码
6. 分析源码判断是否为内存马内存马判断标准：
✅ 是否包含命令执行代码（Runtime.exec、ProcessBuilder）
✅ 是否包含反射调用敏感方法
✅ 是否有异常的网络连接或文件操作
✅ 是否动态注册 Filter/Servlet/Listener
✅ 是否有加密/编码的可疑字符串（Base64、AES 等）
✅ 是否有 Webshell 特征（参数名为 cmd/command/exec 等）
✅ 类名是否异常（随机字符串、与业务无关）
✅ 是否有类加载器操作（defineClass、ClassLoader）
7. 确认是内存马后，调用 remove_memory_shell(class_name="类名", pid=PID, ai_confirmed=True)
8. 移除后立即再次调用 scan_process 验证是否清除成功
9. 重要：某些内存马需要多次移除才能彻底清除，如果仍然存在，重复步骤 7-810. 调用 export_report 导出检测报告存档直接复制以下提示词发送给 AI 即可开始检测：
帮我检测本机的 Java Web 服务，排查是否存在内存马。
检测要求：
1. 先下载检测工具，然后列出 Java 进程找到目标 PID
2. 扫描该进程，获取所有可疑类列表
3. 对每个可疑类反编译源代码，分析是否为内存马
4. 如果确认是内存马，执行移除操作
5. 移除后再次扫描验证，某些内存马需要多次移除才能彻底清除
6. 最后给我一个检测报告总结帮我检测远程服务器上的 Java 服务是否存在内存马。
服务器信息：
- IP: 192.168.1.100
- 用户名: root
- 密码: your_password
检测要求：
1. 通过 SSH 连接到服务器
2. 下载检测工具到 /tmp 目录
3. 列出所有 Java 进程，扫描可疑进程
4. 反编译分析每个可疑类的源代码
5. 确认是内存马后执行移除，并验证移除结果
6. 生成检测报告类型 | 特征 | 移除难度 |
Filter 型 | 实现 | 中等，可能需要多次移除 |
Servlet 型 | 继承 | 中等 |
Listener 型 | 实现 | 较易 |
Spring Controller | 使用 | 中等 |
Spring Interceptor | 实现 | 中等 |
Agent 型 | 通过 | 困难，可能需要重启 |
Valve 型 (Tomcat) | 继承 | 中等 |
调用 download_detector_tools调用 list_java_processes()调用 scan_process(pid=进程ID)调用 view_class_code(class_name="类名", pid=进程ID)# AI 确认后调用
调用 remove_memory_shell(class_name="类名", pid=进程ID, ai_confirmed=True)在 MCP 配置的 env 中设置：
"env": {
"TOOLS_DIR": "/your/tools/directory",
"SSH_HOST": "192.168.1.100",
"SSH_USERNAME": "root",
"SSH_PASSWORD": "password"
}调用时只需设置 use_ssh=True：
调用 scan_process(pid=12345, use_ssh=True)直接告诉 AI SSH 连接信息：
调用 scan_process(
pid=12345,
use_ssh=True,
ssh_host="192.168.1.100",
ssh_username="root",
ssh_password="password"
)对话传入的参数优先级高于环境变量
工具会自动从以下地址下载：
Agent JAR: https://xget.xi-xu.me/gh/RuoJi6/memory-shell-mcp/releases/download/1/detector-agent-1.0.0-SNAPSHOT.jar
CLI JAR: https://xget.xi-xu.me/gh/RuoJi6/memory-shell-mcp/releases/download/1/memory-shell-detector-cli.jar
Windows / Linux / macOS
等级 | 说明 |
CRITICAL | 确认为内存马，需立即处理 |
HIGH | 高度可疑，建议人工确认 |
MEDIUM | 中等风险，可能是正常组件 |
LOW | 低风险，基本可排除 |
SAFE | 安全，已在白名单中 |
扫描其他进程需要足够的系统权限
目标进程和检测工具需使用相同或兼容的 JDK 版本
Agent JAR 需要和 CLI JAR 放在同一目录下
Agent 型内存马无法通过本工具移除，需要重启应用
移除内存马可能影响应用正常运行，建议先备份
# 1. 注册 PyPI 账号并获取 API Token
# https://pypi.org/manage/account/token/
# 2. 构建包
uv build
# 3. 发布到 PyPI
uv publish --token YOUR_PYPI_TOKEN
# 4. 发布后即可通过 uvx 运行
uvx memory-shell-mcpmemory-shell-detector - Java 内存马检测工具核心实现
Xget - GitHub 文件加速下载服务
MIT License
检测网络连通性
测试是否能访问工具下载服务器，用于在下载检测工具前确认网络状态。 如果网络不通，需要手动下载 jar 包或检查网络配置。
Returns: available: 网络是否可用 message: 状态描述信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies a read-only check. It does not explicitly state that it has no side effects, but the nature of testing connectivity is inherently non-destructive. Returns status without changing state.
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 concise and well-structured: it states the purpose, usage context, fallback instructions, and return format. Every sentence adds value with no fluff.
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 no parameters and a simple output (available, message), the description fully covers the tool's purpose, use case, and output. It even provides troubleshooting steps, making it contextually complete.
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?
Tool has 0 parameters, so schema coverage is 100%. Baseline 4 applies. Description adds context about what the tool checks, but no parameters to elaborate on.
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 checks network connectivity to a specific server ('工具下载服务器'). It distinguishes from siblings like 'download_detector_tools' or 'execute_command' by specifying it's a network test, not a download or command.
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?
It explicitly mentions when to use: 'before downloading detection tools'. It also provides guidance on what to do if network is unreachable: manually download jar or check configuration. This suggests not to use it for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
下载 Java 内存马检测工具包（detector-agent.jar 和 detector-cli.jar）
此工具会下载两个核心 jar 包：
detector-agent-1.0.0-SNAPSHOT.jar: Java Agent，用于注入目标 JVM 进程
memory-shell-detector-cli.jar: 命令行工具，提供扫描、反编译、移除等功能
这是使用内存马检测功能的前置步骤，下载完成后才能执行后续的扫描和分析操作。
Args: tools_dir: 工具存放目录，不指定则从环境变量 TOOLS_DIR 读取，都没有则使用系统临时目录 use_ssh: 是否在远程服务器上下载 ssh_host: SSH 主机地址（不指定则从环境变量 SSH_HOST 读取） ssh_username: SSH 用户名（不指定则从环境变量 SSH_USERNAME 读取） ssh_password: SSH 密码（不指定则从环境变量 SSH_PASSWORD 读取） ssh_key_path: SSH 私钥路径（不指定则从环境变量 SSH_KEY_PATH 读取） ssh_port: SSH 端口（不指定则从环境变量 SSH_PORT 读取）
Returns: 下载结果，包含工具目录路径和 jar 文件名
| Name | Required | Description | Default |
|---|---|---|---|
| tools_dir | No | ||
| use_ssh | No | ||
| ssh_host | No | ||
| ssh_username | No | ||
| ssh_password | No | ||
| ssh_key_path | No | ||
| ssh_port | 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 carries full burden. It explains what is downloaded and the basic behavior, but lacks details on side effects like file overwriting, disk space needs, or error handling. The description is adequate but not rich on behavioral context.
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 clear purpose up front, followed by parameter details and return value. It is efficient with no wasted sentences.
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 complexity (7 optional parameters) and absence of annotations, the description is quite complete, explaining parameters and return. However, it lacks details on error conditions or failure handling, and the output schema is not described, but since output schema exists, this is a minor gap.
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?
Parameter descriptions in the Args section cover all 7 parameters, adding meaning beyond the schema, which has 0% description coverage. Each parameter explains its purpose and fallback to environment variables, providing clear guidance.
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 downloads two specific jar files for Java memory shell detection. It uses specific verbs ('下载') and resource names ('detector-agent.jar', 'detector-cli.jar'), and distinguishes itself from sibling tools like scan_process and remove_memory_shell by being a prerequisite step.
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 explicitly states it is a prerequisite step before scanning and analysis, providing clear context for when to use the tool. However, it does not mention when not to use it or suggest alternatives, which slightly reduces the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行系统命令（本地或通过 SSH 远程执行）
这是一个通用的命令执行工具，可用于：
检查 Java 环境是否正常（java -version）
查看系统进程状态（ps aux）
执行其他辅助命令
注意：内存马检测的核心功能请使用专用工具（list_java_processes、scan_process 等）， 此工具仅用于辅助操作。
Args: command: 要执行的 shell 命令 use_ssh: 是否使用 SSH 远程执行 ssh_host: SSH 主机地址（不指定则从环境变量 SSH_HOST 读取） ssh_username: SSH 用户名（不指定则从环境变量 SSH_USERNAME 读取） ssh_password: SSH 密码（不指定则从环境变量 SSH_PASSWORD 读取） ssh_key_path: SSH 私钥路径（不指定则从环境变量 SSH_KEY_PATH 读取） ssh_port: SSH 端口，默认 22（不指定则从环境变量 SSH_PORT 读取） timeout: 命令超时时间（秒），默认 300 秒
Returns: 执行结果，包含 success、stdout、stderr、return_code
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| use_ssh | No | ||
| ssh_host | No | ||
| ssh_username | No | ||
| ssh_password | No | ||
| ssh_key_path | No | ||
| ssh_port | 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 carries full burden. It discloses execution behavior, return fields (success, stdout, stderr, return_code), SSH configuration, and timeout. However, it does not mention potential risks (e.g., destructive commands, security implications) or required permissions, leaving important behavioral aspects unclear.
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 front-loaded with purpose and usage guidelines, followed by parameter details. It is well-structured but slightly verbose with the 'Args' section repeating parameter names. Every sentence serves a purpose, but some redundancy could be trimmed.
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 tool's complexity (8 params, local/remote execution, environment variable fallbacks), the description covers core functionality, usage boundaries, and return structure. It lacks security warnings or error handling details, but overall it is sufficiently complete for typical usage scenarios.
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 description coverage is 0%, so the description must compensate. It provides details for all 8 parameters, including environment variable fallbacks for SSH parameters and default values. This adds significant meaning beyond the schema's raw types and defaults, though the command parameter could have more examples or format guidance.
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 executes system commands locally or via SSH, provides concrete examples (java -version, ps aux), and explicitly distinguishes it from sibling tools like list_java_processes and scan_process for core detection. The verb 'execute' and resource 'system commands' are specific.
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 explicitly states when to use (checking Java, system processes, auxiliary commands) and when not to use (core memory shell detection should use dedicated tools). It names specific alternatives: list_java_processes and scan_process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 memory-shell-detector-cli.jar 生成内存马检测报告
底层命令: java -jar memory-shell-detector-cli.jar --report -p -f
此工具将扫描结果导出为结构化报告，包含：
扫描时间和目标进程信息
检测到的所有可疑类列表
每个可疑类的风险等级和类型判断
反编译的源代码片段
Args: pid: 目标 Java 进程的 PID output_file: 报告输出文件路径 tools_dir: 检测工具 jar 包所在目录 format: 报告格式（json/html/txt） use_ssh: 是否通过 SSH 在远程服务器执行 ssh_host/ssh_username/ssh_password/ssh_key_path/ssh_port: SSH 连接参数
Returns: 导出结果和报告文件路径
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | ||
| output_file | Yes | ||
| tools_dir | No | ||
| format | No | json | |
| use_ssh | No | ||
| ssh_host | No | ||
| ssh_username | No | ||
| ssh_password | No | ||
| ssh_key_path | No | ||
| ssh_port | 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 carries the burden of behavioral transparency. It reveals the underlying command and SSH parameters, implying network usage and external execution. However, it does not explicitly state that the tool is read-only or non-destructive, nor does it mention permissions or side effects. The transparency is adequate but incomplete.
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 structured with a first sentence stating the action, followed by the underlying command, bullet-pointed report contents, and a parameter list. It is front-loaded and reasonably concise given the complexity (10 params, SSH support). Minor redundancy (e.g., 'Args' list repeats schema) but overall efficient.
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 tool's purpose, command, report contents, parameters, and return value. Since an output schema exists, the return description is sufficient. It addresses SSH execution context but omits error handling or failure scenarios. It is fairly complete for a tool of this complexity.
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 description coverage is 0%, so the description must add meaning. It lists all 10 parameters and clarifies their roles (e.g., format accepts json/html/txt, ssh parameters for remote execution). It explains the report contents, which helps contextualize output_file and format. However, it does not provide detailed documentation for each parameter beyond the basic description, so it adds value but could be richer.
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: executing a JAR to generate a memory shell detection report. It specifies the underlying command and details the report contents (scan time, suspicious classes, risk levels, source code). This distinguishes it from siblings like scan_process or remove_memory_shell.
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 no explicit guidance on when to use this tool versus alternatives (e.g., scan_process for scanning, view_class_code for viewing code). It does not mention prerequisites (e.g., needing to run scan_process first) or when not to use it. Usage is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前系统环境信息
返回操作系统类型、平台架构、临时目录等信息， 用于判断检测工具的兼容性和确定工具存放路径。
Returns: system: 操作系统（Linux/Windows/Darwin） platform: 完整平台信息 machine: CPU 架构 temp_dir: 系统临时目录路径
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description omits behavioral traits like read-only nature. However, lists return fields, which partially compensates.
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?
Front-loaded bilingual description, concise bullet list of return fields, no superfluous words.
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?
With output schema present, description fully explains return values and purpose; no gaps for a parameterless 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?
No parameters, baseline 4. Description adds meaning by detailing return fields beyond empty 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?
Specific verb+resource ('获取当前系统环境信息'), clearly distinguishes from siblings like check_network or download_detector_tools.
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?
States use case: compatibility checking and tool storage path determination. Provides clear context but no explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 memory-shell-detector-cli.jar 列出系统中所有运行的 Java 进程
底层命令: java -jar memory-shell-detector-cli.jar -l
此工具通过调用内存马检测器的 CLI jar 包，扫描系统中所有 Java 进程， 返回进程 PID、进程名称等信息，用于后续选择目标进程进行内存马扫描。
Args: tools_dir: 检测工具 jar 包所在目录 use_ssh: 是否通过 SSH 在远程服务器执行 ssh_host/ssh_username/ssh_password/ssh_key_path/ssh_port: SSH 连接参数
Returns: processes: Java 进程列表信息
| Name | Required | Description | Default |
|---|---|---|---|
| tools_dir | No | ||
| use_ssh | No | ||
| ssh_host | No | ||
| ssh_username | No | ||
| ssh_password | No | ||
| ssh_key_path | No | ||
| ssh_port | No |
| 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 must fully disclose behavioral traits. It states the tool lists processes (implying read-only) but does not mention potential side effects like performance impact or Java dependency. The behavior is partially clear but not fully transparent.
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 structured with a brief intro, command explanation, purpose, and parameter list. It is reasonably concise, though the inclusion of both Chinese and English adds some verbosity.
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 complexity of 7 parameters and no required ones, the description covers the tool's purpose, parameters, and return value. It lacks error handling details and dependencies like required Java installation, but is largely complete.
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 has no property descriptions, but the description compensates by listing all 7 parameters with their purpose in an Args section. This adds significant meaning beyond the schema, though some parameter details (e.g., constraints) are missing.
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 executes a specific jar to list all running Java processes, providing a specific verb and resource. It distinguishes from siblings like scan_process by indicating it is a preliminary step for selecting target processes.
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 explains the tool is used before memory shell scanning and provides context for SSH usage. However, it does not explicitly contrast with alternatives or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 memory-shell-detector-cli.jar 从 JVM 内存中移除指定的内存马类
底层命令: java -jar memory-shell-detector-cli.jar -r -p
此工具通过 Java Agent 技术从运行中的 JVM 进程中卸载/禁用指定的恶意类， 实现不重启服务的情况下清除内存马。
移除机制：
对于 Filter/Servlet/Listener：从 Web 容器中注销
对于 Spring 组件：从 Spring 容器中移除 Bean
对于 Agent 类型：尝试还原被 hook 的方法
安全机制：首次调用时会先反编译目标类源码供 AI 分析确认， 确认是内存马后需设置 ai_confirmed=True 再次调用才会执行移除。
Args: class_name: 要移除的内存马完整类名 pid: 目标 Java 进程的 PID tools_dir: 检测工具 jar 包所在目录 ai_confirmed: AI 是否已确认该类为内存马（首次调用设为 False） use_ssh: 是否通过 SSH 在远程服务器执行 ssh_host/ssh_username/ssh_password/ssh_key_path/ssh_port: SSH 连接参数
Returns: 首次调用返回反编译源码供分析，确认后返回移除结果
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | ||
| pid | Yes | ||
| tools_dir | No | ||
| ai_confirmed | No | ||
| use_ssh | No | ||
| ssh_host | No | ||
| ssh_username | No | ||
| ssh_password | No | ||
| ssh_key_path | No | ||
| ssh_port | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it uses Java Agent to unload/disable classes, explains removal mechanisms per type (Filter/Servlet/Listener, Spring, Agent), and describes the two-phase safety mechanism. It also states return values for each phase. No contradictions.
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 purpose, command, mechanism, security, args, and returns. It is front-loaded with the main purpose. While it is somewhat long, every sentence adds value, and no redundancy is present. A slight further tightening could improve, but it's already 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 tool has an output schema, but the description covers the two-phase return. It addresses complexity: removal mechanisms, security confirmation, remote execution via SSH. No critical details are missing for an agent to use correctly. It is complete for the tool's purpose.
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%, so the description must compensate. It provides clear explanations for all 10 parameters in the 'Args' section, including the ai_confirmed workflow and SSH connection parameters. It adds meaning beyond the schema by explaining the roles of tools_dir and the ai_confirmed flag.
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 explicitly states the tool removes memory shells from JVM processes, using a specific verb ('remove') and resource ('memory shell'). It distinguishes from siblings (e.g., scan_process detects, this removes) and provides the underlying command.
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 details a two-step usage pattern: first call with ai_confirmed=False to decompile and confirm, then second call with ai_confirmed=True to execute removal. It also clarifies when to use (after detection) and implies when not (without prior confirmation). Siblings like view_class_code or scan_process are for different phases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 memory-shell-detector-cli.jar 对指定 Java 进程进行内存马扫描检测
底层命令: java -jar memory-shell-detector-cli.jar -s
此工具通过 Java Agent 技术注入目标 JVM 进程，扫描以下可疑组件：
Servlet/Filter/Listener 类型内存马
Spring Controller/Interceptor 内存马
Agent 类型内存马
其他动态注册的恶意类
扫描结果会列出所有可疑类的完整类名，供后续反编译分析。
Args: pid: 目标 Java 进程的 PID tools_dir: 检测工具 jar 包所在目录 use_ssh: 是否通过 SSH 在远程服务器执行 ssh_host/ssh_username/ssh_password/ssh_key_path/ssh_port: SSH 连接参数
Returns: scan_result: 扫描结果，包含可疑类列表
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | ||
| tools_dir | No | ||
| use_ssh | No | ||
| ssh_host | No | ||
| ssh_username | No | ||
| ssh_password | No | ||
| ssh_key_path | No | ||
| ssh_port | No |
| 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 explains the technology used (Java Agent injection), what components are scanned, and that results list suspicious class names. It doesn't discuss side effects or safety, but as a diagnostic tool, the description is sufficiently transparent.
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: purpose, command, detection targets, then argument list. It's informative without being overly verbose, though some redundancy could be trimmed. Each sentence contributes to understanding.
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 tool's complexity (8 parameters, SSH support, output), the description covers the main aspects: what it does, what it scans, all parameters, and the return format. With an output schema present, the description needn't detail return structure 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 description coverage is 0%, so the description compensates by listing all 8 parameters with brief explanations (e.g., pid, tools_dir, SSH options). It adds meaning beyond the schema's types and defaults, though some details (like valid pid range) are missing.
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 it executes a memory shell detection scan on a Java process, detailing the types of memory shells detected (Servlet, Spring, Agent, etc.). It is distinct from siblings like 'remove_memory_shell' or 'list_java_processes'.
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 explains when to use the tool (to scan a Java process for memory shells) and provides the underlying command. It doesn't explicitly state when not to use or mention alternatives, but the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 memory-shell-detector-cli.jar 从 JVM 内存中提取并反编译指定类的字节码
底层命令: java -jar memory-shell-detector-cli.jar -v -p
此工具通过 Java Agent 从运行中的 JVM 进程内存中 dump 指定类的字节码， 然后使用内置反编译器将字节码还原为可读的 Java 源代码。
这是分析内存马的关键步骤，可以查看：
类的完整实现逻辑
恶意代码的具体行为（如命令执行、文件操作、网络连接等）
内存马的注入方式和触发条件
Args: class_name: 要反编译的完整类名（如 com.example.EvilFilter） pid: 目标 Java 进程的 PID tools_dir: 检测工具 jar 包所在目录 use_ssh: 是否通过 SSH 在远程服务器执行 ssh_host/ssh_username/ssh_password/ssh_key_path/ssh_port: SSH 连接参数
Returns: source_code: 反编译后的 Java 源代码
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | ||
| pid | Yes | ||
| tools_dir | No | ||
| use_ssh | No | ||
| ssh_host | No | ||
| ssh_username | No | ||
| ssh_password | No | ||
| ssh_key_path | No | ||
| ssh_port | No |
| 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 full burden. It describes the process (dump bytecode, decompile) and underlying command, but does not disclose potential side effects (e.g., JVM impact), error conditions (class not found, invalid PID), or security requirements. Behavior beyond 'success' is missing.
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: purpose, command example, usage context, parameter list, and return value. It is somewhat verbose with redundant technical details, but information is front-loaded and logically organized. Minor conciseness improvements possible.
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 tool's complexity (9 params, optional SSH, remote execution), the description covers the main workflow and parameters. However, it lacks guidance on SSH usage triggers, error handling, and prerequisites. An output schema exists but is not detailed here; the description's mention of 'source_code' is sufficient.
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 description coverage is 0%, so the description must explain parameters. It provides brief but clear explanations for all 9 parameters, including examples for 'class_name' and 'pid', and context for SSH-related parameters. Could be more detailed (e.g., format constraints), but adequately adds meaning beyond the bare 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 extracts and decompiles bytecode from JVM memory using a specific jar. It uses a specific verb ('extract and decompile') and specifies the resource (class bytecode). The tool is distinct from siblings like 'execute_command' or 'scan_process', which do not perform 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 mentions it's for analyzing memory shells ('内存马') but does not explicitly state when to use this tool versus alternatives like 'execute_command' or 'scan_process'. There is no guidance on prerequisites (e.g., Java Agent availability) or exclusions. Usage context is implied but not explicit.
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.
check_networkdownload_detector_toolsexecute_commandexport_reportget_system_info_toollist_java_processesremove_memory_shellscan_processview_class_codeEach tool has a distinct purpose: network check, download, command execution, report export, system info, process listing, scanning, code viewing, and removal. No overlap exists, and descriptions clearly differentiate them.
Most tools follow verb_noun pattern (check_network, download_detector_tools, export_report, etc.). One outlier, get_system_info_tool, uses 'get' instead of a consistent verb and adds redundant '_tool', slightly breaking consistency.
With 9 tools, the server covers the full workflow from preparation (check, download) to detection (list, scan, view) to remediation (remove, report). The count is well-scoped and not excessive.
The toolset covers the entire memory shell detection lifecycle: network check, tool download, process listing, scanning, code review, removal, and report generation. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Ship better Java with your coding agent.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RuoJi6/memory-shell-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
