Allows performing WiFi security auditing on a remote Kali Linux system using the aircrack-ng suite, including monitor mode management, network scanning, packet capture, handshake capture, and password cracking.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sec-aircrack-ng-mcp Scan for wireless networks on wlan0mon"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides WiFi security auditing capabilities using the aircrack-ng suite. Commands are executed on a remote Kali Linux system via SSH, enabling AI assistants to perform authorized wireless security assessments.
Monitor Mode Management - Enable/disable monitor mode on wireless interfaces
Network Discovery - Scan and enumerate wireless networks with detailed information
Packet Capture - Capture packets from targeted access points (background operation)
Handshake Capture - Deauthentication attacks to capture WPA/WPA2 handshakes
Password Cracking - Attempt to crack captured handshakes using wordlists
Remote Execution - All operations run on a remote Kali system via SSH
Related MCP server: Kali Linux MCP Server
Kali Linux System - With aircrack-ng suite installed
SSH Access - Passwordless SSH recommended (key-based authentication)
Wireless Adapter - Compatible adapter that supports monitor mode and packet injection
Node.js - Version 18 or higher
# Clone the repository
git clone https://github.com/schwarztim/sec-aircrack-ng-mcp.git
cd sec-aircrack-ng-mcp
# Install dependencies
npm install
# Build the TypeScript code
npm run buildConfigure the server using environment variables:
Variable | Description | Default |
| Hostname or IP address of Kali system |
|
| SSH username |
|
| Path to SSH private key file | (none - uses default) |
| Directory for capture files on Kali |
|
Add to your claude_desktop_config.json:
{
"mcpServers": {
"aircrack-ng": {
"command": "node",
"args": ["/path/to/sec-aircrack-ng-mcp/dist/index.js"],
"env": {
"KALI_HOST": "192.168.1.100",
"SSH_USER": "kali",
"SSH_KEY": "/path/to/ssh/key"
}
}
}
}Tool | Description |
| Test SSH connection and verify aircrack-ng installation |
| List wireless interfaces and their status |
| Kill processes that interfere with monitor mode |
| Enable monitor mode on a wireless interface |
| Disable monitor mode and restore managed mode |
Tool | Description |
| Scan for wireless networks (returns BSSID, channel, encryption, ESSID) |
| Start packet capture on a specific target (runs in background) |
| Stop a running packet capture |
| Check status of a running capture |
Tool | Description |
| Send deauthentication frames (helps capture WPA handshakes) |
| Perform fake authentication with AP (for WEP attacks) |
Tool | Description |
| Attempt to crack WPA/WPA2 handshake using a wordlist |
| Verify if a valid handshake has been captured |
Tool | Description |
| List all capture files in the captures directory |
| Delete capture files |
| Get detailed information about a wireless interface |
A typical WPA/WPA2 security assessment workflow:
1. test_connection # Verify SSH connectivity and aircrack-ng
2. airmon_check # List available wireless interfaces
3. airmon_check_kill # Kill interfering processes
4. airmon_start(wlan0) # Enable monitor mode -> wlan0mon
5. airodump_scan(wlan0mon, 30) # Scan for networks (30 seconds)
6. airodump_capture(...) # Start capturing target network
7. aireplay_deauth(...) # Deauth to force handshake
8. aircrack_check_handshake(...) # Verify handshake captured
9. aircrack_crack(...) # Attempt to crack password
10. airodump_stop(...) # Stop the capture
11. airmon_stop(wlan0mon) # Restore managed modeAuthorization Required - Only use on networks you own or have explicit written permission to test
SSH Security - Use key-based authentication and restrict SSH access
Capture Files - Captured data may contain sensitive information; handle appropriately
Legal Compliance - Ensure compliance with local laws and regulations
WARNING: Unauthorized access to computer networks is illegal in most jurisdictions.
This tool is intended exclusively for:
Authorized penetration testing
Security research on networks you own
Educational purposes in controlled environments
The authors assume no liability for misuse of this software. Users are solely responsible for ensuring they have proper authorization before conducting any security testing.
# Watch mode for development
npm run dev
# Build for production
npm run build
# Run the server
npm startThis project is licensed under the MIT License - see the LICENSE file for details.
Contributions are welcome! Please feel free to submit a Pull Request.
Aircrack-ng Team - For the excellent wireless security suite
Model Context Protocol - For the MCP specification
Anthropic - For Claude and the MCP ecosystem
Check if a valid WPA handshake has been captured in a pcap file
| Name | Required | Description | Default |
|---|---|---|---|
| capFile | Yes | Capture file path or prefix | |
| bssid | No | Optional: Specific BSSID to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states it 'checks if a valid WPA handshake has been captured', implying a read-only evaluation. Without annotations, this provides sufficient behavioral context, though it does not detail error handling or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that directly states the tool's purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits the tool's return value or output format (e.g., boolean or message), which would be needed by an agent to interpret results. Additionally, it does not clarify constraints like file existence requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond the schema. The description's mention of 'pcap file' aligns with the schema's 'Capture file path or prefix', but no additional semantics are 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 specifies the action ('Check') and resource ('valid WPA handshake in a pcap file'), clearly distinguishing from sibling tools like aircrack_crack (which cracks) and airodump_capture (which captures).
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 when-to-use or when-not-to-use guidance is given. Usage is implied via the tool name and sibling context, but the description does not clarify when to use this over alternatives like checking via airodump_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attempt to crack WPA/WPA2 handshake using wordlist
| Name | Required | Description | Default |
|---|---|---|---|
| capFile | Yes | Capture file path or prefix (will find .cap file) | |
| wordlist | Yes | Path to wordlist file on Kali (e.g., /usr/share/wordlists/rockyou.txt) | |
| bssid | No | Optional: Target BSSID if multiple networks in capture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'Attempt', implying failure possible, but does not disclose time taken, prerequisites, side effects, or response 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?
Single sentence with no waste, but could be more efficient by including key context. Front-loaded verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; description omits critical context like prerequisites, success/failure indicators, and result storage. Incomplete for a cracking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no extra meaning beyond 'using wordlist', which is already in 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 verb 'crack' and the resource 'WPA/WPA2 handshake using wordlist', distinguishing it from sibling tools like aircrack_check_handshake.
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., after capturing a handshake). The description only states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send deauthentication frames to disconnect clients from AP (helps capture WPA handshake)
| Name | Required | Description | Default |
|---|---|---|---|
| iface | Yes | Monitor mode interface | |
| bssid | Yes | Target access point MAC address | |
| count | No | Number of deauth packets to send (default: 5, 0 for continuous) | |
| clientMac | No | Optional: Target specific client MAC address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but discloses minimal behavioral traits. It mentions disconnecting clients (destructive) but lacks details on side effects, permission requirements, or operational constraints beyond 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 that efficiently conveys the action, resource, and purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool and its siblings, the description is too minimal. It lacks workflow context, such as how it relates to airodump_capture or the need for monitor mode, and does not explain the handshake capturing process.
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 all 4 parameters, so the baseline is 3. The description adds little beyond the schema, only providing context about the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Send deauthentication frames' and the resource 'disconnect clients from AP', with a clear purpose 'helps capture WPA handshake'. It effectively distinguishes this tool from siblings like aireplay_fakeauth and aircrack_check_handshake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for handshake capture but does not explicitly state when to use this tool versus alternatives like aireplay_fakeauth. No exclusions or prerequisites are mentioned beyond what the schema provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform fake authentication with AP (used for WEP attacks)
| Name | Required | Description | Default |
|---|---|---|---|
| iface | Yes | Monitor mode interface | |
| bssid | Yes | Target access point MAC address | |
| sourceMac | No | Optional: Source MAC address to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on success/failure outcomes, side effects, or required prior steps (e.g., monitor mode). Minimal behavioral insight beyond the action name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. Very concise, but borderline overly brief for a network attack 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?
No output schema; description omits workflow context, return values, or how it integrates with sibling tools (e.g., needing airodump first). Incomplete for a tool in a multi-step attack sequence.
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 all parameter descriptions (100%). The tool description adds no extra meaning beyond schema; it only restates generic purpose.
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?
Clear verb and resource: 'Perform fake authentication with AP'. States explicit purpose for WEP attacks, distinguishing it from sibling deauth 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 on when to use this tool versus alternatives like aireplay_deauth. Does not mention prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List wireless interfaces and their status. Shows PHY, Interface, Driver, and Chipset.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately describes read-only listing behavior but does not explicitly state it is non-destructive or requires no privileges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words, conveying purpose and output fields.
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?
Simple tool with no parameters or output schema; description fully covers functionality and output columns.
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?
No parameters exist; schema coverage is 100%. Description adds no param info but baseline is 4 for zero-parameter tools.
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 verb 'List' and resource 'wireless interfaces and their status', specifying fields (PHY, Interface, Driver, Chipset). Distinguishable from sibling tools like airmon_start.
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 vs alternatives. Usage is implied but is not stated as a prerequisite for other tools or as a diagnostic step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kill processes that might interfere with monitor mode (NetworkManager, wpa_supplicant, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions killing specific processes but lacks details on side effects (e.g., loss of network connectivity), whether it offers warnings, or if it checks for running processes before killing.
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 directly states the tool's purpose with no extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no params, no output schema), the description is minimally adequate. However, it misses contextual cues like requiring root privileges, the need to run before starting monitor mode, and potential impact on the system. These omissions reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the description correctly indicates no inputs are needed. The baseline for 0 parameters is 4, and the description adequately covers the tool's operation without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Kill' and the resource 'processes that might interfere with monitor mode', listing examples (NetworkManager, wpa_supplicant). It distinguishes itself from sibling tools like airmon_start or airmon_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?
The description implies usage when preparing monitor mode but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites (e.g., root privileges) or ordering relative to siblings like airmon_start.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable monitor mode on a wireless interface. Creates a monitor interface (e.g., wlan0mon).
| Name | Required | Description | Default |
|---|---|---|---|
| iface | Yes | Wireless interface name (e.g., wlan0) | |
| channel | No | Optional: Lock to specific channel (1-14 for 2.4GHz) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions creating a monitor interface, but lacks details on side effects (e.g., needing root, changing interface state, killing conflicting processes), leaving room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no unnecessary words, and front-loads the primary action. 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?
Given the tool's simplicity (2 parameters, no output schema), the description covers the essential action and even provides an example interface name. However, it could briefly mention how the monitor interface is derived or its use in subsequent tools, but this is a minor gap.
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 already provides clear descriptions for both parameters (iface and channel) with 100% coverage. The description does not add extra 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 'Enable' and the resource 'monitor mode on a wireless interface', and distinguishes itself by mentioning the creation of a monitor interface (e.g., wlan0mon), which sets it apart from sibling tools like airmon_check and airmon_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its action (enable monitor mode) and the interface creation, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable monitor mode and restore managed mode on interface
| Name | Required | Description | Default |
|---|---|---|---|
| iface | Yes | Monitor interface name (e.g., wlan0mon) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the core behavior (disabling monitor mode) but omits potential side effects, permissions needed, or failure conditions.
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 of 8 words is extremely concise and front-loaded. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides necessary information. Minor gaps like prerequisites (monitor mode already active) are acceptable but not critical.
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 a clear parameter description. The tool description adds no additional meaning beyond what the schema already provides, so baseline 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 action ('disable monitor mode and restore managed mode') and the target resource ('interface'), distinguishing it from siblings like airmon_start (enable) and airmon_check (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?
No explicit usage guidance or alternatives are mentioned. Context implies it follows monitoring tasks, but there is no when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start capturing packets from a specific access point. Runs in background.
| Name | Required | Description | Default |
|---|---|---|---|
| iface | Yes | Monitor mode interface (e.g., wlan0mon) | |
| bssid | Yes | Target access point MAC address | |
| channel | Yes | Channel of the target AP | |
| outputPrefix | Yes | Prefix for output files (e.g., 'target1') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions 'runs in background', but omits important details: that it is a long-running process, that it creates output files with the given prefix, how it affects system resources, or whether multiple captures can run concurrently. The schema parameters hint at outputPrefix, but the description does not clarify 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 only two sentences, front-loaded with the core purpose. Every word is informative, with no redundant or filler content.
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 tool with 4 required parameters and no output schema, the description is insufficient. It omits critical context: that the capture is continuous until stopped, how to stop it (sibling airodump_stop), that network interface must be in monitor mode (partially covered by iface param description but not tool description), and that output files are generated. The agent lacks enough information to use it correctly in a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add new meaning beyond what the schema provides; it merely restates that packets are captured from a specific access point (which relates to bssid). The background execution note is behavioral, not parameter-specific.
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 'start capturing' and the resource 'packets from a specific access point', and adds 'runs in background' to specify execution mode. This distinguishes it from sibling tools like airodump_scan (which scans for APs) and airodump_status (which checks 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?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that scanning via airodump_scan should precede capture, or that this tool runs asynchronously and must be stopped with airodump_stop. The context signals show many related sibling tools, but the description provides no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for wireless networks. Returns list of access points with BSSID, channel, encryption, and ESSID.
| Name | Required | Description | Default |
|---|---|---|---|
| iface | Yes | Monitor mode interface (e.g., wlan0mon) | |
| duration | No | Scan duration in seconds (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention that monitor mode is required, potential interference, need for root privileges, or any side effects. Only states basic output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with action and output. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a scan tool, description is adequate but missing prerequisites (monitor mode, root) and output format details since no output schema exists. Leaves some ambiguity.
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. Parameters are clearly named (iface, duration) but no extra context or formatting details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it scans for wireless networks and returns a list with specific fields (BSSID, channel, encryption, ESSID). This distinguishes it from sibling tools like airodump_capture which likely captures packets, not just lists.
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 vs alternatives. From sibling names, it's implied this is for initial reconnaissance, but no clear when-not or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check status of a running capture and list captured files
| Name | Required | Description | Default |
|---|---|---|---|
| outputPrefix | Yes | The output prefix used when starting the capture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions checking status and listing files, but does not specify what the status includes (e.g., packet count, duration), whether it requires an active capture, or if it is read-only.
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. The key action 'Check status' is front-loaded, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks details about return values (no output schema) and prerequisites. For a simple status check, it is adequate but could explain the output format and relationship to other capture 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?
Schema coverage is 100% with a clear description of the 'outputPrefix' parameter. The tool description does not add extra meaning beyond the schema, so it meets the baseline but provides no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Check status and list') and the resource ('a running capture and captured files'). It distinguishes from siblings like airodump_capture (starts a capture) and list_captures (lists all captures) by focusing on a specific running capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a capture is running, but does not explicitly state when to use this tool over siblings like airodump_stop or list_captures. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running packet capture
| Name | Required | Description | Default |
|---|---|---|---|
| outputPrefix | Yes | The output prefix used when starting the capture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description lacks behavioral details such as idempotency, error handling, or side effects. It does not disclose what happens if no capture is running or if multiple captures match the prefix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) and front-loaded. While brief, it efficiently conveys the purpose 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?
Given no annotations and a simple operation, the description is too minimal. It lacks context about prerequisites, response, or relationship to airodump_capture. More detail would help the agent understand expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description does not add extra meaning beyond the schema, which already defines the required prefix.
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 'Stop a running packet capture' clearly uses a specific verb and resource, distinguishing it from sibling tools like airodump_capture (start) and airodump_status (check 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?
No guidance is provided on when to use this tool, prerequisites (e.g., capture must be running), or potential errors. Only the core function is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete capture files from the captures directory
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Optional: File pattern to delete (default: all files) |
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 says 'delete' without mentioning permanence, confirmation requirements, or potential side effects (e.g., pattern matching critical files). This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no redundant information. Every word is functional, making it highly efficient for quick comprehension.
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 (single optional parameter, no output schema), the description covers the essential purpose. However, it lacks safety context (e.g., irreversibility) that would be expected given the destructive nature, leaving it marginally 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 already provides full coverage (100%) for the pattern parameter, including its optionality and default behavior. The description adds no additional meaning or context beyond what is in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (capture files in the captures directory). Among siblings like list_captures (listing) and airodump_capture (capturing), this tool uniquely handles deletion, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives such as list_captures or when deletion is appropriate. No prerequisites, context, or warnings about irreversible actions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a wireless interface
| Name | Required | Description | Default |
|---|---|---|---|
| iface | Yes | Interface name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavior. It only says 'get detailed information' but doesn't specify what information, whether the tool is read-only, requires privileges, or its effects. The behavioral transparency is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits important details that could be included without losing conciseness. It is not optimally front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no output schema), the description is minimally viable. It lacks details about return format, relationship to other wireless tools, or any behavioral notes. However, for a straightforward info-getter, it is passable.
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 the parameter 'iface' described as 'Interface name'. The description adds no additional meaning beyond the schema. A score of 3 is appropriate given high schema coverage and no extra param insights.
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 'Get detailed information about a wireless interface', using a specific verb and resource. It is distinct from sibling tools which are action-oriented (e.g., aircrack, aireplay). However, it doesn't explicitly differentiate itself from similar query tools if any exist.
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. There are no prerequisites, exclusions, or hints about context (e.g., needing airmon started). The description lacks any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all capture files in the captures directory
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides only minimal behavioral information: it lists files. No mention of sorting, filtering, return format, side effects, or whether it is a read-only operation. The agent lacks crucial details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single focused sentence with no extraneous words. Perfectly concise.
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 with no parameters, and the description is adequate for a basic listing. However, it does not specify the output format or behavior when the directory is empty, leaving some gaps.
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?
There are no parameters; the description adds value by specifying 'capture files' rather than generic files. According to guidelines, 0 params yields a baseline of 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 (List) and the resource (capture files in the captures directory), which is specific and distinguishes it from sibling tools like cleanup_captures or airodump_capture.
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 given on when to use this tool versus alternatives (e.g., airodump_scan, airodump_status). The description lacks context for selecting this tool over its many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test SSH connection to Kali Linux and verify aircrack-ng is installed
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states what the tool does but not what happens on success/failure or side effects, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no wasted words, earning 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 zero parameters, no output schema, and a simple action, the description fully covers the tool's purpose and 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?
No parameters exist, so baseline is 4; description adds context about the test, meeting the baseline.
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 SSH connection to Kali Linux and verifies aircrack-ng is installed, distinguishing it from sibling tools focused on specific aircrack-ng operations.
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 as a prerequisite check before other aircrack-ng tools, but lacks explicit when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear, distinct purpose with a unique verb-noun combination. For example, aircrack_check_handshake and aircrack_crack are different stages, and aireplay_deauth vs aireplay_fakeauth are separate attacks.
All tools follow a consistent naming pattern: tool prefix (aircrack, aireplay, etc.) followed by underscore and action. All use snake_case and descriptive verbs, making it easy to predict the function.
16 tools cover the full aircrack-ng workflow: interface setup, scanning, capture, injection, and cracking. Each tool serves a necessary role without being excessive.
The set covers the main WPA/WPA2 attack chain well, but is missing a tool for WEP cracking (aireplay_fakeauth is present but no aircrack for WEP). This is a minor gap in an otherwise thorough surface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-aircrack-ng-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
