Pentest MCP는 필수 침투 테스트 도구를 통합된 자연어 인터페이스로 통합하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 보안 전문가는 대화형 명령을 통해 여러 도구를 실행, 연결 및 분석할 수 있습니다.
이 툴킷은 4가지 핵심 침투 테스트 유틸리티를 단일하고 직관적인 인터페이스로 통합했습니다.
Nmap을 사용한 네트워크 정찰
Gobuster를 사용한 웹 디렉토리 열거
Nikto를 사용한 웹 취약점 스캐닝
John the Ripper를 이용한 비밀번호 해독
Related MCP server: pentestMCP
워크플로 통합: 포괄적인 평가를 위해 도구를 함께 연결합니다.
자연어 인터페이스: 간단한 영어 설명으로 복잡한 명령을 실행합니다.
자동 보고: 적절한 분류를 통해 클라이언트에게 적합한 결과를 생성합니다.
시간 효율성: 최소한의 타이핑으로 일반적인 침투 테스트 시퀀스를 실행합니다.
음성 제어 호환: 음성-텍스트 기능과 페어링하면 핸즈프리 작동이 가능합니다.
컨텍스트 인식: 도구는 이전 스캔 결과를 이해하고 논리적인 다음 단계를 제안할 수 있습니다.
플랫폼: 모든 OS에서 작동하며 Kali Linux에 최적화됨
도구: PATH에 Nmap, John the Ripper, Gobuster 및 Nikto가 필요합니다.
Node.js: v16+(ESM 지원용)
MCP 지원: 로그 파일을 처리하기 위한 로컬 MCP 파일 서버(mcp-fileserver 또는 동등 제품)
권한: 권한이 있는 스캔(SYN 스캔, OS 감지)의 경우 루트/관리자
지엑스피1
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)
구성 가능한 강도로 서비스 및 버전 감지
OS 지문
NSE 스크립트 실행
사용자 정의 타이밍 템플릿 및 스캔 옵션
다음 옵션을 갖춘 웹 애플리케이션을 위한 디렉토리 및 파일 열거:
다중 단어 목록 및 파일 확장자 스캐닝
인증 옵션(기본 인증, 쿠키)
사용자 정의 가능한 스레딩 및 상태 코드 필터링
TLS 구성 및 리디렉션 후
다음을 지원하는 웹 서버 취약성 스캐닝:
포괄적인 취약성 검사
인증 및 프록시 지원
조정 가능한 스캔 옵션 및 시간 초과 구성
취약점 유형별 분류 찾기
강화된 기능을 갖춘 비밀번호 해독 유틸리티:
단어 목록을 이용한 직접 해시 크래킹
통합 사용자 정의 단어 목록 생성
패턴 기반 비밀번호 생성
Leetspeak와 대소문자 변형
허가된 사용자만 사용: 이 툴킷은 유효한 작업 범위 내에서 작업하는 전문 침투 테스터를 위한 것입니다. 명시적인 서면 허가를 받은 시스템 및 네트워크에서만 사용하십시오.
운영 보안:
외부 스캐닝을 위해 VPN을 사용하세요
격리된 환경에서 실행
민감한 네트워크에서 스캔 강도 모니터링
법률 준수: 모든 해당 법률 및 고객 계약을 준수하십시오.
경로 문제: 모든 도구가 설치되어 있고 PATH에 있는지 확인하세요.
권한 요구 사항: SYN 스캔 및 OS 감지에는 root/admin이 필요합니다.
권한 오류: 서버가 scan_logs 및 temp_wordlists 에 쓸 수 있는지 확인하세요.
MCP 파일 액세스: mcp-fileserver(또는 동등 파일)가 올바르게 구성되었는지 확인하세요.
이 도구는 전문가를 위해 전문가가 만들었습니다. GitHub 저장소 에서 풀 리퀘스트를 환영합니다.
| 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…
