Provides access to over 600 security, penetration testing, and forensic tools installed on Kali Linux, including arbitrary command execution, tool search, manpage retrieval, and structured wrappers for common tools like nmap, sqlmap, gobuster, and searchsploit.
Allows Metasploit to be executed as one of the Kali Linux penetration testing tools, enabling exploitation and security assessment workflows.
Allows Wireshark to be executed as one of the Kali Linux tools, enabling network traffic analysis and packet inspection.
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-tool Scan 192.168.1.1 for open ports using 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 high-performance Model Context Protocol (MCP) Server and Client ecosystem running natively on Kali Linux, providing AI assistants (VSCode, Claude Desktop, Antigravity IDE) full, structured access to all 600+ installed security, penetration testing, and forensic tools.
600+ Kali Tools Available: Execute any binary tool in the full Kali suite natively (Nmap, Metasploit, Sqlmap, Gobuster, Nikto, John the Ripper, Hydra, Wireshark, Searchsploit, Ghidra, etc.).
VirtualBox / Remote VM Support:
Run server.py inside a VirtualBox Kali VM (listening on host-only or bridged network adapter).
Run client.py on your Windows Host inside mcp.json. It bridges local Stdio to remote Kali SSE HTTP seamlessly!
Dual Transport Architecture:
Stdio Mode: For single-machine local setup.
SSE HTTP Mode: For cross-machine or VirtualBox / VMware / WSL2 setups.
Dynamic Tool Discovery & Manpages: Automatically search installed tools by category and query manpages (man <tool>) or --help documentation on the fly.
Structured Wrappers & Workspace Management: Includes high-level JSON wrappers for key tools (nmap, sqlmap, gobuster, searchsploit) and local artifact/file management.
Related MCP server: MCP Kali Server
git clone https://github.com/your-repo/kali-mcp.git
cd kali-mcp
python3 -m pip install -r requirements.txt
python3 -m pip install -e .git clone https://github.com/your-repo/kali-mcp.git
cd kali-mcp
pip install -r requirements.txt
pip install -e .On VirtualBox Kali VM:
Check your Kali VM host-only or bridged IP address (ip a, e.g. 192.168.56.101), then run the server:
python3 server.py --host 0.0.0.0 --port 8000
# Or using the installed CLI:
kali-mcp-server --host 0.0.0.0 --port 8000In VSCode / Claude Desktop / Antigravity IDE on Windows Host:
Configure your mcp.json file:
{
"mcpServers": {
"kali-linux": {
"command": "python",
"args": [
"C:/path/to/kali-mcp-tool/client.py",
"--server", "192.168.56.101",
"--port", "8000"
]
}
}
}Alternatively, if installed via pip install -e ., you can use the installed CLI command directly:
{
"mcpServers": {
"kali-linux": {
"command": "kali-mcp-client",
"args": [
"--server", "192.168.56.101",
"--port", "8000"
]
}
}
}The client will bridge Stdio from your IDE directly to your VirtualBox Kali VM over SSE!
Interactive Terminal Client (Optional): You can test tools directly from a terminal prompt:
python client.py --server 192.168.56.101 --port 8000 --interactive
# Or:
kali-mcp-client --server 192.168.56.101 --port 8000 --interactiveIf your IDE is running directly on Kali Linux:
{
"mcpServers": {
"kali-linux": {
"command": "python3",
"args": [
"/path/to/kali-mcp-tool/server.py"
]
}
}
}Or using the installed command:
{
"mcpServers": {
"kali-linux": {
"command": "kali-mcp-server"
}
}
}Tool | Description |
| Execute any arbitrary shell command natively on Kali with timeout control. |
| Search installed Kali tools by name, keyword, or category. |
| Dynamically fetch manpages ( |
| High-level Nmap port/service scanner wrapper. |
| Automatic SQL injection scan wrapper. |
| Web directory & DNS brute-forcing wrapper. |
| Search ExploitDB offline exploit database. |
| Read, write, list, or delete scan logs & target lists in workspace directory. |
Penetration testing tools shouldonly be executed against targets you own or have explicit, documented permission to test. Always operate responsibly and in accordance with applicable laws.
Executes a shell command directly on the Kali Linux host system.
Args: command: The shell command line to execute (e.g. 'nmap -sS 192.168.1.1', 'nikto -h http://example.com') timeout_seconds: Maximum time in seconds before terminating the command (default: 300s) cwd: Working directory path for execution (default: ./kali_workspace)
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| command | Yes | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context about the timeout terminating the command and the default working directory, but for an arbitrary shell execution tool it omits important traits: it does not mention that commands can mutate the host filesystem or system state, what happens on non-zero exit codes, whether output is captured and returned, or what privileges the command runs with.
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 compact and front-loaded with a one-sentence purpose followed by a clean parameter list. Every sentence adds meaningful information, and there is no filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic invocation details for all three parameters, and an output schema exists so return-value documentation is less critical. However, for a dangerous raw shell execution tool with no annotations, the description remains incomplete because it lacks guidance about side effects, command failure behavior, and how this tool relates to the specialized Kali sibling tools.
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 no descriptions, so the description compensates well by explaining all three parameters, giving defaults for timeout_seconds and cwd, and providing a realistic command example. However, the stated cwd default './kali_workspace' conflicts with the schema's default of null, which introduces ambiguity and prevents a perfect score.
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 'executes' and the resource 'shell command on the Kali Linux host system', with concrete examples like 'nmap -sS 192.168.1.1'. However, it does not explicitly distinguish itself from sibling specialized tools such as kali_run_nmap or kali_run_sqlmap, and the example commands actually overlap with those tools, so it stops short of a 5.
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?
There is no guidance on when to prefer this generic executor over the specialized sibling tools. The description even gives 'nmap' and 'nikto' as examples, which could mislead an agent into using this tool instead of kali_run_nmap or other dedicated wrappers. No when-to-use or when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves complete manual (manpage) or --help documentation for any Kali Linux tool.
Args: tool_name: Name of the binary utility (e.g. 'nmap', 'sqlmap', 'john', 'aircrack-ng')
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently states that the tool retrieves documentation rather than executing the target tool, which implies a read-only, non-destructive operation. This is adequate for a simple help-retrieval tool, though it does not discuss edge cases like unavailable tools.
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 and front-loaded with the core purpose in the first sentence. The Args section adds necessary parameter context without redundancy or filler.
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 single-parameter, read-only help tool with an output schema, the description provides enough information to select and call it. It could be slightly stronger with explicit guidance about when to use it relative to the specialized run_* siblings, but overall it is complete.
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 provides no description for tool_name, but the tool description compensates by defining it as the binary utility name and giving concrete examples ('nmap', 'sqlmap', 'john', 'aircrack-ng'). This is sufficient for correct invocation.
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 retrieves manual or --help documentation for any Kali Linux tool, which is a specific verb and resource. It is distinguishable from siblings like kali_execute_command and kali_run_nmap, though it does not explicitly name an alternative.
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 any Kali Linux tool' implies this is the general-purpose help tool, distinct from the specialized run_* commands and the search tool. However, it does not explicitly state when to prefer this over siblings 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.
Manages files inside the local Kali workspace folder.
Args: action: 'list' (list files), 'read' (read file content), 'write' (create/overwrite file), 'delete' (remove file) filename: Relative filename in workspace content: Text content (required when action is 'write')
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| content | No | ||
| filename | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose destructive behavior: write is 'create/overwrite' and delete is 'remove file.' It also states that content is only required for write. It doesn't mention error cases or path restrictions, but the main safety-relevant effects are explicit.
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 compact and front-loaded with the resource and purpose, followed by a concise parameter/action list. No filler or redundant restatement.
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 definition covers the core operations and their effects, and an output schema exists so return values need not be described. The main gap is the conditional filename requirement and the absence of any notes about edge cases (e.g., missing file, non-workspace paths), so it is only minimally complete.
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 0% schema description coverage, the Args block compensates by explaining each parameter and the valid action values. However, it fails to state that filename is effectively required for read/write/delete, even though schema marks only action as required and defaults filename/content to empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the resource (local Kali workspace folder), a specific verb (manages), and enumerates four concrete operations (list/read/write/delete). This distinguishes it from sibling tools that execute commands or search tool help.
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 use whenever workspace file operations are needed and clearly is not for running Kali commands, but it does not explicitly state when to prefer this tool over alternatives or call out exclusions. Usage context is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs Gobuster URI/directory brute-forcer.
Args: target_url: Target URL (e.g. 'http://192.168.1.100') wordlist: Path to wordlist file (default: '/usr/share/wordlists/dirb/common.txt') options: Additional gobuster dir flags (e.g. '-x php,html,txt')
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | ||
| wordlist | No | /usr/share/wordlists/dirb/common.txt | |
| target_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the tool runs a brute-forcer, but does not disclose that it actively sends network requests, may require authorization, or could generate significant traffic. This is a notable gap for a security 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 short, front-loaded with the main purpose, and uses a clear Args list. Every sentence adds value, specifically the defaults and examples, without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and parameter details are covered, the description lacks important contextual information: when to choose gobuster over other enumeration tools, that it performs active scanning, and any authorization or caution notes. For a brute-forcing tool, these are significant omissions.
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 0% description coverage, so the description must compensate. It does so by providing a target URL example, a default wordlist path, and an example of the options flag format, giving meaningful guidance for all three 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 runs Gobuster, a URI/directory brute-forcer, with a specific verb and resource. This distinguishes it from sibling tools like kali_run_nmap and kali_run_sqlmap, which target different scanning tasks.
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?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The description only states what the tool does and lists arguments, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs Nmap network scanner against target hosts with options.
Args: target: Target IP address, hostname, or subnet (e.g. '192.168.1.1' or 'scanme.nmap.org') options: Nmap flags (default: '-sV -F' fast service version scan)
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| options | No | -sV -F |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 disclosing behavioral traits. It only says it 'runs Nmap,' with no mention of potential side effects, runtime duration, network exposure, permission requirements, or behavior on failure. This is a meaningful gap for an unannotated 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 compact and front-loaded with the core action. The Args section is brief and adds necessary parameter context without repeating boilerplate from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return-value details, so that gap is acceptable. However, for a command-execution tool with no annotations, the description omits important operational context such as expected runtime, safety considerations, and when to prefer the generic kali_execute_command instead. It adequately covers the two parameters but not the surrounding usage 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 0%, so the description must add meaning beyond bare property names. It does so by specifying target formats ('IP address, hostname, or subnet') with concrete examples, and by explaining that options are Nmap flags with a default and intent ('fast service version scan').
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 states a specific verb ('Runs'), the resource (Nmap), and the general target ('target hosts'), so the tool's purpose is clear at a glance. It distinguishes itself from sibling scanners like sqlmap and gobuster, though it doesn't explicitly contrast with the generic kali_execute_command sibling.
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 gives no guidance about when to use this tool versus alternatives such as kali_execute_command, kali_run_sqlmap, or kali_run_gobuster. There are no stated prerequisites, exclusions, or context cues to help an agent choose this tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches Exploit-DB offline database via Searchsploit.
Args: query: Search keywords (e.g. 'Apache 2.4', 'WordPress 5.0', 'Linux Kernel 5.4')
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it only says the search is offline via Searchsploit. It does not disclose what the search returns, whether it invokes a new process, or any execution 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 two short sections with no fluff, front-loads the purpose, and keeps the parameter documentation immediately accessible in an 'Args' block.
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 single-parameter search tool with an output schema, the core invocation is adequately specified. However, the missing usage guidance and minimal behavioral detail leave an agent with only the tool name and one sentence to decide when and how confidently it should be used.
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 has no parameter description (0% coverage), so the description's 'Args' section compensates by explaining query as 'Search keywords' and giving concrete examples for Apache, WordPress, and Linux Kernel. This gives an agent a clear template for the only required parameter.
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 names a specific verb and resource: it 'Searches Exploit-DB offline database via Searchsploit,' which clearly differentiates it from siblings like nmap, sqlmap, or gobuster. The scope is unmistakable.
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 choose this tool over alternative Kali tools or the sibling kali_search_tools. There is no mention of scenarios, prerequisites, or exclusions; the 'offline database' phrase only weakly implies the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs Sqlmap automatic SQL injection and database takeover tool.
Args: target_url: Target URL to test (e.g. 'http://testphp.vulnweb.com/artists.php?artist=1') options: Sqlmap flags (default: '--batch --banner' non-interactive banner scan)
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | --batch --banner | |
| target_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the default invocation is '--batch --banner' and 'non-interactive banner scan', which is useful. However, it does not mention the potential impact of custom 'options' flags, output behavior, or any caution about running a security tool that could perform intrusive database operations.
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 and well-structured: one purpose sentence followed by a compact Args block. It front-loads the tool's purpose, uses an example to remove ambiguity, and contains no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter wrapper with an output schema, the description covers the core invocation surface: tool purpose, target URL format, optional flags, and default non-interactive mode. It is slightly incomplete in not providing usage boundaries or risk context for a security tool, but nothing essential to making a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It explains target_url with a concrete example URL, and options as 'Sqlmap flags' with a clear default and mode. Both parameters are meaningfully documented beyond their bare schema names and types.
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 states a specific verb ('Runs'), a specific tool ('Sqlmap'), and its domain ('SQL injection and database takeover'), which clearly distinguishes it from siblings like kali_run_nmap and kali_run_gobuster. The example target URL further clarifies what the tool operates on. This is specific, non-tautological, and easy for an agent to match to the right task.
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 SQL injection testing through phrases like 'SQL injection and database takeover' and the vulnerable-URL example, but it never explicitly states when to choose this tool over alternatives or when not to use it. No sibling tools or exclusion conditions are mentioned, so usage guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches installed Kali Linux tools by name, keyword, or category.
Categories include: 'information-gathering', 'vulnerability-analysis', 'web-application-analysis', 'password-attacks', 'wireless-attacks', 'reverse-engineering', 'exploitation-tools', 'sniffing-spoofing', 'post-exploitation', 'forensics'
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| category | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It communicates that this is a lookup operation over installed tools and enumerates valid categories, but it does not specify matching behavior, case sensitivity, result format, or whether query and category can be combined.
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 compact and front-loaded, and the category list earns its place as an enumerated set of valid inputs. The one-category-per-line formatting makes it slightly longer than necessary, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two optional parameters and no annotations, the description covers core semantics and accepted category values. Since an output schema exists, omitting return-value details is acceptable; a brief usage example or combination rule would have made it fully complete.
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 provides 0% description coverage, so the description must compensate. It gives practical meaning to the query parameter as a name/keyword search and provides an explicit list of accepted category values, which is enough for correct invocation.
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 uses a specific verb 'Searches' with a clear resource 'installed Kali Linux tools' and identifies three search dimensions: name, keyword, or category. This clearly separates it from sibling tools that execute commands or run specific 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?
Usage context is implied: use this tool to locate an installed Kali tool by name, keyword, or category. However, it does not explicitly state when to prefer this over execution-focused sibling tools or give any exclusion conditions.
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. Dates show when Glama detected each change.
v0.1.0kali_execute_commandkali_get_tool_helpkali_manage_workspacekali_run_gobusterkali_run_nmapkali_run_searchsploitkali_run_sqlmapkali_search_toolsThe generic kali_execute_command overlaps with the dedicated run_nmap, run_sqlmap, run_gobuster, and run_searchsploit wrappers, since the same operations can be performed through either path. However, the tool descriptions clarify intended use, and the other tools are functionally distinct.
All tools consistently use the kali_ prefix and follow a clear verb_noun pattern such as execute_command, search_tools, run_nmap, and manage_workspace. This makes the toolset predictable and easy to navigate.
Eight tools is a well-scoped size for a Kali Linux MCP server: generic execution, tool discovery, help retrieval, several common security tool wrappers, and workspace file management cover the main use cases without unnecessary bloat.
The set covers the core Kali workflow of finding tools, reading documentation, running common scanners, searching exploits, and managing workspace files. The generic command executor fills many long-tail gaps, though there is no dedicated handling for results post-processing or less common tool categories.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VibeCode-cell/kali-mcp-tool'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
