Integrates with Mullvad VPN to provide anonymous network testing capabilities, including connecting to VPN servers, disconnecting, and checking connection status.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kali Linux MCP Server run nmap scan on 192.168.1.1"
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 professional-grade Model Context Protocol (MCP) server providing secure access to Kali Linux security tools through containerized execution. Designed for use with Claude Desktop, Cursor, and other MCP-compatible clients.
Related MCP server: Kali Pentest MCP Server
Containerized Security Tools - Isolated Docker environment for safe execution
Network Security Testing - Nmap, Nikto, DIRB, and custom command execution
WiFi Security Auditing - Monitor mode, packet capture, WPA/WPA2 attacks
JWT Security Testing - Token analysis and vulnerability detection
VPN Integration - Built-in Mullvad VPN support for anonymous testing
Environment-Based Configuration - Secure credential management via .env files
Containerized execution with isolated environments
Configurable network access (bridge/host/none modes)
Privileged mode support for WiFi operations
Command whitelisting and input validation
Automatic cleanup after operations
VPN anonymity for professional assessments
Python 3.10+ (required by MCP SDK)
Docker (for containerized Kali tools)
uv package manager
Mullvad VPN subscription (optional, for VPN features)
Java Runtime (automatically installed for OWASP ZAP)
Node.js/npm (automatically installed for retire.js)
cd /path/to/kali-mcp-server
uv syncdocker build -t kali-mcp:latest .This will install:
Kali Linux base system
Network security tools (nmap, nikto, dirb)
Web application scanners (sqlmap, OWASP ZAP, nuclei)
SSL/TLS testing (testssl.sh)
JavaScript security scanner (retire.js)
WiFi security tools (airmon-ng, reaver, wifite, aircrack-ng)
Mullvad VPN client
Python libraries for JWT and security testing
Java runtime and Node.js for modern tools
Edit the .env file with your Mullvad credentials:
# Required: Your Mullvad account number
MULLVAD_ACCOUNT_NUMBER=YOUR_16_DIGIT_ACCOUNT_NUMBER
# Optional: Default server location (default: se)
MULLVAD_DEFAULT_SERVER=se
# Optional: Default protocol (default: wireguard)
MULLVAD_DEFAULT_PROTOCOL=wireguardGet your Mullvad account from mullvad.net
Add the following to your MCP client configuration file:
{
"mcpServers": {
"kali-linux": {
"command": "uv",
"args": [
"run",
"--directory",
"/absolute/path/to/kali-mcp-server",
"python",
"src/kali_mcp_server/mcp_server.py"
]
}
}
}Important: Replace /absolute/path/to/kali-mcp-server with your actual project path.
Client | Configuration File |
Cursor |
|
Claude Desktop (macOS) |
|
Claude Desktop (Linux) |
|
agent-loop |
|
Method 1: Environment Variables
export MULLVAD_ACCOUNT_NUMBER="YOUR_16_DIGIT_ACCOUNT"
export MULLVAD_DEFAULT_SERVER="se"
export MULLVAD_DEFAULT_PROTOCOL="wireguard"Method 2: Runtime Configuration
Use the vpn_configure_account tool after the server starts.
Method 3: Docker Image Edit the Dockerfile to bake credentials into the image (not recommended for production).
Perform network scanning and port discovery.
Parameters:
target (required) - Target IP/hostname/network
scan_type (optional) - Scan type: quick, full, or stealth
ports (optional) - Port range (e.g., 80,443 or 1-1000)
Web application vulnerability scanner (legacy tool).
Parameters:
target (required) - Target URL
options (optional) - Additional Nikto command-line options
Directory and file brute-forcing tool.
Parameters:
target (required) - Target URL
wordlist (optional) - Path to wordlist file
Automated SQL injection detection and exploitation tool.
Parameters:
target (required) - Target URL
level (optional) - Test thoroughness 1-5 (default: 1)
risk (optional) - Risk level 1-3 (default: 1)
data (optional) - POST data for testing forms
Use Cases:
Detect SQL injection vulnerabilities in web applications
Test GET and POST parameters
Extract database contents for authorized testing
Identify database type and version
OWASP ZAP - Modern web application security scanner.
Parameters:
target (required) - Target URL
scan_type (optional) - baseline (quick), full (thorough), or api (REST APIs)
Use Cases:
Comprehensive vulnerability scanning for modern web apps
Automated testing of SPAs (React, Vue, Angular)
API security testing with OpenAPI/Swagger support
Active and passive vulnerability detection
Better alternative to Nikto for modern applications
Fast template-based vulnerability scanner with 5000+ checks.
Parameters:
target (required) - Target URL
templates (optional) - Template tags (e.g., cves,misconfigurations,exposures)
severity (optional) - Filter by severity: critical,high,medium,low,info
Use Cases:
CVE detection and exploitation
Misconfiguration detection
Exposed admin panels and sensitive files
Security header validation
Custom template-based checks
Comprehensive SSL/TLS configuration and vulnerability scanner.
Parameters:
target (required) - Target hostname:port or URL
checks (optional) - Specific check type
Use Cases:
Test HTTPS/TLS configuration
Detect SSL/TLS vulnerabilities (Heartbleed, POODLE, etc.)
Analyze cipher suite strength
Certificate validation
Perfect for testing local dev servers with HTTPS
Scan for vulnerable and outdated JavaScript libraries.
Parameters:
target (required) - Target URL or local path
Use Cases:
Identify vulnerable JavaScript libraries (jQuery, Angular, etc.)
Detect outdated npm packages
Find known CVEs in client-side dependencies
Security auditing of third-party scripts
Analyze HTTP security headers configuration.
Parameters:
target (required) - Target URL
Checks For:
Content-Security-Policy - XSS and injection protection
Strict-Transport-Security - HTTPS enforcement
X-Frame-Options - Clickjacking protection
X-Content-Type-Options - MIME sniffing prevention
Referrer-Policy - Referrer information control
Permissions-Policy - Browser feature control
Use Cases:
Validate security header implementation
Quick security posture assessment
Development/staging environment validation
Production deployment verification
Connect to Mullvad VPN with optional server selection.
Parameters:
server (optional) - Server location (e.g., se, nl ams, us-nyc-wg-301)
protocol (optional) - VPN protocol: wireguard or openvpn
Disconnect from Mullvad VPN.
Check VPN connection status and details.
Parameters:
verbose (optional) - Show detailed status information
Decode and analyze JWT token structure.
Parameters:
token (required) - JWT token to decode
verify (optional) - Attempt signature verification
secret (optional) - Secret key for verification
Test JWT tokens for common security vulnerabilities.
Parameters:
token (required) - JWT token to test
endpoint (optional) - API endpoint to test against
Vulnerability Tests:
None algorithm bypass attacks
Weak secret brute-forcing
Algorithm confusion attacks
Token manipulation attempts
Signature verification bypass
Note: WiFi tools are available in the Docker image but not yet exposed as MCP tools. They can be accessed via the custom_command tool if implemented.
Available WiFi capabilities:
Monitor mode activation/deactivation
Network scanning and discovery
WPA/WPA2 handshake capture
WPS vulnerability testing
MAC address spoofing
Packet injection and analysis
// 1. Check security headers first
security_headers_check({
target: 'http://localhost:3000',
});
// 2. Scan for vulnerable JavaScript libraries
retirejs_scan({
target: 'http://localhost:3000',
});
// 3. Test for SQL injection vulnerabilities
sqlmap_scan({
target: 'http://localhost:3000/api/users?id=1',
level: 3,
risk: 2,
});
// 4. Test POST forms for SQL injection
sqlmap_scan({
target: 'http://localhost:3000/login',
data: 'username=admin&password=test',
level: 2,
});
// 5. Comprehensive web app scan
zap_scan({
target: 'http://localhost:3000',
scan_type: 'baseline',
});
// 6. Fast vulnerability detection with Nuclei
nuclei_scan({
target: 'http://localhost:3000',
templates: 'cves,misconfigurations,exposures',
severity: 'critical,high',
});
// 7. Test HTTPS configuration (if using SSL)
testssl_scan({
target: 'https://localhost:8443',
});// Quick port scan
nmap_scan({
target: '192.168.1.0/24',
scan_type: 'quick',
});
// Full scan with OS detection
nmap_scan({
target: 'example.com',
scan_type: 'full',
ports: '1-65535',
});
// Web vulnerability scan
nikto_scan({
target: 'https://example.com',
});
// Directory enumeration
dirb_scan({
target: 'https://example.com',
wordlist: '/usr/share/dirb/wordlists/common.txt',
});// Connect to VPN before testing
vpn_connect({
server: 'se got',
protocol: 'wireguard',
});
// Verify VPN connection
vpn_status({ verbose: true });
// Perform anonymous testing
nmap_scan({
target: 'authorized-target.com',
scan_type: 'stealth',
});
// Disconnect when done
vpn_disconnect();// Decode JWT token
jwt_decode({
token: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...',
verify: true,
secret: 'suspected-secret',
});
// Security vulnerability testing
jwt_security_test({
token: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...',
endpoint: 'https://api.example.com/protected',
});// 1. Establish anonymous connection
vpn_connect({ server: 'se got' });
vpn_status({ verbose: true });
// 2. Initial reconnaissance
nmap_scan({
target: 'authorized-target.com',
scan_type: 'stealth',
ports: '1-10000',
});
// 3. Web application security testing
// a. Modern vulnerability scan
zap_scan({
target: 'https://authorized-target.com',
scan_type: 'baseline',
});
// b. Fast CVE and misconfiguration detection
nuclei_scan({
target: 'https://authorized-target.com',
templates: 'cves,misconfigurations,exposures',
severity: 'critical,high',
});
// c. Security headers check
security_headers_check({
target: 'https://authorized-target.com',
});
// d. Check for vulnerable JavaScript libraries
retirejs_scan({
target: 'https://authorized-target.com',
});
// 4. Database security testing
sqlmap_scan({
target: 'https://authorized-target.com/api/products?id=1',
level: 3,
risk: 2,
});
// 5. SSL/TLS security analysis
testssl_scan({
target: 'authorized-target.com:443',
});
// 6. API and JWT security testing
jwt_security_test({
token: 'captured-jwt-token',
endpoint: 'https://api.authorized-target.com/v1/user',
});
// 7. Switch VPN location if needed
vpn_connect({ server: 'nl ams' });
// 8. Additional testing from new IP
nmap_scan({
target: 'authorized-target.com',
scan_type: 'full',
});
// 9. Clean disconnect
vpn_disconnect();// Comprehensive security check for your local web application
const target = 'http://localhost:3000';
// Step 1: Quick security posture
security_headers_check({ target });
// Step 2: Check for vulnerable dependencies
retirejs_scan({ target });
// Step 3: SQL injection testing
sqlmap_scan({
target: `${target}/api/search?q=test`,
level: 2,
risk: 1,
});
// Step 4: Comprehensive vulnerability scan
zap_scan({
target,
scan_type: 'baseline',
});
// Step 5: Template-based checks
nuclei_scan({
target,
templates: 'misconfigurations,exposures',
severity: 'medium,high,critical',
});
// Step 6: If using HTTPS locally
testssl_scan({
target: 'https://localhost:8443',
});CRITICAL: Only use this tool on systems you own or have explicit written permission to test. Unauthorized access to computer systems is illegal in most jurisdictions.
Credential Protection - Never commit .env files to version control
Connection Verification - Always verify VPN status before sensitive operations
Kill Switch - Use lockdown mode to prevent traffic leaks
DNS Leak Prevention - Verify DNS queries route through VPN
Operational Security - Assume all testing activities may be logged
Minimal Privileges - Uses --cap-add NET_ADMIN and --cap-add NET_RAW instead of --privileged for better security
Host Network Access - Network scans and VPN operations use host network mode only when needed
Resource Limits - Consider implementing Docker resource constraints
Image Security - Regularly update the Docker image for security patches
Container Isolation - Non-privileged operations run in bridge network mode with minimal capabilities
Legal Compliance - WiFi testing may violate laws in your jurisdiction
Network Disruption - Attacks can disrupt legitimate network services
Interference - Monitor mode may interfere with your own connectivity
Data Handling - Captured handshakes contain sensitive information
Documentation - Maintain detailed logs of all security testing activities
Authorization - Keep written authorization for all penetration tests
Scope Adherence - Only test systems explicitly included in scope
Responsible Disclosure - Report vulnerabilities through proper channels
Evidence Chain - Document VPN usage for legal compliance
kali-mcp-server/
├── src/
│ └── kali_mcp_server/
│ ├── __init__.py
│ ├── mcp_server.py # Main MCP server (clean coordinator)
│ ├── core/
│ │ ├── __init__.py
│ │ └── docker_executor.py # Reusable Docker execution engine
│ └── tools/
│ ├── __init__.py
│ ├── network_tools.py # Nmap, Nikto, DIRB
│ ├── web_tools.py # SQLMap, ZAP, Nuclei, testssl, retire.js
│ ├── vpn_tools.py # Mullvad VPN management
│ └── jwt_tools.py # JWT security testing
├── Dockerfile # Kali Linux container definition
├── pyproject.toml # Python dependencies
├── .env # Environment configuration (git-ignored)
├── .env.example # Environment template
└── README.md # This fileThe server follows DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Stupid) principles:
Modular Design - Each tool category in its own module
Composition Over Inheritance - Functions, not complex class hierarchies
Single Responsibility - One Docker executor used by all tools
Comprehensive Documentation - Every function has detailed Python docstrings
# Install development dependencies
uv sync --dev
# Format code
uv run black .
# Lint code
uv run ruff check .
# Run tests (if available)
uv run pytest
# Test server locally
uv run python src/kali_mcp_server/mcp_server.pyThe modular architecture makes adding new tools straightforward:
Create tool module - Add function to appropriate module in tools/
Network tools → network_tools.py
Web security → web_tools.py
VPN/anonymity → vpn_tools.py
Authentication → jwt_tools.py
New category → Create new module file
Export function - Add to tools/__init__.py
Register tool - Add to TOOL_DEFINITIONS and TOOL_HANDLERS in mcp_server.py
Add documentation - Include Python docstrings with:
Description of functionality
Args with types and descriptions
Returns specification
Usage examples
Test thoroughly - Verify in isolated environment
Example: Adding a new network tool:
# In tools/network_tools.py
async def run_masscan(args: Dict[str, Any]) -> Dict[str, Any]:
"""Execute Masscan port scanner.
Args:
args: Dictionary containing target and rate parameters
Returns:
Dictionary with scan results
"""
target = args["target"]
rate = args.get("rate", 1000)
cmd = ["masscan", target, "-p1-65535", f"--rate={rate}"]
return await execute_in_container(cmd, privileged=True)The Dockerfile can be customized to add additional tools:
# Add custom tools
RUN apt-get update && apt-get install -y \
your-custom-tool \
another-tool \
&& rm -rf /var/lib/apt/lists/*
# Add Python packages
RUN pip3 install --no-cache-dir --break-system-packages \
your-python-packageRebuild the image after modifications:
docker build -t kali-mcp:latest .Problem: "No tools, prompts, or resources" error in MCP client
Solution: Ensure you're using the --directory flag in your MCP configuration:
"args": ["run", "--directory", "/absolute/path/to/project", "python", "src/kali_mcp_server/mcp_server.py"]Problem: Cannot connect to Docker daemon
Solution:
# Start Docker service
sudo systemctl start docker
# Add user to docker group
sudo usermod -aG docker $USER
newgrp dockerProblem: VPN fails to connect
Solutions:
Verify Mullvad account number in .env file
Check Mullvad subscription is active
Ensure privileged Docker mode is enabled
Verify host network access is available
Problem: ModuleNotFoundError when starting server
Solution:
# Reinstall dependencies
uv sync
# Verify uv is using correct Python version
uv run python --version # Should be 3.10+Problem: Operation not permitted when running nmap scans
Solution: This is fixed in v1.0.0 with proper capability management. The server now uses:
--cap-add NET_ADMIN for network administration
--cap-add NET_RAW for raw packet access
--network host for network scanning operations
Instead of the insecure --privileged flag. If you still experience issues:
# Verify Docker image is updated
docker images | grep kali-mcp
# Rebuild if needed
docker build -t kali-mcp:latest .
# Test manually
docker run --rm --network host --cap-add NET_ADMIN --cap-add NET_RAW \
kali-mcp:latest nmap -F 192.168.1.1Reference: Based on Docker MCP Tutorial Issue #7
Contributions are welcome! Please ensure:
Code follows existing style (use black and ruff)
All security tools are properly containerized
Documentation is updated for new features
Testing is performed in isolated environments
This project is provided as-is for educational and authorized security testing purposes only.
WARNING: This tool is designed for authorized security testing only.
Unauthorized access to computer systems is illegal. Users are responsible for:
Obtaining proper authorization before testing
Complying with all applicable laws and regulations
Using the tool ethically and responsibly
Maintaining confidentiality of discovered vulnerabilities
The authors and contributors assume no liability for misuse of this tool.
Kali Linux - Security testing platform
Mullvad VPN - Privacy-focused VPN service
Model Context Protocol - Anthropic's MCP standard
Security Community - For tools and methodologies
Version: 1.0.0 Last Updated: October 21, 2024 Status: Production Ready - Modular Architecture
✅ v1.0.0 (Oct 21, 2024) - Complete refactoring with modular architecture
Modular tool organization (DRY & KISS principles)
Improved Docker security (minimal capabilities instead of --privileged)
Comprehensive Python docstrings for all functions
Composition-based design for maintainability
Fixed nmap execution with proper NET_ADMIN/NET_RAW capabilities
Brute-force discover hidden directories and files on web servers with DIRB
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL | |
| wordlist | No | Wordlist path (default: /usr/share/dirb/wordlists/common.txt) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. The term 'brute-force' hints at possible server load but does not specify concurrency, rate limiting, or other behavioral traits. The agent lacks details about the tool's impact, such as whether it may cause heavy traffic or require specific permissions.
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 communicates the core function without unnecessary words. It is appropriately front-loaded and efficient for a straightforward tool.
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 lack of output schema and annotations, the description is somewhat complete for a simple brute-forcing tool. However, it does not explain what the output contains, how long it might take, or any risk profile (e.g., potential service disruption). For a tool that could be aggressive, more context would benefit 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?
Schema description coverage is 100%, baseline is 3. The description adds minimal value beyond the schema: it mentions a default wordlist path but repeats the same info. No additional semantic or usage context is provided for the parameters.
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: using DIRB to brute-force discover hidden directories and files on web servers. The verb 'discover' and resource 'hidden directories and files' are specific, and it distinguishes itself from sibling tools like nmap_scan or sqlmap_scan which have different scanning 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?
No explicit guidance on when to use this tool versus alternatives like nikto_scan or nuclei_scan. The description implies usage for web directory brute-forcing but does not mention prerequisites, complementary tools, or cases where it should not be used (e.g., against production servers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode and analyze JWT tokens, optionally verifying signatures
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | JWT token to decode | |
| verify | No | Attempt signature verification | |
| secret | No | Secret key for signature verification (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description only mentions optional verification but omits details on error handling, account of decode output, or behavior when verification fails.
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 is efficient and front-loaded, but could slightly benefit from clearer segmentation of decode vs. verification steps.
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?
No output schema; description fails to indicate return structure (e.g., header, payload, signature). Given the tool's complexity and sibling context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; the description adds minimal value beyond confirming optional verification behavior.
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 specifies the action (decode and analyze) and resource (JWT tokens), and hints at distinguishing from sibling jwt_security_test by mentioning signature verification.
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 like jwt_security_test; lacks conditional usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test JWT token for security vulnerabilities (none algorithm, weak secrets)
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | JWT token to test | |
| endpoint | No | API endpoint to test against (optional) |
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 what vulnerabilities are tested but does not disclose behavioral traits such as whether the tool sends HTTP requests, modifies state, or requires authentication. For a security test tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose efficiently. It is concise but could benefit from more structured formatting (e.g., bullet points for 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 no output schema and two parameters, the description is minimally adequate but lacks details on return values, error handling, or behavioral context. For a security testing tool, more completeness is expected.
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% (both token and endpoint are described). The description adds no additional insight beyond the schema, so baseline score of 3 is appropriate.
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: testing JWT tokens for specific vulnerabilities (none algorithm, weak secrets). The verb 'Test' and resource 'JWT token' are explicit, and it distinguishes from siblings like jwt_decode, which decodes tokens.
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 the tool is for security testing but provides no explicit guidance on when to use it versus alternatives (e.g., jwt_decode for decoding, or other scanners for different vulnerabilities). No when-to-use or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan web servers for vulnerabilities and misconfigurations with Nikto
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL (e.g., 'http://example.com') | |
| options | No | Additional Nikto command-line options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as network impact, authentication requirements, or potential consequences of scanning. It merely states the intention to scan.
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 unnecessary words, making it concise. However, it borders on being too brief.
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?
No output schema is provided, and the description does not explain what the tool returns or how to interpret the scan results. Given the complexity of a scanning tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as the schema descriptions are minimal but present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans web servers for vulnerabilities and misconfigurations using Nikto. However, it does not differentiate from sibling scanning tools like nmap_scan or nuclei_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform network scanning with Nmap to discover hosts, ports, and services
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP/hostname/network (e.g., '192.168.1.1', '192.168.1.0/24') | |
| scan_type | No | Scan type: quick, full, or stealth | |
| ports | No | Port range (optional, e.g. '80,443' or '1-1000') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as potential intrusiveness, network impact, or permission requirements. The agent lacks awareness of whether the scan could trigger alarms or consume significant resources.
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, well-formed sentence that directly states the purpose. It is front-loaded with the action and resource, and every word earns its place without unnecessary detail.
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, the description should explain what information is returned (e.g., open ports, services, OS detection). It fails to do so. Additionally, it omits context like rate limits or scan duration, making it incomplete for an agent to predict 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?
The input schema has 100% coverage, so parameters are described. However, the description adds no additional meaning beyond the schema—it does not explain the differences between quick, full, and stealth scans or how to specify ports effectively. A baseline of 3 is appropriate since schema covers the basics.
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 performs network scanning with Nmap to discover hosts, ports, and services. It uses a specific verb and resource, and it distinguishes itself from sibling security scanning tools like sqlmap_scan or nikto_scan, which target web applications or databases.
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 such as nikto_scan or dirb_scan. It does not mention prerequisites, context, or which scan types are appropriate for different scenarios, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast vulnerability scanner using community templates with Nuclei
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL to scan | |
| templates | No | Template tags (e.g., 'cves,misconfigurations') | |
| severity | No | Severity filter (critical,high,medium,low,info) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states it is a 'fast vulnerability scanner' but does not disclose potential impacts like network requests, required permissions, or any side effects. The lack of detail leaves agents uninformed about safety or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, which is very concise. It front-loads the core purpose. However, it could include more context without excessive length, such as typical usage or critical notes.
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 presence of multiple sibling security scanners, the description lacks context to differentiate usage. No output schema or annotations exist. For a tool with 3 parameters—one required—the description is too sparse to fully inform an agent about correct invocation and expectations.
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 is 3. The description adds no additional parameter details beyond what the schema provides (e.g., 'target' as URL, 'templates' as tags, 'severity' filter). It does not clarify template syntax or valid values.
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 identifies the tool as a fast vulnerability scanner using Nuclei with community templates. It conveys the core purpose and distinguishes from sibling tools like nmap_scan (network scanning) or sqlmap_scan (SQL injection) by emphasizing template-based scanning.
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 such as nikto_scan or zap_scan. There is no mention of prerequisites, recommended use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for vulnerable JavaScript libraries with retire.js
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL to scan (must start with http/https) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden but only states the basic action. It does not disclose behavioral traits such as whether the scan is read-only, potential side effects, or limitations beyond the target URL 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 a single, front-loaded sentence with no wasted words. It immediately communicates the tool's 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?
The tool is simple but lacks output schema. The description omits details about return format, error handling, or expected behavior, leaving the agent with incomplete 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% for the single parameter. The tool description adds no extra information beyond what the schema already provides, so baseline score of 3 applies.
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 (scan) and the resource (vulnerable JavaScript libraries) with the tool name (retire.js). It distinguishes itself from sibling scanning tools by specifying the focus on JavaScript libraries.
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 sibling tools like nikto_scan, nuclei_scan, or dirb_scan. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check HTTP security headers configuration for best practices
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'check' but does not clarify whether the tool makes HTTP requests, is read-only, or any side effects. The minimal description leaves significant ambiguity about 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 short sentence with no extraneous information. It is front-loaded and concise, though it could be slightly more informative without losing 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 no output schema and no annotations, the description lacks completeness. It does not explain what the tool returns (e.g., headers list, pass/fail status) or any operational details, leaving gaps for an agent to understand the full 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%, with the parameter 'target' described as 'Target URL to check'. The tool description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 'Check', the resource 'HTTP security headers configuration', and the purpose 'for best practices'. It distinguishes the tool from sibling security scanners (e.g., nmap_scan, nikto_scan) by focusing specifically on security headers.
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 explicit guidance on when to use this tool versus alternatives or when not to use it. The intended usage is only implied by the tool name and description, lacking context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test for SQL injection vulnerabilities with SQLMap
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL to test | |
| level | No | Test level 1-5 (thoroughness, default: 1) | |
| risk | No | Risk level 1-3 (invasiveness, default: 1) | |
| data | No | POST data (e.g., 'username=admin&password=pass') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It fails to disclose that SQLMap sends potentially malicious payloads that could disrupt or damage the target, nor does it mention authorization requirements, invasiveness, or response format. The description is misleadingly benign.
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 without fluff, achieving conciseness. However, it sacrifices informativeness—it states the purpose but lacks structure (e.g., no bullet points or additional context). It earns its place but could be more effective.
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 4 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain what the tool returns (e.g., vulnerability list), how to interpret results, or safety considerations. The complexity of SQLMap scanning demands richer 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?
All 4 parameters have descriptions in the schema (100% coverage). The description itself adds no extra meaning beyond the schema, so baseline 3 is appropriate. No enrichment like usage examples or constraints is provided.
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 tests for SQL injection vulnerabilities using SQLMap. This distinguishes it from sibling tools like dirb_scan (directory brute force) or nmap_scan (network scanning), as it specifically targets SQL injection via a well-known 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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, target suitability, or avoidance conditions (e.g., 'use only with explicit permission'). The description lacks any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test SSL/TLS configuration and vulnerabilities with testssl.sh
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target hostname:port or URL | |
| checks | No | Specific checks to run (e.g., 'heartbleed', 'ccs') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It fails to mention that the tool performs active network scanning, may be intrusive, requires network access, or could generate traffic that impacts the target.
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. It is front-loaded with the key action and resource, but could be slightly expanded without losing 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 tool's simplicity and full schema coverage, the description is minimally adequate but lacks behavioral context (e.g., scanning duration, output format). More details would help, especially without an output schema.
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 parameters are already documented. The description does not add extra 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 uses verb 'Test' and specifies resource 'SSL/TLS configuration and vulnerabilities', clearly distinguishing it from siblings like sqlmap_scan or nikto_scan. However, it could be more specific about the types of checks (e.g., protocol support, cipher strengths).
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 (e.g., for SSL-related scans vs web app scans). Usage is implied by the tool name and description, but no exclusions or recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to Mullvad VPN for anonymous security testing
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Server location (e.g., 'se', 'nl ams') - defaults from .env | |
| protocol | No | VPN protocol (default: wireguard) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'connect' without details on authentication, side effects, or whether a previous connection must be disconnected first.
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 with no waste, but it lacks structure such as separate sections for purpose and 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?
With two parameters, no output schema, and no annotations, the description covers the basic purpose but misses contextual details like connection time, prerequisites, or what happens on failure.
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 description adds no additional 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 action (connect), the specific service (Mullvad VPN), and the context (anonymous security testing). It distinguishes well from sibling tools like vpn_disconnect and vpn_status.
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 phrase 'for anonymous security testing' implies a use context, but there is no explicit guidance on when to use this tool versus alternatives like vpn_disconnect, nor any mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect from Mullvad VPN
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description lacks any disclosure of behavioral traits such as prerequisites, side effects, or safety. It only states the basic action.
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, perfectly concise for the simple action.
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 lack of annotations and output schema, the description should provide more context about behavioral aspects. It fails to mention if disconnect is always safe or requires being connected, leaving 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?
The tool has no parameters, and the input schema provides 100% coverage. The description adds no parameter info, but baseline for 0 parameters is 4.
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 'Disconnect' and the resource 'Mullvad VPN'. It distinguishes from sibling tools like vpn_connect (connect) and vpn_status (status check).
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 vs alternatives. The context of disconnecting is implied but no explicit when/when-not/alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check current VPN connection status and server information
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Show detailed status information (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It does not specify if the operation is read-only, what happens if no VPN is connected, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient and front-loaded. However, it could be slightly expanded to include more context without being verbose.
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 simplicity (one optional boolean parameter, no output schema), the description is adequate but leaves gaps: it doesn't explain what 'server information' entails or the format of the status output.
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 only parameter 'verbose' is fully described in the schema. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
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 'Check' and the resource 'VPN connection status and server information'. It effectively distinguishes from sibling tools like vpn_connect and vpn_disconnect, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking status, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites like an active VPN connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprehensive web application security scanner using OWASP ZAP
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL to scan | |
| scan_type | No | Scan type: baseline (quick), full (thorough), or api |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'comprehensive web application security scanner' without mentioning whether scans can be destructive, require authentication, or affect targets.
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 at one sentence, front-loading the core purpose. However, it is somewhat vague with the word 'comprehensive', though it 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?
Given no output schema and 2 parameters, the description should explain return values, risks, or expected behavior. It fails to provide contextual completeness, such as scan duration or results format.
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 input schema already documents both parameters. The description adds no additional meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans web applications for security issues and explicitly names OWASP ZAP, distinguishing it from sibling scanners like nikto_scan or nuclei_scan.
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 such as dirb_scan or sqlmap_scan. The description lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dirb_scanjwt_decodejwt_security_testnikto_scannmap_scannuclei_scanretirejs_scansecurity_headers_checksqlmap_scantestssl_scanvpn_connectvpn_disconnectvpn_statuszap_scanScored across 14 tools
Tools are mostly distinct—each targets a specific security task (web scanning, JWT, SSL, VPN, etc.). Some overlap exists among web scanners (dirb, nikto, nuclei, zap), but descriptions clarify their different foci. Only minor potential confusion between nikto and nuclei.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., dirb_scan, vpn_connect, jwt_decode). The few variations like jwt_security_test still use the same structure, so naming is predictable and uniform.
With 14 tools, the set is well-scoped for a security testing server. It covers a range of essential tasks (network scanning, web application scanning, JWT analysis, VPN management) without being overwhelming or too sparse.
The tool set covers major security testing areas: network scanning (nmap), web vuln scanning (multiple tools), SQL injection (sqlmap), SSL (testssl), JWT, directory brute-force, JS library vulns, and security headers. Minor gaps like exploitation or password cracking exist, but core workflows are covered.
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Exposes FEDLIN's public security scanners as agent-callable tools over Streamable HTTP.
Offline methodology engine for authorized penetration testing, CTF, and security research.
