Exposes 20+ Kali Linux security tools for performing authorized penetration testing and security assessments, including network scanning, web application testing, password cracking, and exploit database searches.
Provides access to Metasploit's msfvenom payload generator for creating custom exploit payloads in various formats.
Enables packet capture and analysis using Wireshark's CLI tool (tshark) for network traffic inspection.
Integrates WPScan for performing security scans and vulnerability assessments on WordPress installations.
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., "@Kali MCP Server scan ports 22,80,443 on 192.168.1.1 with nmap"
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 production-quality MCP (Model Context Protocol) server that exposes 20+ Kali Linux security tools through an AI-friendly interface, enabling AI assistants to perform penetration testing and security assessments in a controlled, structured manner.
This tool is intended for AUTHORIZED security testing only.
You MUST have explicit written permission to test any systems
Unauthorized access to computer systems is ILLEGAL
Users are responsible for ensuring proper authorization
The authors assume NO LIABILITY for misuse of this tool
By using this tool, you acknowledge that you have proper authorization and accept full responsibility for your actions.
Related MCP server: Kali MCP Server
20+ Security Tools across multiple categories
Type-safe using TypeScript and Zod validation
Safe execution with command allowlists, timeouts, and output limits
Input validation to prevent command injection
Rate limiting to prevent abuse
Structured output with proper error handling
MCP-compliant for seamless AI integration
nmap - Network port scanning and service detection
nmap discover - Host discovery on networks
masscan - High-speed port scanner
netdiscover - ARP reconnaissance
tcpdump - Packet capture
tshark - Wireshark CLI for packet analysis
gobuster dir - Directory/file enumeration
gobuster dns - Subdomain enumeration
sqlmap - SQL injection testing
nikto - Web server scanner
wpscan - WordPress security scanner
ffuf - Web fuzzer
nuclei - Template-based vulnerability scanner
hydra - Network login brute-forcer
john - John the Ripper password cracker
hashcat - Advanced password recovery
searchsploit - Exploit database search
searchsploit examine - View exploit details
msfvenom - Metasploit payload generator
Kali Linux (or any Linux distribution with security tools installed)
Node.js 18+ and npm
Security tools installed on your system
sudo apt update
sudo apt install -y \
nmap masscan netdiscover tcpdump tshark \
gobuster sqlmap nikto wpscan ffuf nuclei \
hydra john hashcat \
exploitdb metasploit-frameworkcd kali-mcp-server
npm install
npm run build# Start the server
npm start
# Or run directly
node dist/index.js# Launch the MCP Inspector for interactive testing
npm run inspector
# Or
npx @modelcontextprotocol/inspector node dist/index.jsAdd to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"kali-security": {
"command": "node",
"args": ["/path/to/kali-mcp-server/dist/index.js"]
}
}
}Perform network port scanning using Nmap.
Example:
{
"target": "192.168.1.1",
"ports": "22,80,443",
"scan_type": "tcp_syn",
"timing": "normal",
"service_version": true
}Parameters:
target (required): IP, hostname, or CIDR range
ports (optional): Port specification (default: top 1000)
scan_type: tcp_syn, tcp_connect, udp, ack, null, fin, xmas
timing: paranoid, sneaky, polite, normal, aggressive, insane
os_detection: Enable OS detection (requires root)
service_version: Probe for service versions
script_scan: NSE scripts to run
aggressive: Enable aggressive scan
timeout: Timeout in seconds (default: 300)
Discover live hosts on a network.
Example:
{
"network": "192.168.1.0/24",
"method": "ping",
"timeout": 120
}Enumerate directories and files on web servers.
Example:
{
"url": "https://example.com",
"wordlist": "/usr/share/wordlists/dirb/common.txt",
"extensions": "php,html,txt",
"threads": 10
}Automated SQL injection testing.
Example:
{
"url": "https://example.com/page?id=1",
"level": 1,
"risk": 1,
"batch": true
}WARNING: Only use on systems you have authorization to test.
Fast network login brute-forcer.
Example:
{
"target": "192.168.1.1",
"service": "ssh",
"username": "admin",
"password_list": "/usr/share/wordlists/rockyou.txt",
"threads": 16
}WARNING: Only use on systems you have authorization to test.
Search the Exploit Database.
Example:
{
"query": "apache 2.4",
"platform": "linux"
}Or search by CVE:
{
"cve": "CVE-2021-44228"
}Generate custom payloads.
Example:
{
"payload": "linux/x64/shell_reverse_tcp",
"lhost": "192.168.1.100",
"lport": 4444,
"format": "elf"
}Only pre-approved commands can be executed. The server maintains a strict allowlist of permitted security tools.
All inputs are validated before execution:
IP addresses and CIDR ranges
Hostnames and URLs
Port numbers and ranges
File paths (no directory traversal)
No shell metacharacters
Sensitive information is automatically redacted from output:
Passwords
API keys
Tokens
Secrets
Timeouts: Configurable per tool (default: 5 minutes)
Output size: Maximum 10MB per command
Rate limiting: 10 commands per minute, 100 per hour
All commands are executed in isolated child processes with:
Separate stdout/stderr capture
Graceful timeout handling
Resource cleanup
Customize tool paths using environment variables:
export NMAP_PATH=/usr/bin/nmap
export GOBUSTER_PATH=/usr/bin/gobuster
export SQLMAP_PATH=/usr/bin/sqlmap
# ... etcDefault wordlists (Kali Linux):
/usr/share/wordlists/rockyou.txt
/usr/share/wordlists/dirb/common.txt
/usr/share/seclists/Discovery/Web-Content/common.txt
The server provides detailed, actionable error messages:
ā Command failed: nmap -sS 192.168.1.1
š¢ Exit code: 1
š Error output:
You requested a scan type which requires root privileges.
Possible causes:
- TCP SYN scan requires root/sudo
- Try using scan_type="tcp_connect" instead
- Run the server with sudo (not recommended)
Suggested actions:
1. Use tcp_connect scan type (doesn't require root)
2. Grant CAP_NET_RAW capability to nmap
3. Check permissions and try againIf tools are not in your PATH:
# Check if tool is installed
which nmap
# Install missing tools
sudo apt install nmap
# Or set custom path
export NMAP_PATH=/custom/path/to/nmapSome tools require root privileges:
nmap TCP SYN scan (-sS)
masscan
tcpdump/tshark
netdiscover
Solutions:
Use non-privileged alternatives (e.g., nmap TCP connect scan)
Grant specific capabilities: sudo setcap cap_net_raw+ep /usr/bin/nmap
Run server with sudo (not recommended for security reasons)
If scans are timing out:
{
"target": "192.168.1.1",
"ports": "1-65535",
"timeout": 1800 // Increase to 30 minutes
}kali-mcp-server/
āāā src/
ā āāā index.ts # Main server
ā āāā types.ts # Type definitions
ā āāā constants.ts # Configuration
ā āāā utils/
ā ā āāā executor.ts # Command execution
ā ā āāā validator.ts # Input validation
ā ā āāā formatter.ts # Output formatting
ā ā āāā parser.ts # Output parsing
ā āāā tools/
ā ā āāā network.ts # Network tool handlers
ā ā āāā web.ts # Web tool handlers
ā ā āāā password.ts # Password tool handlers
ā ā āāā exploit.ts # Exploit tool handlers
ā āāā schemas/
ā āāā network.schemas.ts
ā āāā web.schemas.ts
ā āāā password.schemas.ts
ā āāā exploit.schemas.ts
āāā dist/ # Compiled outputDefine Zod schema in src/schemas/[category].schemas.ts
Implement tool handler in src/tools/[category].ts
Register tool in src/index.ts
Add to ALLOWED_COMMANDS in src/constants.ts
Example:
// 1. Schema
export const MyToolSchema = z.object({
target: z.string().describe("Target to scan"),
option: z.boolean().default(false),
});
// 2. Handler
export async function myTool(input: MyToolInput): Promise<ToolResult> {
const args = [input.target];
if (input.option) args.push("--option");
const result = await executeCommand("mytool", args);
return formatExecutionResult(result);
}
// 3. Register in index.ts
{
name: "kali_category_mytool_action",
description: "Description of what it does",
inputSchema: zodToJsonSchema(MyToolSchema),
}
// 4. Add to ALLOWED_COMMANDS
export const ALLOWED_COMMANDS = new Set([
// ... existing commands
"mytool",
]);npm run build
npm startTest with MCP Inspector:
npm run inspector1. Discover hosts: kali_network_nmap_discover
2. Port scan: kali_network_nmap_scan
3. Service detection: kali_network_nmap_scan with service_version=true
4. Vulnerability scan: kali_network_nmap_scan with script_scan="vuln"1. Directory enumeration: kali_web_gobuster_dir
2. Subdomain discovery: kali_web_gobuster_dns
3. Vulnerability scanning: kali_web_nikto_scan
4. SQL injection testing: kali_web_sqlmap_test1. Network brute force: kali_password_hydra_brute
2. Hash identification: Manual analysis
3. Hash cracking: kali_password_john_crack or kali_password_hashcat_crack1. Search exploits: kali_exploit_searchsploit_search
2. Examine exploit: kali_exploit_searchsploit_examine
3. Generate payload: kali_exploit_msfvenom_generateUse appropriate timing: Balance speed vs stealth
Limit port ranges: Scan only necessary ports
Use wordlists wisely: Smaller wordlists for faster results
Adjust threads: More threads = faster, but more resource-intensive
Set realistic timeouts: Complex scans need more time
Contributions are welcome! Please ensure:
All inputs are validated
Commands are in the allowlist
Error messages are actionable
Documentation is updated
Security best practices are followed
MIT License - See LICENSE file for details
Kali Linux team for the excellent security distribution
Anthropic for the Model Context Protocol
Security tool authors: nmap, gobuster, sqlmap, hydra, john, hashcat, and many more
This tool 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 ensure you have proper authorization before testing any systems.
Version: 1.0.0 Last Updated: 2025-11-29
Generate custom payloads for Metasploit Framework.
Msfvenom is a payload generator and encoder combining msfpayload and msfencode.
WARNING: Only use generated payloads for authorized security testing.
Common Payloads:
windows/meterpreter/reverse_tcp
linux/x64/shell_reverse_tcp
php/meterpreter/reverse_tcp
Example:
payload="linux/x64/shell_reverse_tcp", lhost="192.168.1.100", lport=4444, format="elf"
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Payload type (e.g., 'windows/meterpreter/reverse_tcp', 'linux/x64/shell_reverse_tcp') | |
| lhost | Yes | Local host IP for reverse connections | |
| lport | Yes | Local port for reverse connections | |
| format | No | Output format | raw |
| arch | No | Target architecture | |
| platform | No | Target platform | |
| encoder | No | Encoder to use (e.g., 'x86/shikata_ga_nai') | |
| iterations | No | Number of encoding iterations | |
| output_file | No | Output file path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool generates payloads and includes a security warning, but does not detail behavioral traits like required permissions, rate limits, or what the output looks like. The example gives some context, but more operational details would be helpful.
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 well-structured with clear sections (warning, common payloads, example) and avoids unnecessary verbosity. Every sentence adds value, such as the security warning and practical examples, making it efficient and easy to scan.
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 complexity of a payload generation tool with 9 parameters, no annotations, and no output schema, the description is moderately complete. It covers purpose, security context, and examples, but lacks details on output format, error handling, or integration with other tools, leaving some gaps for an AI agent.
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 schema already documents all parameters thoroughly. The description adds minimal value by listing common payload examples and an example usage, but does not provide additional semantics beyond what the schema specifies. Baseline 3 is appropriate given high schema 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's purpose with specific verbs ('Generate custom payloads') and resources ('for Metasploit Framework'), distinguishing it from sibling tools focused on scanning, fuzzing, or cracking. It explicitly mentions msfvenom's role as a payload generator and encoder, making its function unambiguous.
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 clear context with a warning for authorized use only, but does not explicitly state when to use this tool versus alternatives or mention any prerequisites. It lists common payloads and an example, which helps guide usage, but lacks direct comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Examine and display the contents of an exploit from searchsploit results.
| Name | Required | Description | Default |
|---|---|---|---|
| exploit_id | Yes | Exploit ID or path from searchsploit results | |
| color | No | Enable color output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Examine and display the contents' but lacks details on output format (e.g., text, code), potential side effects (e.g., if it runs or just views exploit code), permissions needed, or error handling, which are critical for a tool interacting with exploit data.
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, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized for its purpose, though it could be slightly more front-loaded with key details like output type to enhance clarity.
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 complexity of handling exploits, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'display the contents' entails (e.g., code preview, metadata), potential risks, or how results are formatted, leaving significant gaps for safe and effective tool 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?
The input schema has 100% description coverage, clearly documenting both parameters ('exploit_id' and 'color'). The description adds no additional parameter semantics beyond what the schema provides, such as examples of exploit IDs or color output effects, so it meets the baseline for high schema coverage without 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 action ('Examine and display the contents') and resource ('an exploit from searchsploit results'), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling 'kali_exploit_searchsploit_search', which might search for exploits rather than examine specific ones, leaving some ambiguity in sibling distinction.
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. It doesn't mention prerequisites (e.g., needing searchsploit results first), exclusions, or comparisons with sibling tools like 'kali_exploit_searchsploit_search', leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Exploit Database for public exploits and vulnerability information.
SearchSploit is a command-line search tool for Exploit-DB.
Search Options:
By software name/version
By CVE identifier
By platform (linux, windows, php, etc.)
By exploit type (local, remote, webapps, dos)
Example:
query="apache 2.4", platform="linux"
cve="CVE-2021-44228"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (software name, version, or keyword) | |
| exact | No | Exact match only | |
| cve | No | Search by CVE ID (e.g., 'CVE-2021-1234') | |
| platform | No | Filter by platform (e.g., 'linux', 'windows', 'php') | |
| type | No | Filter by exploit type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that SearchSploit is a 'command-line search tool,' which implies read-only behavior, but does not disclose critical traits like whether it requires authentication, rate limits, or what the output format looks like (e.g., list of exploits, details). This is inadequate for a search tool with no annotation coverage.
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 well-structured with a clear purpose statement, bullet points for search options, and examples. It is appropriately sized and front-loaded, though the example section could be more concise. Overall, it avoids unnecessary verbosity.
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 no annotations and no output schema, the description provides basic purpose and parameter guidance but lacks details on behavioral traits (e.g., output format, error handling) and usage distinctions from siblings. It is minimally viable for a search tool but has clear gaps in 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 description coverage is 100%, so the schema already documents all parameters. The description adds value by listing 'Search Options' that map to parameters (e.g., platform, type, cve) and providing examples, but does not explain parameter interactions or constraints beyond what the schema provides. Baseline 3 is appropriate given high schema 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's purpose: 'Search the Exploit Database for public exploits and vulnerability information.' It specifies the verb 'search' and the resource 'Exploit Database,' distinguishing it from siblings like kali_exploit_msfvenom_generate (generate exploits) and kali_exploit_searchsploit_examine (examine exploits).
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 through the 'Search Options' section, listing scenarios like searching by software name, CVE, platform, or exploit type. However, it does not explicitly state when to use this tool versus alternatives (e.g., kali_exploit_searchsploit_examine) or provide exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
High-speed port scanner capable of scanning the entire internet in minutes. Use with caution and proper authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP, range, or CIDR (e.g., '192.168.1.0/24', '10.0.0.1-10.0.0.255') | |
| ports | Yes | Port range (e.g., '1-1000', '22,80,443', '0-65535') | |
| rate | No | Packet transmission rate (packets/second, default: 1000) | |
| banners | No | Grab banners from services | |
| timeout | No | Scan timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'high-speed' and 'capable of scanning the entire internet in minutes', which hints at performance, and 'Use with caution and proper authorization' implies potential risks. However, it lacks details on output format, error handling, rate limits, or specific destructive impacts (e.g., network disruption), leaving significant gaps for a powerful scanning tool.
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 highly concise and front-loaded, with two sentences that efficiently convey the tool's capability and a critical warning. Every sentence earns its place without redundancy or unnecessary elaboration, making it easy to parse 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 (high-speed scanning with potential network impact), lack of annotations, and no output schema, the description is incomplete. It misses details on behavioral traits (e.g., what results look like, error cases), usage nuances compared to siblings, and fails to fully address risks beyond a generic caution, leaving the agent under-informed for safe and effective 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?
The input schema has 100% description coverage, providing clear details for all 5 parameters (target, ports, rate, banners, timeout). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting, but doesn't compensate with extra context.
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 as a 'high-speed port scanner' with the capability to 'scan the entire internet in minutes', which is specific and distinguishes it from general scanning tools. However, it doesn't explicitly differentiate from sibling tools like 'kali_network_nmap_scan' or 'kali_network_netdiscover_scan' beyond the high-speed aspect.
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 implied usage guidance with 'Use with caution and proper authorization', which suggests ethical and legal considerations. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to nmap_scan for detailed analysis or netdiscover_scan for local network discovery), and no specific exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ARP reconnaissance tool for discovering hosts on a local network. Supports active and passive modes.
| Name | Required | Description | Default |
|---|---|---|---|
| interface | No | Network interface to use (e.g., 'eth0', 'wlan0') | |
| range | No | IP range to scan (e.g., '192.168.1.0/24') | |
| passive | No | Passive mode (sniff packets without sending ARP requests) | |
| timeout | No | Scan timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'active and passive modes' and that it's an 'ARP reconnaissance tool,' which gives some context about network scanning behavior. However, it lacks details on permissions needed, potential network impact, output format, or rate limits, which are critical for a network scanning tool with no structured safety hints.
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 with two sentences that directly state the tool's function and key feature (modes). It's front-loaded with the core purpose and avoids any redundant or unnecessary information, making it efficient and easy 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?
Given the complexity of a network scanning tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like output format, error handling, or security implications, which are essential for proper tool invocation. The high schema coverage helps with parameters, but overall context is lacking for safe and effective 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?
The input schema has 100% description coverage, so parameters are well-documented in the schema itself. The description adds minimal value beyond the schema by implying the tool's mode (active/passive) relates to parameters, but it doesn't provide additional syntax, format, or usage details for the parameters. This meets the baseline of 3 when schema coverage is high.
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 as an 'ARP reconnaissance tool for discovering hosts on a local network,' which specifies the verb (discovering), resource (hosts), and scope (local network). However, it doesn't explicitly differentiate from sibling tools like 'kali_network_nmap_discover' or 'kali_network_masscan_scan,' which likely have overlapping network discovery functions.
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 by mentioning 'active and passive modes,' suggesting when to choose between them, but it doesn't provide explicit guidance on when to use this tool versus alternatives like nmap or masscan for network scanning. No exclusions or prerequisites are stated, leaving the agent to infer context from the tool's name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover live hosts on a network using Nmap. Supports ping, ARP, TCP, UDP, and ICMP discovery methods.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Network range in CIDR notation (e.g., '192.168.1.0/24') | |
| method | No | Discovery method (arp requires root and local network) | ping |
| timeout | No | Discovery timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's purpose and supported methods, adding value beyond the schema. However, it lacks details on behavioral traits like whether it's read-only/destructive, permission requirements (beyond ARP note in schema), rate limits, output format, or network impact. The description doesn't contradict annotations since none exist.
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, efficient sentence that front-loads the core purpose ('Discover live hosts on a network using Nmap') and adds necessary detail about methods. Every word earns its place with zero waste, making it easy to parse 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 moderate complexity (network scanning with multiple methods), no annotations, and no output schema, the description is adequate but has gaps. It covers the what and how at a high level but lacks details on behavioral context (e.g., safety, permissions beyond ARP), output format, or error handling. It's minimally viable but not fully comprehensive for an unannotated 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%, providing clear documentation for all 3 parameters. The description adds minimal value by mentioning the methods (ping, ARP, TCP, UDP, ICMP), which relates to the 'method' parameter but doesn't explain semantics beyond what the schema already covers. This meets the baseline of 3 for high schema 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 specific action ('Discover live hosts') and resource ('on a network') using the tool 'Nmap'. It distinguishes from siblings like 'kali_network_nmap_scan' by focusing on host discovery rather than comprehensive scanning, and from 'kali_network_masscan_scan' by specifying Nmap's methods.
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 clear context by listing supported discovery methods (ping, ARP, TCP, UDP, ICMP), which helps understand when to use this tool. However, it doesn't explicitly state when to choose this over alternatives like 'kali_network_nmap_scan' or 'kali_network_masscan_scan', nor does it mention exclusions or prerequisites beyond the ARP method note in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform network port scanning using Nmap.
Nmap (Network Mapper) is a powerful network scanner for discovering hosts, services, and potential vulnerabilities.
Capabilities:
TCP SYN, Connect, UDP, and stealth scans
Service version detection (-sV)
OS fingerprinting (-O, requires root)
NSE script execution
Multiple output formats
Usage Notes:
TCP SYN scan requires root privileges
Use appropriate timing for stealth vs speed
Large port ranges increase scan time significantly
Example:
Quick scan: target="192.168.1.1", ports="22,80,443"
Full scan: target="10.0.0.0/24", ports="-", timing="aggressive"
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP address, hostname, or CIDR range (e.g., '192.168.1.1', 'example.com', '10.0.0.0/24') | |
| ports | No | Port specification (e.g., '22', '1-1000', '22,80,443', '-' for all ports). Default: top 1000 ports | |
| scan_type | No | Nmap scan type (tcp_syn requires root) | tcp_syn |
| timing | No | Timing template: paranoid (T0) to insane (T5) | normal |
| os_detection | No | Enable OS detection (-O, requires root) | |
| service_version | No | Probe for service versions (-sV) | |
| script_scan | No | NSE script(s) to run (e.g., 'vuln', 'default', 'http-*') | |
| aggressive | No | Enable aggressive scan (-A: OS, version, script, traceroute) | |
| output_format | No | Output format | text |
| timeout | No | Scan timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: root requirements for certain scans, performance implications ('Large port ranges increase scan time significantly'), and practical constraints like timing trade-offs. It doesn't cover everything (e.g., network impact, error handling) but adds substantial value beyond basic functionality.
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 well-structured with clear sections (Capabilities, Usage Notes, Example), front-loaded with the core purpose, and every sentence adds value without redundancy. It's appropriately sized for a complex tool with 10 parameters, efficiently conveying essential information in a digestible format.
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 (10 parameters, no annotations, no output schema), the description is largely completeāit covers purpose, behavioral traits, and usage context. However, it lacks details on output format interpretation or error scenarios, which would be helpful since there's no output schema. Still, it provides sufficient guidance for effective 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%, so the schema already documents all 10 parameters thoroughly. The description adds minimal parameter semantics beyond the schemaāit mentions 'ports' and 'timing' in examples but doesn't explain parameter interactions or provide additional context. Baseline 3 is appropriate as the schema does the heavy lifting.
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 as 'Perform network port scanning using Nmap' with specific verbs ('scanning', 'discovering') and resources ('hosts', 'services', 'vulnerabilities'). It distinguishes from sibling tools like kali_network_masscan_scan by specifying Nmap's unique capabilities (e.g., OS fingerprinting, NSE scripts) that other scanning tools may not offer.
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 clear context for when to use this tool through 'Usage Notes' (e.g., 'TCP SYN scan requires root privileges', 'Use appropriate timing for stealth vs speed'), and examples illustrate different scenarios. However, it doesn't explicitly compare to alternatives like kali_network_nmap_discover or kali_network_masscan_scan, missing explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture network packets for analysis. Supports BPF filters and can save to PCAP files.
| Name | Required | Description | Default |
|---|---|---|---|
| interface | Yes | Network interface to capture on (e.g., 'eth0', 'wlan0', 'any') | |
| filter | No | BPF filter expression (e.g., 'port 80', 'host 192.168.1.1') | |
| count | No | Number of packets to capture (default: unlimited) | |
| duration | No | Capture duration in seconds | |
| output_file | No | Output file path (.pcap format) | |
| verbose | No | Verbose output |
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 behavioral aspects like supporting BPF filters and saving to PCAP files, but lacks critical details: it doesn't state if this requires elevated privileges (e.g., root), whether it's destructive or read-only, potential performance impacts, or output format beyond file saving. For a network capture tool with zero annotation coverage, this is insufficient.
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, efficient sentence with zero waste. It's front-loaded with the core purpose and includes only essential additional capabilities. Every word earns its place, making it easy to parse 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 (network packet capture with 6 parameters) and lack of annotations/output schema, the description is moderately complete. It covers the high-level purpose and key features but misses critical behavioral context (e.g., permissions, side effects). With no output schema, it also doesn't describe return values, leaving gaps for agent 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 parameters are well-documented in the schema. The description adds minimal value beyond the schemaāit mentions BPF filters and PCAP files, which relate to the 'filter' and 'output_file' parameters but don't provide additional semantics. Baseline 3 is appropriate when the schema does the heavy lifting.
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: 'Capture network packets for analysis.' It specifies the action (capture) and resource (network packets), and mentions key capabilities (BPF filters, PCAP file saving). However, it doesn't explicitly differentiate from its sibling 'kali_network_tshark_capture', which likely serves a similar packet capture function.
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. It doesn't mention sibling tools like 'kali_network_tshark_capture' for comparison, nor does it specify prerequisites, contexts, or exclusions for usage. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wireshark CLI for packet capture and analysis with advanced filtering and multiple output formats.
| Name | Required | Description | Default |
|---|---|---|---|
| interface | Yes | Network interface to capture on | |
| filter | No | Display filter (e.g., 'http', 'tcp.port == 80') | |
| count | No | Number of packets to capture | |
| duration | No | Capture duration in seconds | |
| fields | No | Fields to display (e.g., ['ip.src', 'ip.dst', 'tcp.port']) | |
| output_format | No | Output format | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'capture and analysis' and 'advanced filtering' but lacks critical behavioral details: whether this requires elevated privileges, what happens during capture (e.g., network disruption), output characteristics, error conditions, or rate limits. For a network capture tool with zero annotation coverage, 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?
The description is a single, efficient sentence that communicates the core functionality. It's appropriately sized for the tool's complexity, though it could be more front-loaded with critical behavioral information given the lack of annotations.
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 network packet capture tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address security implications, privilege requirements, output structure, or error handling. The description provides basic purpose but lacks the contextual depth needed for safe and effective use of this potentially privileged network 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 the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'advanced filtering' which relates to the 'filter' parameter and 'multiple output formats' which relates to 'output_format', but provides no additional syntax, format details, or usage examples 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 clearly states the tool's purpose as 'packet capture and analysis' using Wireshark CLI, specifying the core action and resource. It distinguishes from some siblings by focusing on packet analysis rather than scanning or exploitation, though it doesn't explicitly differentiate from the similar 'kali_network_tcpdump_capture' tool.
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 explicit guidance is provided on when to use this tool versus alternatives. The description mentions 'advanced filtering and multiple output formats' which implies capabilities, but doesn't specify scenarios, prerequisites, or compare it to the similar tcpdump_capture sibling tool. Usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced password recovery tool using GPU acceleration. Supports 300+ hash types.
| Name | Required | Description | Default |
|---|---|---|---|
| hash_file | Yes | File containing password hashes | |
| mode | Yes | Hash type mode (e.g., 0=MD5, 100=SHA1, 1000=NTLM, 1400=SHA256) | |
| attack_type | No | Attack mode | dictionary |
| wordlist | No | Wordlist file for dictionary attack | |
| mask | No | Mask for brute-force attack (e.g., '?a?a?a?a?a?a?a?a') | |
| rules | No | Rules file | |
| timeout | No | Cracking timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions GPU acceleration and hash type support, but lacks critical details such as required permissions, whether it's destructive (likely yes for password cracking), performance characteristics, error handling, or output format. This leaves significant gaps for an agent to understand the tool's behavior.
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 efficiently convey key features. It's front-loaded with the main purpose and avoids unnecessary details, though it could be slightly more structured by explicitly stating the tool's action (cracking).
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 complexity of a password cracking tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It misses behavioral context (e.g., destructive nature, resource usage), usage guidelines relative to siblings, and output expectations, making it inadequate for an agent to fully understand the tool's operation.
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 schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters like attack_type and wordlist/mask). Baseline 3 is appropriate as the schema does the heavy lifting.
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 as 'Advanced password recovery tool using GPU acceleration' with the specific action 'crack' implied in the name. It distinguishes from some siblings (e.g., kali_password_hydra_brute focuses on brute-force attacks, kali_password_john_crack is another cracker) by mentioning GPU acceleration and 300+ hash type support, though it doesn't explicitly contrast with all password-related siblings.
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 explicit guidance on when to use this tool versus alternatives like kali_password_hydra_brute or kali_password_john_crack is provided. The description mentions general features (GPU acceleration, hash types) but doesn't specify scenarios, prerequisites, or exclusions for choosing 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.
Fast network login brute-forcer supporting many protocols.
Hydra is a parallelized login cracker which supports numerous protocols.
Supported Services:
SSH, FTP, HTTP(S), MySQL, SMB, RDP, Telnet, and more
WARNING: Only use on systems you have authorization to test.
Example:
SSH: target="192.168.1.1", service="ssh", username="admin", password_list="/usr/share/wordlists/rockyou.txt"
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target host or IP address | |
| service | Yes | Service to attack | |
| username | No | Single username to test | |
| username_list | No | File containing usernames (one per line) | |
| password | No | Single password to test | |
| password_list | No | File containing passwords (one per line) | |
| port | No | Custom port number | |
| threads | No | Number of parallel connections | |
| timeout | No | Scan timeout in seconds | |
| verbose | No | Verbose output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing critical behavioral traits: it's a brute-force attack tool (destructive by nature), requires authorization, supports parallel connections (implied by 'parallelized'), and provides protocol specifics. However, it doesn't mention rate limits, error handling, or output format.
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 efficiently structured with clear sections (overview, supported services, warning, example), uses bold formatting effectively, and every sentence adds value without redundancy. The example is particularly helpful for understanding practical usage.
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 10-parameter brute-force tool with no annotations or output schema, the description provides good context about what the tool does, authorization requirements, and protocol support. However, it lacks information about return values, error conditions, and how results are presented to the agent.
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?
With 100% schema description coverage, the baseline is 3. The description adds some value through the example showing parameter usage patterns (target, service, username, password_list), but doesn't provide additional semantic context beyond what's already documented in the comprehensive 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's purpose as a 'parallelized login cracker' and 'network login brute-forcer' with specific protocol support, distinguishing it from sibling password tools like hashcat_crack and john_crack which focus on offline hash cracking rather than network login attacks.
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 clear context with the authorization warning and example usage, but doesn't explicitly state when to choose this tool over alternatives like kali_password_hashcat_crack or kali_password_john_crack for different attack scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
John the Ripper password cracker supporting many hash formats and attack modes.
| Name | Required | Description | Default |
|---|---|---|---|
| hash_file | Yes | File containing password hashes | |
| format | No | Hash format (e.g., 'md5', 'sha256', 'des', 'nt') | |
| wordlist | No | Wordlist file for dictionary attack | |
| rules | No | Mangling rules to apply | |
| incremental | No | Use incremental mode (brute force) | |
| timeout | No | Cracking timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'password cracker' which implies a resource-intensive, potentially long-running operation, but doesn't disclose critical traits like performance expectations, output format, error handling, or system impact. The mention of 'attack modes' is vague without elaboration.
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, efficient sentence that communicates the core purpose without waste. It's appropriately sized for a tool with good schema documentation, though it could be slightly more front-loaded with key behavioral context.
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 password cracking tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (cracked passwords? success/failure?), doesn't warn about resource usage or ethical considerations, and provides minimal behavioral context despite the tool's 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 the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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: 'John the Ripper password cracker' specifies the verb (crack) and resource (passwords), and 'supporting many hash formats and attack modes' adds useful context. It distinguishes from siblings like 'kali_password_hashcat_crack' by naming a specific tool (John the Ripper), but doesn't explicitly contrast their differences.
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 'kali_password_hashcat_crack' or 'kali_password_hydra_brute'. The description mentions 'many hash formats and attack modes' which implies versatility, but doesn't specify scenarios, prerequisites, or exclusions for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast web fuzzer for discovering hidden files, directories, and parameters. URL must contain FUZZ keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL with FUZZ keyword (e.g., 'https://example.com/FUZZ') | |
| wordlist | No | Wordlist file path | /usr/share/wordlists/dirb/common.txt |
| method | No | HTTP method | GET |
| headers | No | Custom headers as key-value pairs | |
| data | No | POST data | |
| match_codes | No | Match HTTP status codes | 200,204,301,302,307,401,403,405,500 |
| filter_codes | No | Filter HTTP status codes | |
| threads | No | Number of concurrent threads | |
| timeout | No | Scan timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is 'fast' and for 'discovering', which implies it's a scanning/read operation, but it lacks details on potential destructive effects (e.g., if it might trigger security alerts), authentication needs, rate limits, or output format. This leaves gaps in understanding its behavior beyond the basic purpose.
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 front-loaded and concise with two sentences that directly state the purpose and a key requirement (FUZZ keyword). There is no wasted text, and every sentence earns its place by providing essential information efficiently.
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 complexity (9 parameters, no output schema, no annotations), the description is somewhat complete for basic usage but lacks depth. It covers the purpose and a critical constraint (FUZZ keyword), but without annotations or output schema, it misses behavioral traits like safety, performance implications, or result interpretation, which are important for a fuzzing 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 schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond the schema by implying the FUZZ keyword usage, but it does not provide additional semantics or context for parameters like default behaviors or interactions. Baseline 3 is appropriate as the schema does the heavy lifting.
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 with specific verbs ('fuzz', 'discovering') and resources ('hidden files, directories, and parameters'), and it distinguishes itself from sibling tools like kali_web_gobuster_dir by specifying it's a 'fast web fuzzer' that requires the FUZZ keyword in the URL, which is unique among the listed web 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 clear context for usage by stating the URL must contain the FUZZ keyword, which implicitly guides when to use this tool (for fuzzing with that keyword). However, it does not explicitly mention when not to use it or name alternatives like kali_web_gobuster_dir, which could help differentiate further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate directories and files on web servers using wordlists.
Gobuster is a fast directory/file brute-forcing tool written in Go.
Features:
Fast multi-threaded scanning
Customizable file extensions
Status code filtering
Recursive scanning support
Example:
Basic: url="https://example.com", wordlist="/usr/share/wordlists/dirb/common.txt"
With extensions: url="https://example.com", extensions="php,html,txt"
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL (e.g., 'https://example.com') | |
| wordlist | No | Wordlist file path | /usr/share/wordlists/dirb/common.txt |
| extensions | No | File extensions to append (e.g., 'php,html,txt') | |
| threads | No | Number of concurrent threads | |
| status_codes | No | Positive status codes (comma-separated) | 200,204,301,302,307,401,403 |
| timeout | No | Scan timeout in seconds | |
| user_agent | No | Custom User-Agent string | |
| follow_redirect | No | Follow redirects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a 'fast directory/file brute-forcing tool' with 'multi-threaded scanning,' 'customizable file extensions,' 'status code filtering,' and 'recursive scanning support.' This covers performance, functionality, and operational characteristics, though it doesn't detail error handling or output format.
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 well-structured with a clear purpose statement, a features list, and examples. It is appropriately sized and front-loaded, with the core purpose stated first. However, the features section could be more concise, and some redundancy exists (e.g., repeating 'Gobuster is a fast...' after the initial enumeration statement).
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 (8 parameters, no output schema, and no annotations), the description is moderately complete. It covers the tool's purpose, features, and provides examples, but lacks details on output format, error conditions, or integration with other tools. For a brute-forcing tool with multiple parameters, more contextual guidance 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?
The input schema has 100% description coverage, so the baseline score is 3. The description adds minimal parameter semantics beyond the schema, only mentioning 'url' and 'extensions' in the example without providing additional context. It does not explain interactions between parameters or advanced usage scenarios.
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 as 'Enumerate directories and files on web servers using wordlists,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like kali_web_gobuster_dns (DNS enumeration) and kali_web_ffuf_fuzz (fuzzing) by focusing on directory/file brute-forcing.
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 implied usage context through the 'Features' section (e.g., 'Fast multi-threaded scanning,' 'Status code filtering'), which suggests when this tool might be preferred. However, it lacks explicit guidance on when to use this tool versus alternatives like kali_web_nikto_scan or kali_web_sqlmap_test, and does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate subdomains using DNS brute-forcing with wordlists.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Target domain (e.g., 'example.com') | |
| wordlist | No | Subdomain wordlist file path | /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt |
| threads | No | Number of concurrent threads | |
| timeout | No | Scan timeout in seconds | |
| resolver | No | Custom DNS resolver (e.g., '8.8.8.8') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'DNS brute-forcing with wordlists,' which implies aggressive scanning behavior, but doesn't disclose potential impacts like network noise, rate limiting risks, legal considerations, or typical output format. For a security tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
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, efficient sentence: 'Enumerate subdomains using DNS brute-forcing with wordlists.' It's front-loaded with the core purpose, has zero redundant information, and every word earns its place by specifying the action, target, and method concisely.
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 (a security scanning tool with 5 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral traits like potential destructiveness, authorization needs, or output format, which are critical for a brute-forcing tool. The description alone is insufficient for safe and effective use without additional context.
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 schema already documents all five parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'wordlist' selection affects results or what 'threads' optimization entails). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate with extra semantic context.
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: 'Enumerate subdomains using DNS brute-forcing with wordlists.' It specifies the verb ('enumerate'), resource ('subdomains'), and method ('DNS brute-forcing with wordlists'). However, it doesn't explicitly differentiate from its sibling tool 'kali_web_gobuster_dir', which appears to be a directory enumeration tool rather than DNS subdomain enumeration, so the distinction is implied but not stated.
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. It doesn't mention sibling tools like 'kali_web_nikto_scan' or 'kali_web_nuclei_scan' for web scanning, or specify scenarios where DNS brute-forcing is preferred over other subdomain discovery methods. Usage is implied by the tool's name and description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprehensive web server scanner for vulnerabilities, misconfigurations, and security issues.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target host or URL | |
| port | No | Port to scan | |
| ssl | No | Force SSL/HTTPS mode | |
| tuning | No | Tuning options (e.g., '1' for interesting files, '2' for misconfig) | |
| timeout | No | Scan timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'comprehensive' scanning but lacks details on permissions required, potential impact (e.g., whether it's intrusive or safe for production), rate limits, output format, or error handling. For a security scanning tool with zero annotation coverage, this is a significant gap in 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, efficient sentence that front-loads key information ('comprehensive web server scanner') without unnecessary words. Every part of the sentence earns its place by specifying the tool's scope, making it appropriately sized and well-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?
Given the complexity of a security scanning tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., intrusiveness, permissions), output format, and differentiation from sibling tools, which are critical for an AI agent to use this tool effectively in a context with multiple scanning alternatives.
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 schema already documents all parameters (target, port, ssl, tuning, timeout) with descriptions. The description adds no additional meaning beyond what the schema provides, such as examples for tuning options or context on default values. Baseline 3 is appropriate when the schema does the heavy lifting.
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 as a 'comprehensive web server scanner for vulnerabilities, misconfigurations, and security issues,' which specifies the verb (scan), resource (web server), and scope (vulnerabilities, misconfigurations, security issues). However, it doesn't explicitly differentiate from sibling web scanning tools like kali_web_nuclei_scan or kali_web_wpscan_scan, which likely have overlapping purposes.
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. With multiple sibling tools for web scanning (e.g., kali_web_nuclei_scan, kali_web_sqlmap_test), there's no indication of specific contexts, prerequisites, or exclusions for using kali_web_nikto_scan, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Template-based vulnerability scanner with extensive CVE coverage and custom templates support.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL or host | |
| templates | No | Template or template directory (default: all templates) | |
| severity | No | Filter by severity | |
| tags | No | Filter by tags (e.g., ['cve', 'owasp']) | |
| threads | No | Number of concurrent threads | |
| timeout | No | Scan timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'vulnerability scanner' which implies potentially intrusive/destructive actions, but doesn't warn about risks, permissions needed, rate limits, or output format. For a security scanning tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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, efficient sentence that communicates the core functionality without waste. It's appropriately sized and front-loaded with the essential information about being a template-based vulnerability scanner.
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 vulnerability scanning tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address critical context like what the scan output looks like, whether it's passive vs active scanning, potential impact on targets, or error conditions. The combination of security tool complexity and lack of structured metadata requires more comprehensive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter interactions, default behaviors beyond schema defaults, or practical usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 as a 'template-based vulnerability scanner' with 'extensive CVE coverage and custom templates support', which specifies the verb (scan), resource (vulnerabilities), and key capabilities. It distinguishes itself from siblings like nikto_scan or sqlmap_test by emphasizing template-based scanning and CVE coverage, though it doesn't explicitly contrast with all web scanning 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 alternatives. With multiple web scanning siblings (nikto_scan, sqlmap_test, wpscan_scan, etc.), there's no indication of specific scenarios, target types, or comparative strengths/weaknesses that would help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Automated SQL injection testing and exploitation.
SQLMap automates the detection and exploitation of SQL injection vulnerabilities.
WARNING: Only use on systems you have authorization to test.
Features:
Automatic SQL injection detection
Database fingerprinting
Data extraction
Multiple injection techniques
Example:
GET: url="https://example.com/page?id=1"
POST: url="https://example.com/login", data="user=admin&pass=test", method="POST"
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL | |
| data | No | POST data string | |
| cookie | No | HTTP Cookie header value | |
| method | No | HTTP method | GET |
| parameter | No | Testable parameter(s) (e.g., 'id', '*' for all) | |
| level | No | Level of tests (1-5, default: 1) | |
| risk | No | Risk of tests (1-3, default: 1) | |
| dbms | No | Force DBMS type | |
| technique | No | SQL injection techniques (e.g., 'BEUSTQ') | |
| batch | No | Never ask for user input (batch mode) | |
| timeout | No | Scan timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs 'exploitation' and 'data extraction,' implying destructive/mutative behavior, and includes a security warning about authorization. However, it lacks details on rate limits, error handling, output format, or what specific actions might be taken during exploitation (e.g., database modification). The features list adds some context but is high-level.
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 well-structured with a clear purpose statement, warning, bullet-pointed features, and examples. It's front-loaded with critical information. However, the features list is somewhat redundant with the purpose, and the examples could be more integrated, slightly reducing efficiency.
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, potentially destructive tool with 11 parameters and no annotations or output schema, the description is moderately complete. It covers purpose, ethical warning, and high-level features, but lacks details on behavioral outcomes, error cases, or what to expect from the tool's execution, leaving gaps given the tool's 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 the schema already documents all 11 parameters thoroughly. The description adds minimal parameter semantics beyond the examples showing url, data, and method usage. It doesn't explain parameter interactions, default behaviors, or advanced options like technique codes, keeping it at the baseline for high schema 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's purpose as 'Automated SQL injection testing and exploitation' and elaborates with 'SQLMap automates the detection and exploitation of SQL injection vulnerabilities.' This specifies both the action (testing/exploitation) and resource (SQL injection vulnerabilities), distinguishing it from sibling web tools like fuzzing or directory scanning 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 includes a strong warning: 'Only use on systems you have authorization to test,' which provides clear ethical context. However, it doesn't explicitly state when to choose this tool over alternatives like kali_web_nikto_scan or kali_web_nuclei_scan for vulnerability assessment, nor does it mention prerequisites or typical use cases beyond the examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WordPress security scanner for finding vulnerabilities in WordPress sites, themes, and plugins.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | WordPress site URL | |
| enumerate | No | Enumeration: vp (vulnerable plugins), vt (vulnerable themes), u (users) | vp,vt,u |
| api_token | No | WPScan API token for vulnerability data | |
| plugins_detection | No | Plugin detection mode | passive |
| timeout | No | Scan timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'security scanner' and 'finding vulnerabilities,' which implies a read-only analysis, but it does not specify critical behaviors such as whether the scan is passive or active, potential impact on the target site (e.g., if it triggers alerts), rate limits, or authentication needs. For a tool with no annotations and potential security implications, this is a significant gap in 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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core function ('WordPress security scanner'), making it easy to parse. However, it could be slightly more structured by including key usage notes, but it avoids redundancy and waste, earning a high score for conciseness.
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 complexity of a security scanning tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., scan intensity, output format), usage context, and how results are returned. Without annotations or an output schema, the description should provide more context to guide the agent effectively, but it falls short, making it inadequate for the tool's scope.
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, so parameters like 'url' and 'enumerate' are well-documented in the schema itself. The description does not add any additional meaning or context beyond what the schema provides (e.g., it doesn't explain the significance of 'vp,vt,u' or typical use cases for parameters). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 as a 'WordPress security scanner for finding vulnerabilities in WordPress sites, themes, and plugins.' It specifies the verb ('scanner for finding vulnerabilities') and resource ('WordPress sites, themes, and plugins'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'kali_web_nikto_scan' or 'kali_web_nuclei_scan', which may also perform web vulnerability scanning, so it lacks sibling differentiation for a perfect score.
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. It does not mention any specific contexts, prerequisites (e.g., needing a WordPress site), or exclusions (e.g., not for non-WordPress sites). With many sibling tools for web scanning and exploitation, the absence of usage guidelines leaves the agent without clear direction, resulting in a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no ambiguity. The tools are organized into categories (exploit, network, password, web) and target specific resources or actions, such as kali_network_nmap_discover for host discovery versus kali_network_nmap_scan for port scanning. There is no overlap in functionality, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun pattern with a uniform prefix structure (kali_category_tool_action). For example, kali_exploit_searchsploit_search and kali_web_gobuster_dir adhere to the same naming convention throughout. There are no deviations or mixed styles, ensuring predictability and readability.
With 19 tools, the server is well-scoped for its purpose of providing security testing and penetration testing utilities. Each tool earns its place by covering distinct aspects like network scanning, password cracking, and web vulnerability assessment. The count is appropriate for the domain, avoiding both thin coverage and overwhelming complexity.
The tool surface is complete with comprehensive coverage of the security testing domain. It includes tools for exploitation, network reconnaissance, password attacks, and web application scanning, with no obvious gaps. Each category has multiple tools that support full workflows, such as discovery, scanning, and exploitation, ensuring agents can handle typical tasks without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/azza39925/kali-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
