Provides AI assistants with access to NetExec, a network execution and penetration testing tool, via SSH to a Kali Linux machine. Supports protocols like SMB, WinRM, SSH, LDAP, MSSQL, RDP, WMI for enumeration, credential dumping, command execution, password spraying, and more.
Click on "Install 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., "@sec-netexec-mcp Enumerate SMB hosts in 192.168.1.0/24"
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 NetExec (nxc), the powerful network execution and penetration testing tool formerly known as CrackMapExec.
This MCP server enables AI assistants to execute NetExec commands via SSH to a Kali Linux machine, supporting:
Protocol | Capabilities |
SMB | Windows enumeration, credential dumping (SAM/LSA/NTDS), command execution, pass-the-hash |
WinRM | Remote Windows management, PowerShell execution, credential dumping |
SSH | Linux/Unix authentication, key-based auth, remote command execution |
LDAP | Active Directory enumeration, Kerberoasting, ASREPRoast, BloodHound collection |
MSSQL | SQL Server queries, xp_cmdshell execution, login enumeration |
RDP | Credential validation, screenshot capture |
WMI | Windows Management Instrumentation command execution |
Additional features:
Password spraying across all protocols
Module management and execution
SMB share enumeration and file operations
NetExec credential database queries
Related MCP server: redteam-mcp
Node.js 18+
SSH access to a Kali Linux machine with NetExec installed
SSH key-based authentication (recommended) or password
# Clone the repository
git clone https://github.com/schwarztim/sec-netexec-mcp.git
cd sec-netexec-mcp
# Install dependencies
npm install
# Build the project
npm run buildVariable | Description | Default |
| SSH hostname or IP for Kali machine |
|
| SSH username | (none) |
| Path to SSH private key file | (none) |
| Command timeout in seconds |
|
Add to your claude_desktop_config.json:
{
"mcpServers": {
"netexec": {
"command": "node",
"args": ["/path/to/sec-netexec-mcp/dist/index.js"],
"env": {
"KALI_HOST": "your-kali-host",
"SSH_USER": "kali",
"SSH_KEY": "/path/to/ssh/key"
}
}
}
}nxc_smbSMB protocol operations including enumeration, share listing, user/group/session enumeration, credential dumping (SAM, LSA, NTDS), and command execution.
nxc_winrmWinRM remote management for authentication testing, cmd/PowerShell execution, and credential dumping.
nxc_sshSSH protocol for authentication testing, key-based auth, and remote command execution.
nxc_ldapLDAP/Active Directory operations including user/group/computer enumeration, Kerberoasting, ASREPRoast, BloodHound collection, and trust enumeration.
nxc_mssqlSQL Server operations including queries, xp_cmdshell execution, and login enumeration.
nxc_rdpRDP credential validation and screenshot capture.
nxc_wmiWMI-based command execution on Windows targets.
nxc_modulesList and query available NetExec modules for each protocol.
nxc_sprayPassword spraying with configurable options including user/password lists, jitter, and continue-on-success.
nxc_sharesSMB share enumeration and file operations (spider, get, put).
nxc_rawExecute raw NetExec commands for advanced scenarios not covered by other tools.
nxc_databaseQuery the NetExec credential database for stored hosts and credentials.
{
"tool": "nxc_smb",
"arguments": {
"target": "192.168.1.0/24"
}
}{
"tool": "nxc_smb",
"arguments": {
"target": "192.168.1.10",
"username": "admin",
"password": "P@ssw0rd",
"domain": "CORP",
"action": "shares"
}
}{
"tool": "nxc_smb",
"arguments": {
"target": "192.168.1.10",
"username": "admin",
"hash": "aad3b435b51404eeaad3b435b51404ee:5fbc3d5fec8206a30f4b6c473d68ae76",
"domain": "CORP",
"action": "shares"
}
}{
"tool": "nxc_spray",
"arguments": {
"protocol": "smb",
"target": "192.168.1.0/24",
"userList": "/tmp/users.txt",
"password": "Summer2024!",
"domain": "CORP",
"continueOnSuccess": true
}
}{
"tool": "nxc_ldap",
"arguments": {
"target": "dc01.corp.local",
"username": "user",
"password": "password",
"domain": "CORP",
"action": "bloodhound",
"bloodhoundCollection": "All"
}
}{
"tool": "nxc_smb",
"arguments": {
"target": "dc01.corp.local",
"username": "admin",
"password": "P@ssw0rd",
"domain": "CORP",
"action": "ntds"
}
}This tool is intended for authorized security testing only. Always ensure you have:
Written authorization to test target systems
Proper scope definition for penetration testing engagements
Compliance with applicable laws and regulations
Never use this tool against systems you do not have explicit permission to test.
# Watch mode for development
npm run dev
# Build for production
npm run build
# Start the server
npm start┌─────────────────┐ ┌──────────────────┐ ┌────────────────┐
│ AI Assistant │────▶│ NetExec MCP │────▶│ Kali Linux │
│ (Claude, etc.) │ │ Server (Node.js)│ SSH │ (nxc) │
└─────────────────┘ └──────────────────┘ └────────────────┘
│
│ stdio
▼
┌──────────────┐
│ MCP Protocol │
└──────────────┘This project is licensed under the MIT License - see the LICENSE file for details.
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 program. Users are responsible for ensuring compliance with all applicable laws and regulations.
Query the NetExec database for stored credentials and hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | Protocol database to query | |
| action | Yes | Action to perform | |
| exportFormat | No | Export format (for export action) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It implies a read operation but omits whether 'export' action writes files or just formats output. No mention of safety, permissions, 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?
Single sentence with no superfluous content. Efficiently conveys the core purpose.
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?
Lacks information about return values or behavior of each action (hosts, creds, export). With no output schema, the description should elaborate on results but does not. Incomplete for practical use.
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% with all parameters documented adequately. The description adds no extra meaning beyond the schema, warranting the baseline score of 3.
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 'Query the NetExec database for stored credentials and hosts' clearly states the action (query) and resource (database). It implies retrieval of historical data, differentiating it from siblings that perform live protocol operations, though it does not explicitly contrast.
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 sibling tools like nxc_smb or nxc_ldap. The description lacks any indication of prerequisites, typical use cases, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute NetExec LDAP protocol commands for Active Directory enumeration, including users, groups, Kerberoasting, and BloodHound collection.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target domain controller IP or hostname | |
| username | No | Username for authentication | |
| password | No | Password for authentication | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| action | No | Action to perform | |
| bloodhoundCollection | No | BloodHound collection method (All, DCOnly, etc.) | |
| module | No | Module to run (e.g., adcs, daclread, maq) | |
| outputFile | No | Output file path for results | |
| threads | No | Number of concurrent threads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only vs. destructive actions, authentication requirements, rate limits, or side effects. The description simply states 'execute commands' without clarifying impact.
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, concise sentence that front-loads the main purpose. No extraneous information is present.
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 10 parameters, a rich enum, and no output schema, the description is too brief to be fully informative. It fails to explain how actions work, output format, or error handling, making it 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?
The input schema has 100% description coverage for all 10 parameters. The description adds examples of actions (users, groups, etc.) but does not significantly enhance meaning beyond the schema's own descriptions. With full schema coverage, the description's incremental value is limited.
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 NetExec LDAP protocol commands for Active Directory enumeration, listing specific actions like users, groups, Kerberoasting, and BloodHound collection. This distinguishes it from sibling tools that target other protocols (e.g., SMB, RDP).
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 LDAP tool versus alternatives like nxc_smb or nxc_ldap is implied, but no explicit conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or get information about available NetExec modules for a protocol.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | Protocol to list modules for | |
| moduleName | No | Specific module name to get info about |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states 'list or get information' without confirming read-only nature, output format, error handling, or any side effects. This is insufficient for an AI agent to understand implications of invocation.
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, clear sentence with no redundant words. It front-loads the verb and resource, making it efficient for an agent to parse.
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 listing tool, the description gives the core function but lacks details about return values, error cases (e.g., invalid protocol), and pagination or limits. Given no output schema, agents may be uncertain about the response structure.
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% with descriptions for both parameters. The tool description adds context about the operation (list vs get info) but does not provide additional parameter semantics beyond what the schema already offers, meeting the baseline for high 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 clearly states the tool lists or gets information about NetExec modules for a protocol, distinguishing it from sibling tools like nxc_smb or nxc_ldap which focus on specific protocol operations rather than module discovery. However, it does not explicitly contrast with other module-related tools.
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 siblings like nxc_shares or nxc_spray. It does not mention prerequisites, scenarios, or when not to use it, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute NetExec MSSQL protocol commands for SQL Server enumeration and command execution.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target SQL Server IP or hostname | |
| username | No | SQL username (or Windows user) | |
| password | No | Password for authentication | |
| domain | No | Domain for Windows authentication | |
| localAuth | No | Use SQL Server authentication instead of Windows | |
| query | No | SQL query to execute | |
| command | No | OS command to execute via xp_cmdshell | |
| module | No | Module to run (e.g., enum_logins, enum_impersonate) | |
| threads | No | Number of concurrent threads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only vaguely implies command execution; no details on destructive potential, authentication requirements, 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?
Single sentence, front-loaded with purpose, no unnecessary 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 9 parameters and no output schema, the description is too sparse; it omits common use cases, return format, and error behavior.
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 covers 100% of parameters with descriptions, so the tool description adds no extra meaning 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 the tool executes NetExec MSSQL protocol commands for SQL Server enumeration and command execution, distinguishing it from sibling tools focused on other protocols like SMB or 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?
No guidance on when to use this tool versus alternatives; lacks context on prerequisites, typical scenarios, or situations where other tools would be preferred.
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 command with full control over all arguments. Use for advanced scenarios not covered by other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Full nxc command (without 'nxc' prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies full control over arguments but does not disclose potential destructive behavior, side effects, or safety risks. The agent is left unaware of the implications of executing arbitrary NetExec commands.
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: the first defines the purpose, the second provides usage guidance. No redundant or extraneous information. Every sentence 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?
The description covers purpose and usage but lacks details on return values, potential side effects, or prerequisites. Given the tool's raw execution nature and lack of output schema/annotations, more context would be beneficial.
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% as the single parameter is described. The description adds 'full control over all arguments' but this is a general statement, not specific to the parameter. It does not provide additional meaning beyond the schema 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?
The description clearly states 'Execute a raw NetExec command with full control over all arguments', specifying the verb 'Execute' and the resource 'NetExec command'. It also distinguishes from sibling tools by stating 'Use for advanced scenarios not covered by other tools.'
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 explicitly says to use this tool for advanced scenarios not covered by other tools, implying when to use. It does not provide explicit exclusions or list alternative tools, but the contrast is clear given the list of specialized sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute NetExec RDP protocol commands for credential validation and screenshot capture.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP, hostname, or CIDR range | |
| username | No | Username for authentication | |
| password | No | Password for authentication | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| screenshot | No | Take screenshot of RDP session | |
| threads | No | Number of concurrent threads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lacks details on destructive potential, rate limits, authentication behavior, or what 'execute commands' entails, leaving significant ambiguity.
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 concise single sentence with no wasted words. However, it omits important context, so conciseness is a slight penalty for under-specification.
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 no output schema and no annotations, the description fails to explain return values, error handling, or behavioral outcomes. A credential validation tool needs more detail 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?
All 7 parameters have schema descriptions, so baseline is 3. The tool description adds minimal value 'credential validation and screenshot capture' but does not enrich parameter meaning beyond schema defaults.
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 NetExec RDP commands for credential validation and screenshot capture, and distinguishes it from sibling tools that handle other protocols like LDAP, SMB, etc.
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 vs alternatives. No exclusions or context about prerequisites, making it hard for an agent to decide between nxc_rdp and other netexec tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute NetExec SMB protocol commands for Windows enumeration, credential validation, command execution, and credential dumping. Supports pass-the-hash attacks.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP, hostname, CIDR range, or file path containing targets | |
| username | No | Username for authentication | |
| password | No | Password for authentication | |
| hash | No | NTLM hash for pass-the-hash (format: LM:NT or :NT) | |
| domain | No | Domain name for authentication | |
| localAuth | No | Use local authentication instead of domain | |
| action | No | Action to perform | |
| command | No | Command to execute (for exec-cmd or exec-ps actions) | |
| module | No | Module to run (e.g., lsassy, mimikatz, spider_plus) | |
| moduleOptions | No | Module options (key=value format) | |
| continueOnSuccess | No | Continue spraying after successful auth | |
| threads | No | Number of concurrent threads (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions credential dumping and pass-the-hash but does not disclose risks (e.g., account lockout, admin requirements) or non-obvious behaviors. The dangerous actions (sam, lsa, ntds) are listed without warnings.
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 clearly convey purpose and a key feature (pass-the-hash). No redundant information. 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?
For a complex tool with 12 parameters and no output schema, the description is too brief. It omits common usage patterns, error behavior, privilege requirements, and output expectations, leaving the agent under-informed.
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 high-level context (enumeration, validation, etc.) but does not explain when to use specific actions or parameter interactions beyond what the schema already provides.
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 NetExec SMB protocol commands for enumeration, validation, execution, and dumping, and explicitly mentions pass-the-hash. This distinguishes it from sibling tools targeting other protocols (e.g., nxc_ldap, nxc_mssql).
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, no prerequisites, and no scenarios. It only lists capabilities without contextual advice.
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 with configurable options.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | Protocol to use for spraying | |
| target | Yes | Target IP, hostname, CIDR range, or file path | |
| userList | No | Path to file containing usernames (one per line) | |
| username | No | Single username to test | |
| passwordList | No | Path to file containing passwords (one per line) | |
| password | No | Single password to test | |
| domain | No | Domain name | |
| continueOnSuccess | No | Continue after finding valid credentials | |
| nobruteforce | No | Avoid brute force by pairing user:pass from lists | |
| threads | No | Number of concurrent threads | |
| jitter | No | Random delay between connections (e.g., '0-5') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'configurable options' without disclosing the intrusive nature of password spraying, potential account lockouts, or legal implications. The schema parameters have descriptions, but the description adds no behavioral context beyond that.
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, which is concise, but it lacks structure and front-loading of key information. It could benefit from a brief sentence on output or prerequisites.
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 11 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the output format, success indicators, or required target format (e.g., IP vs file). Critical context for a security testing tool is missing.
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% (all 11 parameters have descriptions). The tool description adds no additional parameter semantics, achieving the baseline of 3.
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 performs password spraying attacks across multiple targets, using the verb 'perform' and resource 'spray'. However, it does not distinguish this tool from the many protocol-specific sibling tools (e.g., nxc_smb, nxc_ssh), which also could perform spraying within their protocol.
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 the protocol-specific siblings. It does not mention when not to use it or suggest alternatives, leaving an agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute NetExec SSH protocol commands for Linux/Unix enumeration and command execution.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP, hostname, CIDR range, or file path containing targets | |
| username | No | Username for authentication | |
| password | No | Password for authentication | |
| keyFile | No | Path to SSH private key file | |
| port | No | SSH port (default: 22) | |
| command | No | Command to execute on target | |
| threads | No | Number of concurrent threads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description accurately characterizes the tool as executing commands over SSH, implying network activity and authentication. It does not disclose error handling or side effects, but the core behavior is well communicated.
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?
A single, concise sentence that conveys the tool's purpose without unnecessary words. The structure is front-loaded with the action and resource.
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?
While the description covers the core purpose, it lacks details on return values, error behavior, or prerequisites. With no output schema, some explanation of expected output would improve completeness.
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 significant meaning beyond what the schema provides, other than associating the 'command' parameter with execution. No additional semantic enrichment.
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 verb 'Execute', the resource 'NetExec SSH protocol commands', and the target domain 'Linux/Unix enumeration and command execution'. It effectively distinguishes from sibling tools which target other protocols (SMB, LDAP, etc.).
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 SSH enumeration/execution on Linux/Unix systems but does not explicitly state when to use this tool over alternatives or provide any exclusions. The context is clear due to sibling differentiation, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute NetExec WinRM protocol commands for remote Windows management and command execution.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP, hostname, CIDR range, or file path containing targets | |
| username | No | Username for authentication | |
| password | No | Password for authentication | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name for authentication | |
| action | No | Action to perform | |
| command | No | Command to execute | |
| threads | No | Number of concurrent threads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only vaguely mentions execution without disclosing potential destructive actions, authentication requirements, or rate limits. The action enum includes 'sam' and 'lsa' which imply sensitive operations, yet no warning is given.
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 with no wasted words, but it is too brief, lacking key details. Still, it achieves conciseness without being ambiguous.
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 8 parameters including enums with actions like 'sam' and 'lsa', and no output schema, the description is too sparse to guide the agent on how to use the tool effectively across different actions.
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 itself adds no additional meaning beyond the schema, thus no extra value.
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 NetExec WinRM protocol commands for remote Windows management and command execution, using specific verb ('Execute') and resource ('NetExec WinRM protocol commands'), and distinguishes from siblings by specifying the WinRM protocol.
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 like nxc_smb or nxc_wmi, nor any prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute NetExec WMI protocol commands for Windows management and command execution.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP, hostname, or CIDR range | |
| username | No | Username for authentication | |
| password | No | Password for authentication | |
| hash | No | NTLM hash for pass-the-hash | |
| domain | No | Domain name | |
| command | No | Command to execute | |
| threads | No | Number of concurrent threads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully describe behavioral traits. It only states the basic action (execute commands) without disclosing potential side effects, authentication methods, required permissions, or any destructive nature. The description is too minimal to provide transparency.
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, concise and front-loaded. While it lacks depth, it is not verbose and wastes no 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?
For a command execution tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It fails to explain return values, error handling, security considerations, or any common usage patterns. The description feels 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?
Input schema has 100% description coverage, so each parameter is already documented. The tool description adds no additional meaning beyond the schema, earning a baseline score of 3.
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 NetExec WMI protocol commands for Windows management and command execution. It uses a specific verb and resource and distinguishes itself from sibling tools like nxc_smb or nxc_ldap by naming WMI.
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 (e.g., WinRM, SMB). There is no mention of prerequisites or scenarios where WMI is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct protocol or feature (e.g., LDAP, MSSQL, SMB, spraying) with clear scope. The only potential overlap is between nxc_smb and nxc_shares, but the descriptions differentiate them well (general SMB vs. share enumeration).
All tools follow the consistent 'nxc_<protocol/feature>' pattern, using lowercase with underscores. This uniform naming convention makes the tool set predictable and easy to navigate.
With 12 tools covering major protocols (LDAP, MSSQL, RDP, SMB, SSH, WinRM, WMI) plus auxiliary features (database, modules, shares, spray, raw), the count is well-scoped for a security enumeration/execution server.
The tool set covers core NetExec protocols and common attack vectors (password spraying, credential dumping, command execution). Minor gaps exist (e.g., no explicit Kerberos or FTP tool), but the raw tool provides a fallback for advanced scenarios.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-netexec-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
