Pentest MCP 是一个模型上下文协议服务器，它将重要的渗透测试工具集成到统一的自然语言界面中。它允许安全专业人员通过对话命令执行、链接和分析多个工具。
该工具包在一个直观的界面下集成了四个核心渗透测试实用程序：
使用 Nmap 进行网络侦察
使用 Gobuster 进行Web 目录枚举
使用 Nikto 进行Web 漏洞扫描
使用 John the Ripper破解密码
Related MCP server: pentestMCP
**工作流程集成：**将工具链接在一起进行全面评估
**自然语言界面：**使用简单的英文描述运行复杂的命令
**自动报告：**通过适当的分类生成客户可用的调查结果
**时间效率：**以最少的输入执行常见的渗透测试序列
**兼容语音控制：**与语音转文本功能配对时，可实现免提操作
**上下文感知：**工具了解之前的扫描结果并可以建议合理的后续步骤
**平台：**适用于任何操作系统，针对 Kali Linux 进行了优化
**工具：**需要 Nmap、John the Ripper、Gobuster 和 Nikto 在你的 PATH 中
Node.js： v16+（用于 ESM 支持）
**MCP 支持：**用于处理日志文件的本地 MCP 文件服务器（mcp-fileserver 或同等服务器）
权限： Root/admin 特权扫描（SYN 扫描、OS 检测）
npm install -g pentest-mcp将其添加到您的 MCP 配置文件中：
{
"servers": [
{
"name": "pentest-mcp",
"command": "npx pentest-mcp -y"
}
]
}Set the working mode to professional.
Scan the target 192.168.1.0/24 using a SYN scan technique with service detection.Use Gobuster to search for hidden directories on http://192.168.1.10 with the common.txt wordlist.
Run Nikto against the target http://192.168.1.10 to check for security issues.Scan 10.0.1.0/24 for web servers.
For each web server found, use Gobuster to enumerate directories with the directory-list-2.3-medium.txt wordlist.
Then run Nikto against each web server to identify vulnerabilities.
Create a report for client "Acme Corp" summarizing all findings.Generate a wordlist from the target's company name "Acme", founder "Smith", and founding date "1984-06-12".
Crack these password hashes using the wordlist I just created:
admin:$1$xyz$anotherFakeHash
user:$1$abc$definitelyNotARealHashCreate a report for client "Example Corp" titled "Q1 External Assessment" including all scans from today.
Summarize the findings from the scan of 10.0.0.5.
Suggest next steps for this assessment based on all tool results collected so far.网络映射器集成提供对以下内容的全面支持：
使用自定义端口范围进行端口扫描（TCP SYN、TCP Connect、UDP）
可配置强度的服务和版本检测
操作系统指纹识别
NSE脚本执行
自定义计时模板和扫描选项
Web 应用程序的目录和文件枚举，具有以下选项：
多个单词列表和文件扩展名扫描
身份验证选项（基本身份验证、cookie）
可定制的线程和状态代码过滤
TLS 配置和重定向
Web 服务器漏洞扫描，支持：
全面的漏洞检查
身份验证和代理支持
可调扫描选项和超时配置
按漏洞类型查找分类
具有增强功能的密码破解实用程序：
使用单词表直接破解哈希值
集成自定义词表生成
基于模式的密码创建
俚语和格变体
**仅限授权使用：**本工具包仅供在有效工作范围内工作的专业渗透测试人员使用。请仅在您获得明确书面授权的系统和网络上使用。
运营安全：
使用 VPN 进行外部扫描
在隔离环境中运行
监控敏感网络的扫描强度
**遵守法律：**遵守所有适用法律和客户协议
**路径问题：**确保所有工具都已安装并位于您的 PATH 中
权限要求： SYN 扫描和 OS 检测需要 root/admin
**权限错误：**检查服务器是否可以写入scan_logs和temp_wordlists
**MCP 文件访问：**验证 mcp-fileserver（或同等服务器）是否配置正确
此工具由专业人士为专业人士打造。欢迎在GitHub 仓库提交Pull 请求。
| Name | Required | Description | Default |
|---|---|---|---|
| scanId | Yes | The ID of the scan to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| client | Yes | Client name for the report | |
| title | Yes | Title of the assessment report | |
| assessmentType | Yes | Type of assessment | |
| scanIds | Yes | IDs of scans to include | |
| summary | No | Executive summary | |
| recommendations | No | List of recommendations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| baseWords | Yes | List of base words (names, pets, places, etc.). | |
| dates | No | List of dates (YYYY-MM-DD, MM-DD, YYYY). Parsed for variations. | |
| customPatterns | No | List of custom patterns/symbols to prepend/append (e.g., '!', '123'). | |
| minYear | No | Minimum year (YYYY) to include in variations. | |
| maxYear | No | Maximum year (YYYY) to include in variations (defaults to current year). | |
| includeLeet | No | Apply basic leetspeak substitutions (a=4, e=3, etc.). | |
| caseVariations | No | Include variations like TitleCase, UPPERCASE. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL | |
| wordlist | Yes | Path to wordlist | |
| extensions | No | File extensions (comma-separated) | |
| threads | No | Number of threads | |
| statusCodes | No | Valid status codes (comma-separated) | |
| useragent | No | User-Agent string | |
| timeout | No | Timeout for requests | |
| basicAuth | No | Basic authentication credentials (username:password) | |
| cookie | No | Cookie to include in requests | |
| excludeLength | No | Exclude paths of specific lengths | |
| followRedirect | No | Follow HTTP redirects | |
| noTLSValidation | No | Skip TLS certificate validation | |
| rawOptions | No | Raw gobuster options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL | |
| port | No | Port(s) to scan | |
| ssl | No | Force SSL mode | |
| timeout | No | Timeout for requests | |
| useragent | No | User-Agent string | |
| tuning | No | Tuning mode | |
| output | No | Output file | |
| proxy | No | Use proxy | |
| basicAuth | No | Basic authentication credentials (username:password) | |
| root | No | Root directory | |
| cookies | No | Cookies to include | |
| rawOptions | No | Raw nikto options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| ports | No | ||
| fastScan | No | ||
| topPorts | No | ||
| scanTechnique | No | ||
| udpScan | No | ||
| serviceVersionDetection | No | ||
| versionIntensity | No | ||
| osDetection | No | ||
| defaultScripts | No | ||
| scripts | No | ||
| scriptArgs | No | ||
| timingTemplate | No | ||
| skipHostDiscovery | No | ||
| verbose | No | ||
| rawOptions | No | ||
| userModeHint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| hashData | Yes | String containing the password hashes, one per line. | |
| attackMode | No | Attack mode: 0=Straight, 1=Combination, 3=Brute-force, 6=Hybrid Wordlist + Mask, 7=Hybrid Mask + Wordlist | |
| hashType | No | Hash-type, e.g., 0=MD5, 100=SHA1, 1000=NTLM, 1400=SHA2-256, 1800=sha512crypt, 22000=WPA*01/WPA*02 | |
| wordlist | No | Path to wordlist file for dictionary attacks | |
| mask | No | Mask for brute-force attacks (e.g., '?a?a?a?a?a?a?a?a' for 8 chars) | |
| increment | No | Enable incremental mode (start with shorter passwords) | |
| incrementMin | No | Minimum password length for incremental mode | |
| incrementMax | No | Maximum password length for incremental mode | |
| rules | No | Rules file to apply to wordlist | |
| session | No | Session name for resuming attacks | |
| restore | No | Restore a previous session | |
| optimizedKernels | No | Enable optimized kernels (-O) | |
| workloadProfile | No | Workload profile: 1=Low, 2=Default, 3=High, 4=Nightmare | |
| deviceTypes | No | Device types: 1=CPU, 2=GPU, 3=FPGA | |
| force | No | Ignore warnings | |
| potfilePath | No | Path to custom potfile | |
| outfile | No | Output file for cracked hashes | |
| outfileFormat | No | Output format: 1=hash, 2=plain, 3=hex-plain, etc. | |
| runtime | No | Abort session after X seconds | |
| showProgress | No | Show progress every X seconds | |
| quiet | No | Suppress output | |
| loopback | No | Add new plains to induct directory | |
| markovThreshold | No | Threshold X when to stop accepting new Markov-chains | |
| customCharset1 | No | User-defined charset ?1 | |
| customCharset2 | No | User-defined charset ?2 | |
| customCharset3 | No | User-defined charset ?3 | |
| customCharset4 | No | User-defined charset ?4 | |
| options | No | Additional raw hashcat options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| hashData | Yes | String containing the password hashes, one per line. | |
| options | No | Array of command-line options for JtR. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 no description.
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?
Tool has no description.
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?
Tool has no description.
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.
cancelScancreateClientReportgenerateWordlistgobusterniktonmapScanrunHashcatrunJohnTheRippersetModeScored across 9 tools
The tools have distinct purposes in penetration testing (e.g., nmapScan for scanning, gobuster for directory busting, runHashcat for password cracking), but some overlap exists in the 'run' category (runHashcat and runJohnTheRipper both handle password cracking with different tools), and the vague 'setMode' could be confused with other configuration or control functions. Descriptions are missing, which limits clarity, but the tool names suggest reasonably separate domains.
Naming is inconsistent with mixed conventions: camelCase (cancelScan, createClientReport, setMode) and snake_case-like patterns (gobuster, nikto, nmapScan, runHashcat, runJohnTheRipper, generateWordlist). There's no uniform verb_noun pattern; some tools use verbs like 'run' or 'create', while others are tool names or actions without clear structure, making the set less predictable.
With 9 tools, the count is appropriate for a penetration testing server, covering key areas like scanning, cracking, reporting, and wordlist generation. It's well-scoped without being overly heavy, though it could be slightly thin if more specialized tools are needed, but it reasonably represents core pentest functions.
The tool set covers major pentest phases: reconnaissance (nmapScan), vulnerability scanning (nikto), password cracking (runHashcat, runJohnTheRipper), and reporting (createClientReport). However, there are notable gaps, such as no tools for exploitation, post-exploitation, or data exfiltration, and missing descriptions make it hard to assess full coverage, but it provides a basic workflow from scan to report.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
