Pentest MCP es un servidor de Protocolo de Contexto de Modelo que integra herramientas esenciales de pentesting en una interfaz unificada de lenguaje natural. Permite a los profesionales de seguridad ejecutar, encadenar y analizar múltiples herramientas mediante comandos conversacionales.
Este kit de herramientas integra cuatro utilidades principales de pruebas de penetración bajo una única interfaz intuitiva:
Reconocimiento de red con Nmap
Enumeración de directorios web con Gobuster
Escaneo de vulnerabilidades web con Nikto
Descifrando contraseñas con John el Destripador
Related MCP server: pentestMCP
Integración del flujo de trabajo: encadene herramientas para realizar evaluaciones integrales
Interfaz de lenguaje natural: ejecute comandos complejos con descripciones simples en inglés
Informes automatizados: genere hallazgos listos para el cliente con la categorización adecuada
Eficiencia de tiempo: ejecute secuencias de pruebas de penetración comunes con una escritura mínima
Compatible con control de voz: cuando se combina con voz a texto, permite la operación con manos libres
Conciencia del contexto: las herramientas comprenden los resultados de análisis anteriores y pueden sugerir próximos pasos lógicos
Plataforma: Funciona en cualquier sistema operativo, optimizado para Kali Linux
Herramientas: Requiere Nmap, John the Ripper, Gobuster y Nikto en su PATH
Node.js: v16+ (para compatibilidad con ESM)
Compatibilidad con MCP: un servidor de archivos MCP local para gestionar archivos de registro (mcp-fileserver o equivalente)
Permisos: Root/admin para escaneos privilegiados (escaneo SYN, detección de SO)
npm install -g pentest-mcpAgregue esto a su archivo de configuración de 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.La integración del mapeador de red ofrece soporte completo para:
Escaneo de puertos (TCP SYN, TCP Connect, UDP) con rangos de puertos personalizados
Detección de servicios y versiones con intensidad configurable
Huellas dactilares del sistema operativo
Ejecución de scripts de NSE
Plantillas de tiempo personalizadas y opciones de escaneo
Enumeración de directorios y archivos para aplicaciones web con opciones para:
Múltiples listas de palabras y escaneo de extensiones de archivos
Opciones de autenticación (autenticación básica, cookies)
Filtrado de código de estado y subprocesos personalizables
Configuración de TLS y redireccionamiento posterior
Escaneo de vulnerabilidades del servidor web con soporte para:
Comprobaciones exhaustivas de vulnerabilidades
Compatibilidad con autenticación y proxy
Opciones de escaneo ajustables y configuración del tiempo de espera
Encontrar la categorización por tipo de vulnerabilidad
Utilidad de descifrado de contraseñas con funciones mejoradas:
Descifrado directo de hashes con listas de palabras
Generación integrada de listas de palabras personalizadas
Creación de contraseñas basadas en patrones
Leetspeak y variaciones de mayúsculas y minúsculas
SOLO PARA USO AUTORIZADO: Este kit de herramientas está dirigido a profesionales de pruebas de penetración que operan bajo un alcance de trabajo válido. Úselo únicamente en sistemas y redes para los que cuente con autorización explícita por escrito.
SEGURIDAD OPERACIONAL:
Utilice VPN para escaneo externo
Ejecutar en entornos aislados
Supervisar la intensidad del escaneo en redes sensibles
CUMPLIMIENTO LEGAL: Cumplir con todas las leyes aplicables y los acuerdos con los clientes.
Problemas de ruta: asegúrese de que todas las herramientas estén instaladas y en su PATH
Requisitos de privilegios: Los escaneos SYN y la detección del sistema operativo requieren root/admin
Errores de permisos: compruebe que el servidor pueda escribir en scan_logs y temp_wordlists
Acceso a archivos MCP: Verifique que mcp-fileserver (o equivalente) esté configurado correctamente
Esta herramienta fue creada por profesionales para profesionales. Se aceptan solicitudes de incorporación de cambios en el repositorio de 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…
