Provides SSH-based access to a Kali Linux host to execute CrackMapExec/NetExec commands for network penetration testing across multiple protocols (SMB, WinRM, SSH, MSSQL, LDAP, RDP, WMI) including enumeration, credential dumping, and command execution.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CrackMapExec MCP Server enumerate SMB shares on 192.168.1.100 with admin:pass123"
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.
A Model Context Protocol (MCP) server that provides AI assistants with access to CrackMapExec/NetExec network penetration testing capabilities via SSH to a Kali Linux host.
This MCP server enables AI-powered network security assessments by exposing CrackMapExec (CME) / NetExec (NXC) functionality through the standardized MCP interface. It supports multiple protocols and comprehensive enumeration, credential dumping, and command execution capabilities.
Related MCP server: redteam-mcp
Protocol | Description |
SMB | Windows file sharing - shares, users, groups, SAM/LSA/NTDS dumping |
WinRM | Windows Remote Management - remote command execution |
SSH | Secure Shell - Linux/Unix command execution |
MSSQL | Microsoft SQL Server - query execution, xp_cmdshell |
LDAP | Active Directory enumeration - users, computers, delegation |
RDP | Remote Desktop Protocol - access validation |
WMI | Windows Management Instrumentation - remote execution |
Enumeration: Shares, users, groups, sessions, computers, domain controllers
Credential Dumping: SAM, LSA secrets, NTDS.dit, gMSA passwords
Command Execution: cmd, PowerShell, via multiple methods (wmiexec, smbexec, atexec)
Password Spraying: Multi-threaded credential testing with jitter support
Module System: Extensible via NetExec modules
Credential Database: Store and search discovered credentials
Node.js 18+
SSH access to a Kali Linux host with NetExec/CrackMapExec installed
SSH key-based authentication configured (recommended)
# Clone the repository
git clone https://github.com/schwarztim/sec-crackmapexec-mcp.git
cd sec-crackmapexec-mcp
# Install dependencies
npm install
# Build
npm run buildVariable | Description | Default |
| Hostname or IP of the Kali Linux host |
|
| SSH username | (none) |
| Path to SSH private key | (none) |
| Binary name ( |
|
Add to your claude_desktop_config.json:
{
"mcpServers": {
"crackmapexec": {
"command": "node",
"args": ["/path/to/sec-crackmapexec-mcp/dist/index.js"],
"env": {
"KALI_HOST": "your-kali-host",
"SSH_USER": "kali",
"SSH_KEY": "/path/to/ssh/key"
}
}
}
}cme_smbExecute SMB protocol operations including share enumeration, user enumeration, credential dumping, and command execution.
// Example: Enumerate shares
{ targets: "192.168.1.0/24", username: "admin", password: "pass123", shares: true }
// Example: Dump SAM hashes
{ targets: "192.168.1.100", username: "admin", password: "pass123", sam: true }cme_winrmExecute commands via Windows Remote Management (ports 5985/5986).
{ targets: "192.168.1.100", username: "admin", password: "pass123", execPowershell: "Get-Process" }cme_sshTest SSH credentials and execute commands on Linux/Unix hosts.
{ targets: "192.168.1.0/24", username: "root", password: "toor", execCmd: "id" }cme_mssqlQuery MSSQL databases and execute OS commands via xp_cmdshell.
{ targets: "192.168.1.50", username: "sa", password: "password", query: "SELECT @@version" }cme_ldapEnumerate Active Directory via LDAP queries.
{ targets: "dc01.domain.local", username: "user", password: "pass", domain: "domain.local", usersEnabled: true }cme_rdpValidate RDP access to targets.
{ targets: "192.168.1.0/24", username: "admin", password: "pass123" }cme_wmiExecute commands via WMI.
{ targets: "192.168.1.100", username: "admin", password: "pass123", execCmd: "whoami" }cme_modulesList available modules for a protocol or get module options.
// List SMB modules
{ protocol: "smb" }
// Get options for specific module
{ protocol: "smb", moduleName: "mimikatz" }cme_sprayPerform password spraying attacks with jitter support.
{
protocol: "smb",
targets: "192.168.1.0/24",
usernames: "users.txt",
passwords: "Summer2024!",
domain: "corp.local",
jitter: "1-3"
}cme_credsManage the NetExec credential database.
// List all credentials
{ action: "list" }
// Search credentials
{ action: "search", searchTerm: "admin" }
// Export credentials
{ action: "export", exportPath: "creds.csv" }cme_rawExecute raw NetExec commands for advanced operations.
{ command: "smb 192.168.1.100 -u admin -p pass123 --shares" }This tool is intended for authorized security testing only. Ensure you have:
Written authorization to test target systems
Proper scope definition for the engagement
Understanding of applicable laws and regulations
Never use this tool against systems without explicit permission.
┌─────────────────┐ SSH ┌─────────────────┐
│ Claude/AI │ ────────────► │ Kali Linux │
│ Assistant │ │ + NetExec │
├─────────────────┤ └─────────────────┘
│ MCP Server │ │
│ (Node.js) │ ▼
└─────────────────┘ ┌─────────────────┐
│ Target Network │
└─────────────────┘# Run in development mode
npm run dev
# Build for production
npm run build
# Start production server
npm startMIT License - see LICENSE file for details.
NetExec - The network execution tool
Model Context Protocol - The MCP specification
MCP SDK - Official MCP SDK
Contributions are welcome! Please feel free to submit a Pull Request.
This software is provided for educational and authorized security testing purposes only. The authors are not responsible for any misuse or damage caused by this tool. Always obtain proper authorization before conducting security assessments.
Manage the NetExec credential database. View, search, and export stored credentials from previous scans.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: list, search, export, clear | |
| searchTerm | No | Search term for credentials | |
| exportPath | No | Path to export credentials |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions view/search/export but omits the 'clear' action from the schema, which is destructive. This incomplete disclosure leaves the agent unaware of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loaded with the main purpose. However, the list of actions is incomplete compared to the schema.
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?
For a simple tool with 3 parameters and no output schema, the description covers basic purpose but omits the destructive 'clear' action, making it partially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description only lists three actions (view, search, export), missing 'clear' which is in the action parameter. This inconsistency adds confusion rather than clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages the NetExec credential database with verbs 'View, search, and export', distinguishing it from sibling tools focused on different protocols or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for credential management after scans but does not explicitly state when to use this tool versus alternatives like cme_spray or protocol-specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute LDAP protocol operations. Supports Active Directory enumeration including users, computers, groups, delegation, and custom LDAP queries.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | Target Domain Controller IP or hostname | |
| username | No | Username or file path to usernames | |
| password | No | Password or file path to passwords | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| kerberosAuth | No | Use Kerberos authentication | |
| port | No | LDAP port (default: 389, 636 for LDAPS) | |
| threads | No | Concurrent threads | |
| usersEnabled | No | Enumerate enabled users | |
| computers | No | Enumerate computers | |
| dc | No | Enumerate domain controllers | |
| trustedForDelegation | No | Find accounts trusted for delegation | |
| passwordNotReqd | No | Find accounts with PASSWD_NOTREQD flag | |
| adminCount | No | Find accounts with adminCount=1 | |
| gmsa | No | Dump gMSA passwords | |
| ldapQuery | No | Custom LDAP query | |
| module | No | Module to run | |
| moduleOptions | No | Module options | |
| verbose | No | Verbose output | |
| debug | No | Debug output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions enumeration but does not clarify whether write operations are supported, authentication requirements, error handling, or potential side effects. This is insufficient for a tool with 20 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the core purpose and follow with examples. No unnecessary words, but could be slightly more structured with bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 20 parameters and no output schema or annotations, the description is incomplete. It does not explain return values, error handling, authentication requirements, or how to use the custom LDAP query parameter. For a complex tool, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond what the schema already provides; it only repeats examples of what can be enumerated, which maps to parameters but adds no new detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes LDAP protocol operations and enumerates Active Directory objects, listing specific examples like users, computers, groups, delegation, and custom queries. This distinguishes it from sibling tools that target other protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for LDAP enumeration but does not explicitly state when to use this tool versus alternatives like cme_smb or cme_mssql. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available modules for a protocol or get options for a specific module.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | Protocol to list modules for: smb, winrm, ssh, mssql, ldap, rdp, wmi, ftp, vnc, nfs | |
| moduleName | No | Module name to get options for (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral traits. It does not disclose whether the operation is read-only, requires authentication, has rate limits, or any side effects. The agent cannot infer safety or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the full purpose without any extraneous words. It is front-loaded with the primary action (list) and clearly structured.
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?
For a simple tool with two parameters and no output schema, the description is adequate but lacks details about return format, examples, or constraints (e.g., protocol must be valid). It does not fully inform an agent about expected outputs or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the dual behavior based on whether moduleName is provided (list vs. get options), which clarifies the parameter semantics beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states two clear actions: listing available modules for a protocol and getting options for a specific module. This clearly distinguishes from sibling tools which focus on executing commands on specific protocols or managing credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when needing to explore modules), but provides no guidance on when not to use, prerequisites (e.g., must have a valid protocol), or alternatives among siblings. It lacks explicit context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute MSSQL protocol operations. Supports SQL query execution and command execution via xp_cmdshell.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | Target IP, hostname, CIDR range, or file path | |
| username | No | Username or file path to usernames | |
| password | No | Password or file path to passwords | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| localAuth | No | Use local authentication | |
| port | No | MSSQL port (default: 1433) | |
| threads | No | Concurrent threads | |
| query | No | SQL query to execute | |
| database | No | Database name | |
| execCmd | No | Execute OS command via xp_cmdshell | |
| module | No | Module to run | |
| moduleOptions | No | Module options | |
| verbose | No | Verbose output | |
| debug | No | Debug output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose critical behavioral traits such as required authentication, destructive potential, or xp_cmdshell prerequisites. The agent receives no warnings about prerequisites like enabling xp_cmdshell or potential blocking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no filler. Every word earns its place.
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?
Despite 15 parameters and no output schema, the description barely covers the tool's capabilities. It omits common usage patterns, parameter dependencies, expected outputs, and prerequisites. The agent lacks sufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. The description adds value by grouping query and execCmd as supported operations, but doesn't elaborate on how parameters like threads or module interact. Still, it provides useful high-level context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes MSSQL protocol operations, supporting SQL queries and command execution via xp_cmdshell. This specific verb and resource distinction effectively sets it apart from sibling tools like cme_smb or cme_ldap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for MSSQL operations, but lacks explicit guidance on when to use this tool versus alternative approaches (e.g., modules vs direct query/execCmd). No when-not-to-use or scenario-based advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a raw NetExec/CrackMapExec command. Use this for advanced operations not covered by other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Raw nxc/crackmapexec command (without the 'nxc' or 'crackmapexec' prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'execute a raw command' without disclosing behavioral traits like authentication requirements, potential destructiveness, output format, or error handling. For a raw command tool, this is a significant gap.
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?
Two sentences, front-loaded with purpose then usage. No superfluous words; every sentence adds value.
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?
Despite low complexity (1 param), the tool can execute arbitrary commands. Description fails to explain potential risks, required permissions, success/failure indicators, or result format. No output schema. Completeness is inadequate for safe usage.
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?
Single parameter 'command' with clear description specifying that the 'nxc' or 'crackmapexec' prefix should be omitted. Adds meaning beyond the schema type, compensating for lack of enums or detail. Schema coverage is 100%, so baseline 3 is exceeded.
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?
Clearly states the action (execute a raw command) and resource (NetExec/CrackMapExec command). Explicitly distinguishes from sibling tools by noting it covers advanced operations not handled by others.
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?
Guides when to use: 'for advanced operations not covered by other tools.' Implies that for common tasks, the specialized sibling tools should be used. Lacks explicit 'when not to use' but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute RDP protocol operations. Check RDP access and screenshot capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | Target IP, hostname, CIDR range, or file path | |
| username | No | Username or file path to usernames | |
| password | No | Password or file path to passwords | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| port | No | RDP port (default: 3389) | |
| threads | No | Concurrent threads | |
| module | No | Module to run | |
| moduleOptions | No | Module options | |
| verbose | No | Verbose output | |
| debug | No | Debug output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'check RDP access and screenshot capabilities' but doesn't disclose read/write behavior, authentication requirements, side effects, or error handling.
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?
Very short (two sentences), no wasted words. Could be slightly more structured, but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 11 parameters and no output schema, the description fails to explain workflow, module usage, or expected results. Incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions, which are basic but present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions RDP and two actions (check access, screenshot capabilities), which is clear but not specific enough to distinguish from other protocol tools. It's adequate but not precise.
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?
No guidance on when to use this tool versus siblings like cme_smb or cme_ssh. No when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute SMB protocol operations with NetExec/CrackMapExec. Supports enumeration of shares, users, groups, sessions, credential dumping (SAM, LSA, NTDS), and command execution.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | Target IP, hostname, CIDR range, or file path | |
| username | No | Username or file path to usernames | |
| password | No | Password or file path to passwords | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| localAuth | No | Use local authentication | |
| kerberosAuth | No | Use Kerberos authentication | |
| port | No | SMB port (default: 445) | |
| threads | No | Concurrent threads | |
| shares | No | Enumerate shares | |
| users | No | Enumerate domain users | |
| groups | No | Enumerate domain groups | |
| loggedOnUsers | No | Enumerate logged on users | |
| sessions | No | Enumerate active sessions | |
| disks | No | Enumerate disks | |
| passPolicy | No | Dump password policy | |
| rid | No | RID brute force enumeration | |
| sam | No | Dump SAM hashes | |
| lsa | No | Dump LSA secrets | |
| ntds | No | Dump NTDS.dit hashes (requires DC) | |
| execCmd | No | Execute cmd command | |
| execPowershell | No | Execute PowerShell command | |
| execMethod | No | Execution method: wmiexec, smbexec, atexec, mmcexec | |
| module | No | Module to run | |
| moduleOptions | No | Module options (KEY=VALUE format) | |
| verbose | No | Verbose output | |
| debug | No | Debug output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It fails to disclose critical behavioral traits such as destructive potential (credential dumping, command execution), authentication requirements, or network impact, leaving the agent without safety or context information.
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?
Two concise sentences that efficiently convey the core purpose and supported operations without redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 27 parameters, no output schema, and no annotations, the description is too simplistic. It does not explain how to combine parameters, expected output format, or prerequisites (e.g., necessary permissions), leaving significant gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds some context by grouping operations into categories (enumeration, dumping, exec) but does not significantly enhance understanding of individual parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Execute SMB protocol operations' and lists specific capabilities (enumeration, credential dumping, command execution), distinguishing it from sibling tools like cme_ldap or cme_ssh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for SMB operations via NetExec, but does not provide when-to-use or when-not-to-use guidance, nor does it compare to alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform password spraying attacks across multiple targets. Supports jitter and continues on success options.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | Protocol to use: smb, winrm, ssh, mssql, ldap, rdp | |
| targets | Yes | Target IP, hostname, CIDR range, or file path | |
| usernames | Yes | Username or file path to usernames | |
| passwords | Yes | Password or file path to passwords | |
| domain | No | Domain name (for AD authentication) | |
| localAuth | No | Use local authentication | |
| threads | No | Concurrent threads | |
| jitter | No | Jitter interval (e.g., '0-5' for 0-5 seconds between connections) | |
| continueOnSuccess | No | Continue spraying after a successful login | |
| noProgress | No | Disable progress bar | |
| verbose | No | Verbose output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions key behaviors (jitter, continue on success) but does not disclose potential risks like account lockouts, rate limiting, or authentication side effects. Adequate but could be improved.
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?
Two sentences, front-loaded with main purpose. Every word earns its place, no unnecessary information.
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?
For a security-sensitive tool with 11 parameters and no annotations, the description is too brief. It lacks details on return values, error handling, output format, and security implications, making it insufficient for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond schema by explaining the overall purpose and providing context for jitter and continueOnSuccess, but does not add new parameter details.
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?
Clearly states the verb 'perform password spraying attacks' and specifies the resource 'multiple targets'. Distinguishes from sibling tools like cme_creds, cme_smb, etc. by focusing on spraying.
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?
Implies usage through the mention of jitter and continue on success options, but lacks explicit guidelines on when to use this tool versus alternatives, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute SSH protocol operations. Supports password and key-based authentication for Linux/Unix hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | Target IP, hostname, CIDR range, or file path | |
| username | No | Username or file path to usernames | |
| password | No | Password or file path to passwords | |
| port | No | SSH port (default: 22) | |
| keyFile | No | Path to SSH private key | |
| sshTimeout | No | SSH timeout in seconds | |
| threads | No | Concurrent threads | |
| execCmd | No | Execute command | |
| module | No | Module to run | |
| moduleOptions | No | Module options | |
| verbose | No | Verbose output | |
| debug | No | Debug output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions password and key-based authentication but does not disclose whether the tool is read-only or destructive, how it handles errors, or what side effects may occur. The presence of execCmd and module parameters suggests command execution capability, which should be highlighted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that directly convey the core purpose and key features. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema, no annotations), the description is insufficient. It does not explain return values, command execution behavior, authentication flow, or how modules work. The agent would need significant inference to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema (e.g., associating password/keyFile with authentication). It does not provide additional context for complex parameters like execCmd or module.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute SSH protocol operations' with a specific verb and resource. It also specifies supported authentication methods (password and key-based) and target OS (Linux/Unix), which distinguishes it from sibling tools like cme_rdp or cme_winrm.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or scenarios where a different sibling tool would be more appropriate. For a tool with many siblings, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute WinRM protocol operations. Supports remote command execution and credential dumping on hosts with WinRM enabled (ports 5985/5986).
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | Target IP, hostname, CIDR range, or file path | |
| username | No | Username or file path to usernames | |
| password | No | Password or file path to passwords | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| localAuth | No | Use local authentication | |
| kerberosAuth | No | Use Kerberos authentication | |
| port | No | WinRM port (5985 HTTP, 5986 HTTPS) | |
| checkProto | No | Check protocol: http or https | |
| httpTimeout | No | HTTP timeout in seconds | |
| threads | No | Concurrent threads | |
| execCmd | No | Execute cmd command | |
| execPowershell | No | Execute PowerShell command | |
| sam | No | Dump SAM hashes | |
| lsa | No | Dump LSA secrets | |
| dumpMethod | No | Dump method: cmd or powershell | |
| module | No | Module to run | |
| moduleOptions | No | Module options | |
| verbose | No | Verbose output | |
| debug | No | Debug output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behaviors. It mentions remote command execution and credential dumping, which imply destructive potential, but it does not detail side effects, permission requirements, or system modifications. The transparency is minimal for a tool with such capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the main purpose and critical details (ports). There is no superfluous information, making it easy to scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, no output schema, no annotations), the description is too brief. It omits typical use cases, dependencies (e.g., WinRM service), and expected outcomes, leaving the agent with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 20 parameters, so the description does not need to add parameter details. The tool description provides no additional meaning beyond the schema, meeting the baseline for good coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute WinRM protocol operations. Supports remote command execution and credential dumping on hosts with WinRM enabled (ports 5985/5986)' clearly states the tool's function and scope, including specific actions and ports. However, it does not explicitly differentiate from sibling tools like cme_smb or cme_ssh, though the protocol-specific name helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when not to use it. It lacks context on prerequisites, such as requiring WinRM service or administrative credentials, and does not mention that sibling tools exist for other protocols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute WMI protocol operations. Supports remote command execution via WMI.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | Target IP, hostname, CIDR range, or file path | |
| username | No | Username or file path to usernames | |
| password | No | Password or file path to passwords | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| localAuth | No | Use local authentication | |
| threads | No | Concurrent threads | |
| execCmd | No | Execute cmd command | |
| execPowershell | No | Execute PowerShell command | |
| module | No | Module to run | |
| moduleOptions | No | Module options | |
| verbose | No | Verbose output | |
| debug | No | Debug output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions remote command execution but omits details on authentication requirements, network prerequisites, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, with no redundant information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and no annotations, the description is too minimal. It fails to explain return values, common use cases, or how to combine parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional context beyond the schema, but the schema already describes each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes WMI protocol operations and supports remote command execution, which differentiates it from sibling tools focused on other protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use WMI versus alternatives like SMB or WinRM. No exclusions or context for selecting this tool over others.
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.
v1.0.0cme_credscme_ldapcme_modulescme_mssqlcme_rawcme_rdpcme_smbcme_spraycme_sshcme_winrmcme_wmiScored across 11 tools
Each tool targets a distinct protocol or operation (e.g., SMB, LDAP, MSSQL, credential management), with clear descriptions that eliminate ambiguity. No overlapping purposes.
All tools follow a consistent `cme_<protocol/function>` naming convention, using lowercase and snake_case, making it predictable and easy to understand.
With 11 tools, the server covers a broad set of protocols and operations (credential management, spraying, multiple protocol executions) without being overwhelming or too sparse.
The surface covers major protocols (SMB, LDAP, MSSQL, RDP, SSH, WinRM, WMI) and key activities like credential dumping, spraying, and raw commands. Minor gaps exist (e.g., Kerberos) but are manageable via the raw tool.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
