What can you do with this server?

The Pentest MCP server provides a unified natural language interface that integrates key penetration testing tools. Capabilities include: * Set working mode: Configure for student or professional use * Network scanning: Run comprehensive Nmap scans with customizable options (SYN scan, OS detection, NSE scripts) * Web directory enumeration: Use Gobuster to discover hidden directories with configurable wordlists and authentication * Web vulnerability scanning: Execute Nikto with tuning options, SSL support, and proxy capabilities * Password cracking: Utilize John the Ripper with custom wordlists * Wordlist management: Generate custom wordlists based on patterns, dates, and transformations * Scan management: Cancel ongoing scans using scan IDs * Workflow automation: Chain tools together for comprehensive assessments * Report generation: Create professional client reports with findings and recommendations

Which integrations are available for this server?

Integrated toolkit optimized for Kali Linux that provides penetration testing capabilities including network reconnaissance, web directory enumeration, vulnerability scanning, and password cracking Requires Node.js v16+ for ESM support to run the penetration testing toolkit server Enables installation of the penetration testing toolkit via npm package management

How do I use Pentest MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pentest MCP scan 10.0.1.0/24 for web servers and run nikto on any found" 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.

de en es ja ko ru zh

Pentest MCP

by DMontgomery40

Overview Schema Related Servers Score Discussions

JavaScript

Local

Pentest MCP

Professional penetration-testing MCP server with modern transport/auth support and expanded recon tooling.

What Changed in 0.9.0

Upgraded MCP SDK to @modelcontextprotocol/sdk@^1.26.0
Kept MCP Inspector at the latest release (@modelcontextprotocol/inspector@^0.20.0) with bundled launcher
Streamable HTTP is now the primary network transport (MCP_TRANSPORT=http)
SSE is still available only as a deprecated compatibility mode
Added bearer-token auth with OIDC JWKS and introspection support
Added first-class tools: subfinderEnum, httpxProbe, ffufScan, nucleiScan, trafficCapture, hydraBruteforce, privEscAudit, extractionSweep
Added report-admin tools: listEngagementRecords, getEngagementRecord
Added SoW capture flow for reports using MCP elicitation (scopeMode=ask) with safe template fallback
Hardened command resolution so web probing uses httpx-toolkit (preferred) or validated ProjectDiscovery httpx, avoiding Python httpx CLI collisions
Integrated bundled MCP Inspector launcher (pentest-mcp inspector)
Runtime baseline is now Node.js 22.7.5+
Added invocation metadata in new tool outputs when auth/session context is available

Related MCP server: pentestMCP

Included Tools

nmapScan
runJohnTheRipper
runHashcat
gobuster
nikto
subfinderEnum
httpxProbe
ffufScan
nucleiScan
trafficCapture
hydraBruteforce
privEscAudit
extractionSweep
generateWordlist
listEngagementRecords
getEngagementRecord
createClientReport
cancelScan

Quick Start

Install

npm install -g pentest-mcp

Run locally (stdio)

pentest-mcp

Launch bundled MCP Inspector (no separate install)

pentest-mcp inspector

You can forward Inspector flags directly:

pentest-mcp inspector --help

Run over network (Streamable HTTP)

MCP_TRANSPORT=http MCP_SERVER_HOST=0.0.0.0 MCP_SERVER_PORT=8000 pentest-mcp

Run legacy SSE mode (deprecated)

MCP_TRANSPORT=sse MCP_SERVER_PORT=8001 pentest-mcp

Transport Notes

stdio: default for local MCP clients.
http: modern network transport. Recommended.
sse: compatibility only. Deprecated and will be removed in a future major release.

Inspector Integration

pentest-mcp inspector launches the bundled @modelcontextprotocol/inspector CLI.
It auto-targets this MCP server over stdio by spawning:
- node <this-package-entrypoint> stdio
You do not need to install Inspector separately.

Auth Configuration (Bearer + OIDC)

Set these env vars when using MCP_TRANSPORT=http (or sse if needed):

MCP_AUTH_ENABLED=true
MCP_AUTH_MODE=bearer
MCP_AUTH_SCOPES=read,write
MCP_AUTH_AUDIENCE=
MCP_OIDC_ISSUER=https://issuer.example.com
MCP_OIDC_JWKS_URL=https://issuer.example.com/.well-known/jwks.json
# optional alternative/backup validation mode:
MCP_OIDC_INTROSPECTION_URL=https://issuer.example.com/oauth/introspect
MCP_OAUTH_CLIENT_ID=...
MCP_OAUTH_CLIENT_SECRET=...

Legacy aliases are still accepted temporarily:

MCP_OAUTH_ENABLED
MCP_OAUTH_PROVIDER_URL
MCP_OAUTH_SCOPES

Workflow + Reporting

createClientReport now supports SoW handling modes:

scopeMode=ask: prompt user via MCP elicitation (recommended)
scopeMode=provided: use scopeOfWork value directly
scopeMode=template: use built-in generic authorized-testing template

If elicitation is declined/unavailable, the report automatically falls back to the template.

How users provide SoW (right now)

There is no separate file-upload API yet. Current options are:

Ask interactively via MCP user invocation (elicitation)

{
  "tool": "createClientReport",
  "arguments": {
    "title": "Q1 External Pentest",
    "assessmentType": "external-network",
    "scopeMode": "ask"
  }
}

Paste SoW text directly into scopeOfWork

{
  "tool": "createClientReport",
  "arguments": {
    "title": "Q1 External Pentest",
    "assessmentType": "external-network",
    "scopeMode": "provided",
    "scopeOfWork": "Authorized targets: ...\nOut-of-scope: ...\nTesting window: ...\nRules of engagement: ..."
  }
}

Use template mode when client details should not be shared

{
  "tool": "createClientReport",
  "arguments": {
    "title": "Q1 External Pentest",
    "assessmentType": "external-network",
    "scopeMode": "template"
  }
}

How this cuts admin time

Every tool run stores a structured engagement record (recordId=...) with invocation context.
Use listEngagementRecords to pull all work artifacts quickly.
Generate the report from selected recordIds (or latest records by default) instead of manual copy/paste.
Scope notes are attached automatically from one of:
- user elicitation form (ask)
- pasted SoW text (provided)
- safe default template (template)

Roadmap

These are planned specifically to reduce pentest admin overhead.

scopeFilePath ingestion (load SoW from a local file path on the MCP host)
scopeDocument chunked upload flow (send SoW content directly through MCP for remote clients)
SoW parser that auto-extracts targets, exclusions, test windows, and rules of engagement
Evidence auto-linking from tool outputs (recordId) to findings and report sections
Finding dedup/merge across overlapping tools (nuclei, nikto, etc.)
Auto severity + impact draft text for faster writeups
One-click report pack generation (executive summary + technical appendix + remediation table)
Retest diff mode (fixed/reopened/new findings between engagements)
Ticket export sync (Jira/Linear/GitHub) with status backfill
Deliverable QA checks (missing evidence, missing scope fields, weak remediation notes)

Adoption note:

Expect strong usage for scopeFilePath and scopeDocument because most teams already maintain SoW in docs/PDF and want to avoid repeated paste-and-reformat steps.

Recon + Exploitation Examples

Subdomain enumeration

{
  "tool": "subfinderEnum",
  "arguments": {
    "domain": "example.com",
    "recursive": true,
    "allSources": true
  }
}

Probe live hosts

{
  "tool": "httpxProbe",
  "arguments": {
    "targets": ["example.com", "api.example.com"],
    "includeTitle": true,
    "includeStatusCode": true
  }
}

Fuzz content paths

{
  "tool": "ffufScan",
  "arguments": {
    "targetUrl": "https://example.com/FUZZ",
    "wordlist": "/usr/share/seclists/Discovery/Web-Content/common.txt",
    "threads": 40
  }
}

Template scanning

{
  "tool": "nucleiScan",
  "arguments": {
    "targets": ["https://example.com"],
    "severities": ["medium", "high", "critical"]
  }
}

Traffic capture (sniffing)

{
  "tool": "trafficCapture",
  "arguments": {
    "networkInterface": "eth0",
    "packetCount": 200,
    "bpfFilter": "tcp port 80"
  }
}

Brute-force checks

{
  "tool": "hydraBruteforce",
  "arguments": {
    "target": "10.10.10.20",
    "service": "ssh",
    "usernameList": "/usr/share/seclists/Usernames/top-usernames-shortlist.txt",
    "passwordList": "/usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt"
  }
}

SQLi extraction sweep

{
  "tool": "extractionSweep",
  "arguments": {
    "targetUrl": "https://target.local/item.php?id=1",
    "risk": 2,
    "level": 3
  }
}

Docker

docker-compose --profile http up
docker-compose --profile stdio up
docker-compose --profile sse up

The Docker image installs:

nmap, john, hashcat, gobuster, nikto, ffuf, hydra, sqlmap, tcpdump
subfinder, httpx + httpx-toolkit alias, nuclei

Required Host Tools (non-Docker runs)

Ensure the binaries are in PATH:

which nmap john hashcat gobuster nikto subfinder httpx-toolkit ffuf nuclei hydra sqlmap tcpdump

If httpx-toolkit is not installed, a validated ProjectDiscovery httpx binary is accepted as fallback.

Security Notice

Authorized use only. Run against systems/networks where you have explicit written permission.

Appendix: MCP in Practice (Code Execution, Tool Scale, and Safety)

Last updated: 2026-03-23

Why This Appendix Exists

Model Context Protocol (MCP) is still one of the most useful interoperability layers for tools and agents. The tradeoff is that large MCP servers can expose many tools, and naive tool-calling can flood context windows with schemas, tool chatter, and irrelevant call traces.

In practice, "more tools" is not always "better outcomes." Tool surface area must be paired with execution patterns that keep token use bounded and behavior predictable.

The Shift to Code Execution / Code Mode

Recent workflows increasingly move complex orchestration out of chat context and into code execution loops. This reduces repetitive schema tokens and makes tool usage auditable and testable.

Core reading:

Recommended Setup for Power Users

For users who want reproducible and lower-noise MCP usage, start with a codemode-oriented setup:

Practical caveat: even with strong setup, model behavior can still be inconsistent across providers and versions. Keep retries, guardrails, and deterministic fallbacks in place.

Peter Steinberger-Style Wrapper Workflow

A high-leverage pattern is wrapping MCP servers into callable code interfaces and task-focused CLIs instead of exposing every raw tool to the model at all times.

Reference tooling:

Client Fit Guide (Short Version)

Claude Code / Codex / Cursor: strong for direct MCP workflows, but still benefit from narrow tool surfaces.
Code execution wrappers (TypeScript/Python CLIs): better when tool count is high or task chains are multi-step.
Hosted chat clients with weaker MCP controls: often safer via pre-wrapped CLIs or gateway tools.

This space changes fast. If you are reading this now, parts of this guidance may already be stale.

Prompt Injection: Risks, Impact, and Mitigations

Prompt injection remains an open security problem for tool-using agents. It is manageable, but not "solved."

Primary risks:

Malicious instructions hidden in tool output or remote content.
Secret exfiltration and unauthorized external calls.
Unsafe state changes (destructive file/system/API actions).

Consequences:

Data leakage, account compromise, financial loss, and integrity failures.

Mitigation baseline:

Least privilege for credentials and tool scopes.
Allowlist destinations and enforce egress controls.
Strict input validation and schema enforcement.
Human confirmation for destructive/high-risk actions.
Sandboxed execution with resource/time limits.
Structured logging, audit trails, and replayable runs.
Output filtering/redaction before model re-ingestion.

Treat every tool output as untrusted input unless explicitly verified.

MCP Compliance State

This server targets MCP protocol version 2025-11-25 and SDK @modelcontextprotocol/sdk@^1.27.1.

Feature	Status
stdio transport	Supported (default)
Streamable HTTP transport	Supported (`MCP_TRANSPORT=http`)
SSE transport (legacy)	Deprecated compatibility mode
Tool annotations	All tools annotated with title, readOnlyHint, destructiveHint, idempotentHint, openWorldHint
Bearer auth (OIDC/JWKS)	Supported
Origin validation (HTTP)	403 on invalid Origin when `MCP_ALLOWED_ORIGINS` is set
JSON Schema 2020-12	Zod-generated schemas
Structured tool errors	isError flag with descriptive messages for model self-correction
Elicitation	Used for SoW capture in report generation

Available Tools

9 tools

cancelScanD

ParametersJSON Schema

Name	Required	Description	Default
`scanId`	Yes	The ID of the scan to cancel

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

createClientReportD

ParametersJSON Schema

Name	Required	Description
`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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

generateWordlistD

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

gobusterD

ParametersJSON Schema

Name	Required	Description
`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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

niktoD

ParametersJSON Schema

Name	Required	Description
`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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

nmapScanD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

runHashcatD

ParametersJSON Schema

Name	Required	Description
`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=WPA01/WPA02
`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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

runJohnTheRipperD

ParametersJSON Schema

Name	Required	Description	Default
`hashData`	Yes	String containing the password hashes, one per line.
`options`	No	Array of command-line options for JtR.

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

setModeD

ParametersJSON Schema

Name	Required	Description	Default
`mode`	Yes

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.6/5.0

Disambiguation3/5

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 Consistency2/5

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.

Tool Count4/5

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.

Completeness3/5

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.

Maintenance

ActivityInactive

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
meok-mcp-hardening-mcp
io.github.CSOAI-ORG
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Penetration Testing Security
1
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237

Related MCP Servers

Pentest Tools MCP Server
Penetration Testing API Testing Security
ch1nhpd
F
license
Not graded
quality
F
maintenance
An MCP server that integrates various penetration testing tools, enabling security professionals to perform reconnaissance, vulnerability scanning, and API testing through natural language commands in compatible LLM clients like Claude Desktop.
Updated a year ago (2025-04-23 07:15 UTC)
7
pentestMCP
Penetration Testing Security Autonomous Agents
RamKansal
F
license
Not graded
quality
B
maintenance
An MCP server that exposes over 20 standard penetration testing utilities, such as Nmap, SQLMap, and OWASP ZAP, as callable tools for AI agents. It enables natural language control over complex security workflows for automated and interactive penetration testing.
Updated 19 days ago (2026-08-16 05:51 UTC)
93
redteam-mcp
Penetration Testing Shell Access
samirjani03
F
license
Not graded
quality
C
maintenance
A penetration testing MCP server that runs 20 hacking tools inside a Kali Linux Docker container, enabling AI assistants to execute security scans and attacks via natural language.
Updated 17 days ago (2026-08-17 09:33 UTC)
2
MCPwner
Penetration Testing Code Analysis
nedlir
A
license
Not graded
quality
A
maintenance
Model Context Protocol server for security research automation, integrating multiple security testing tools into LLM-driven workflows for secret scanning, static analysis, and vulnerability discovery.
Updated 14 days ago (2026-08-20 21:42 UTC)
54
Apache 2.0

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DMontgomery40/pentest-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server