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., "@john-the-ripper-mcp crack these MD5 hashes using rockyou"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides AI assistants with access to John the Ripper, the legendary password security auditing and recovery tool. This server executes commands on a remote Kali Linux system via SSH, enabling secure password analysis workflows.
Password Cracking - Multiple attack modes: wordlist, incremental, single crack, and rules-based
Hash Management - Show cracked passwords, manage pot files, identify hash types
Session Control - Create, monitor, restore, and terminate cracking sessions
Hash Extraction - Extract hashes from encrypted files (ZIP, PDF, SSH keys, Office docs, etc.)
Benchmarking - Test cracking performance for different hash formats
Rules Engine - List and test password mangling rules
Related MCP server: K-MCP: Kali Model Context Protocol Server
# Clone the repository
git clone https://github.com/schwarztim/sec-john-the-ripper-mcp.git
cd sec-john-the-ripper-mcp
# Install dependencies
npm install
# Build
npm run buildThe server connects to a remote Kali Linux system via SSH. Configure via environment variables:
Variable | Description | Default |
| SSH hostname or IP of Kali system |
|
| SSH username (optional) | (none) |
| Path to john binary on remote system |
|
| Remote working directory for temp files |
|
SSH Access - Passwordless SSH key authentication to your Kali system
John the Ripper - Installed on the remote Kali system (apt install john)
Node.js - Version 18+ recommended
Add to your claude_desktop_config.json:
{
"mcpServers": {
"john-the-ripper": {
"command": "node",
"args": ["/path/to/sec-john-the-ripper-mcp/dist/index.js"],
"env": {
"JOHN_SSH_HOST": "your-kali-host",
"JOHN_SSH_USER": "kali"
}
}
}
}Tool | Description |
| Start password cracking with configurable modes and options |
| Display cracked passwords from hash files |
| Check the status of running sessions |
| Resume an interrupted cracking session |
| List all active and saved sessions |
| Terminate running John processes |
Tool | Description |
| Identify hash type(s) for given values |
| List supported hash formats with optional filtering |
| Extract hashes from encrypted files using *2john utilities |
Tool | Description |
| List available rules or test rules against sample words |
| Run performance benchmarks for hash formats |
| Manage the john.pot file (show, clear, export, search) |
Use john_crack with:
- hash_content: "5f4dcc3b5aa765d61d8327deb882cf99"
- format: "raw-md5"
- wordlist: "/usr/share/wordlists/rockyou.txt"Use john_identify with:
- hash: "$2a$10$N9qo8uLOickgx2ZMRZoMy..."Use john_hash_extract with:
- type: "zip"
- file_path: "/path/to/encrypted.zip"Use john_status with:
- session: "my-crack-session"zip - ZIP archives
rar - RAR archives
pdf - PDF documents
ssh - SSH private keys
gpg - GPG/PGP keys
office - Microsoft Office documents
keepass - KeePass databases
7z - 7-Zip archives
bitlocker - BitLocker volumes
luks - LUKS encrypted volumes
truecrypt / veracrypt - TrueCrypt/VeraCrypt volumes
ethereum / bitcoin - Cryptocurrency wallets
This tool is intended for authorized security testing only. Ensure you have proper authorization before:
Testing password strength on systems you own or administer
Conducting penetration tests with written permission
Recovering passwords for files you have legitimate access to
Unauthorized password cracking is illegal. Always follow your organization's security policies and applicable laws.
MIT License - See LICENSE for details.
Contributions welcome! Please open an issue or submit a pull request.
John the Ripper by Openwall
Built with the Model Context Protocol SDK
Run benchmarks to test cracking speed for different hash types
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Specific format to benchmark (optional, benchmarks all if not specified) | |
| duration | No | Benchmark duration in seconds per format |
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, but it only states that benchmarks are run without explaining side effects, output format, or potential resource usage. This leaves significant behavioral gaps.
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 directly conveys the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters, but the description lacks information about what the benchmark produces (e.g., output format) and any behavioral caveats. While the core purpose is clear, the absence of output schema makes this a notable 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 input schema already describes both parameters (format, duration) with 100% coverage, so the description adds no additional semantic 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?
The description clearly states the tool runs benchmarks for cracking speed across hash types, using a specific verb ('Run') and unique resource (benchmarks), distinguishing it from sibling tools like john_crack and john_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 description implies the tool is for testing cracking speed, which provides clear context for when to use it. However, it does not explicitly mention alternatives or exclusions, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start password cracking with John the Ripper. Supports various modes including wordlist, incremental, and single crack.
| Name | Required | Description | Default |
|---|---|---|---|
| fork | No | Number of parallel processes to use | |
| rules | No | Rule set to apply (e.g., Single, Wordlist, Extra, Jumbo, KoreLogic) | |
| format | No | Hash format (e.g., raw-md5, raw-sha256, bcrypt, ntlm, descrypt). Use john_formats to list available formats. | |
| session | No | Session name for this cracking job (allows restore/status) | |
| wordlist | No | Path to wordlist file for dictionary attack (e.g., /usr/share/wordlists/rockyou.txt) | |
| hash_file | No | Path to the file containing password hashes (on remote Kali system) | |
| incremental | No | Incremental mode name (e.g., ASCII, Alnum, Alpha, Digits, Lower, Upper) | |
| hash_content | No | Hash content to crack (will be written to a temp file). Use this OR hash_file, not both. | |
| max_run_time | No | Maximum run time in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention whether the tool runs in the foreground, how long it might take, whether it creates session files, or any side effects (e.g., writing to a pot file). For a resource-intensive tool like John the Ripper, this is a significant omission.
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, no unnecessary words. It is front-loaded with the primary purpose and quickly lists supported modes. This is appropriately concise and well-structured for an AI-readable description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 optional parameters, no output schema, no annotations), the description is too thin. It doesn't explain what happens after the command completes, how to retrieve results, or how the tool interacts with siblings like john_status and john_show. The agent would need to infer the workflow from the schema and sibling names, which is a 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?
Schema description coverage is 100%, so the parameters are already well-documented. The description mentions 'wordlist' and 'incremental' modes, but these map directly to the 'wordlist' and 'incremental' parameters without adding new semantics. It provides a conceptual overview but no additional detail 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?
The description explicitly states the tool's function: 'Start password cracking with John the Ripper.' This clearly distinguishes it from sibling tools like john_status, john_show, and john_restore, which are auxiliary operations. The mention of supported modes ('wordlist, incremental, and single crack') further clarifies the tool's scope.
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 'Start password cracking' provides clear context for when to use this tool versus the siblings. It implies you should invoke this when you have hashes to crack, while the other tools are for monitoring, restoring, or inspecting results. However, it does not explicitly exclude alternatives or list when-not-to-use scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all supported hash formats. Can filter by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filter formats by keyword (e.g., "md5", "sha", "bcrypt") | |
| details | No | Show detailed format information |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It states the read-only nature ('list') but does not mention any side effects, prerequisites, or output behavior. For a simple list operation, this is adequate but does not go beyond the obvious.
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 sentences, front-loaded with the main action and free of unnecessary details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description covers the core function and filter capability. The details parameter is documented in the schema, so the description is sufficiently complete, though it could have mentioned the details option explicitly.
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% for both parameters (filter and details), so the baseline is 3. The description adds only a generic mention of keyword filtering, which does not provide 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?
The description clearly states the tool lists all supported hash formats and can filter by keyword. This is specific and distinguishes it from sibling tools like john_crack or john_identify, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to know which hash formats are supported. While it doesn't explicitly mention alternatives, the clear context of listing formats is enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract hashes from various file types using John's *2john utilities
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of file to extract hashes from | |
| file_path | Yes | Path to the file on the remote Kali system |
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 mentions using *2john utilities but does not explain output format, potential side effects, whether files are modified, or error handling. This is a significant gap for a tool that runs external processes.
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 is front-loaded with the verb and provides all essential info in under 15 words, with no fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description should cover return values and behavior. It lacks any mention of what the extracted hash output looks like, how to feed it to john_crack, or what happens on unsupported files. This makes it incomplete for a tool that is part of a cracking 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?
The schema already documents both parameters and enumerates all valid types, providing 100% coverage. The description adds the detail that John's *2john utilities are used, but this does not significantly enhance parameter understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Extract hashes), the resource (from various file types), and the mechanism (*2john utilities), which distinguishes it from sibling tools like john_crack and john_identify. It is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool works on files rather than existing hashes, implying it is a preparatory step before cracking. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the hash type(s) for given hash values
| Name | Required | Description | Default |
|---|---|---|---|
| hash | No | Hash string to identify | |
| hash_file | No | Path to file containing hashes to identify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Identify the hash type(s)' without indicating whether the operation is read-only, modifies any state, or what side effects may occur. It provides minimal behavioral context.
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 wasted words. It is front-loaded with the action and resource, making it 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 tool is simple but the description lacks critical context: no output schema exists, yet the return format is not described. It also doesn't explain how this tool fits into a workflow with siblings like john_crack. The minimal description is not fully adequate for an agent to select and invoke it confidently.
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 two parameters (hash and hash_file), so baseline is 3. The description does not add additional meaning beyond the schema; it only generically refers to 'given hash 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 uses a specific verb 'Identify' and a clear resource 'hash type(s)' for 'given hash values'. This distinguishes the tool from siblings like john_crack (which cracks hashes) and john_formats (which lists formats).
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 like john_crack or john_formats. It does not mention prerequisites, exclusions, or typical invocation contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kill a running John the Ripper process or session
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Kill all John processes | |
| session | No | Session name to kill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It mentions 'kill' but does not disclose potential side effects, such as whether it interrupts ongoing cracking, deletes session state, or if 'all' kills all active sessions. The destructive behavior is implied but not elaborated.
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 filler. It is appropriately sized for the tool's purpose, though it could be improved by mentioning that parameters are optional and by clarifying the kill behavior.
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 that this is a destructive operation (killing processes/sessions) and there is no output schema or annotations, the description is incomplete. It lacks critical details about impact, recovery options, and behavior when no parameters are provided. The overall complexity is low, but the destructive nature demands more 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?
The input schema provides 100% coverage for both parameters ('all' and 'session') with clear descriptions. The description adds minimal semantic context beyond mapping 'process' to 'all' and 'session' to the named session, but does not explain precedence or edge cases like what happens if both 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 uses a specific verb (kill) and specifies the resource (John the Ripper process or session). It clearly distinguishes this from sibling tools like john_status, john_restore, and john_crack, all of which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, such as using john_restore to resume a session instead of killing it. It only states what it does, not when it should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage the john.pot file containing cracked passwords
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: show (list contents), clear (empty pot), export (output all) | |
| search | No | Search for specific hash or password in pot file |
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 not disclose that the 'clear' action is destructive and irreversible, nor does it mention output formats or side effects. The only added context is 'containing cracked passwords', which is minimal. This is a significant gap for a tool with a destructive 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 redundant words, making it efficient and well-structured. However, its brevity contributes to vagueness, so it does not earn a 5, but it is appropriately sized for the minimal information it conveys.
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 includes a destructive 'clear' action, no annotations, and no output schema, the description is incomplete. It fails to mention the destructive nature, the difference between 'show' and 'export', or any prerequisites. The schema partially mitigates this, but the overall context remains insufficient for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters (action enum and search). The description adds no extra parameter semantics beyond what the schema already states, so it meets the baseline for high schema coverage but does not exceed it.
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 identifies the resource (john.pot file) and its content (cracked passwords), but the verb 'Manage' is vague and does not specify the concrete operations (show, clear, export) that the schema defines. It also fails to distinguish this from sibling tools like john_show, which likely overlaps with the 'show' action.
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 john_show, john_crack, or john_status. There is no mention of contexts where this tool is preferred, nor any exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore and continue an interrupted cracking session
| Name | Required | Description | Default |
|---|---|---|---|
| session | No | Session name to restore |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only restates the action 'restore and continue' without disclosing side effects, required permissions, state changes, or what happens if the session does not exist. Minimal behavioral detail is provided.
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. It is concise and contains no unnecessary information, while still conveying 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?
For a simple tool with one optional parameter and no output schema, the description is minimally adequate. However, it does not clarify whether the session parameter is required under some conditions, how the restore behaves, or what the return value looks like. It is complete enough for basic usage but lacks nuance.
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 100% coverage for the single parameter, describing 'session' as 'Session name to restore'. The description adds no additional semantic detail, so the schema alone is sufficient. Baseline 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 uses a specific verb ('Restore and continue') and a resource ('interrupted cracking session'), clearly distinguishing this from sibling tools like john_crack (start new) and john_status (check progress). It accurately conveys the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context – when a session has been interrupted – but does not explicitly state when to choose this over alternatives, nor does it mention any prerequisites or exclusions. The 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.
List available mangling rules or test rules against words
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | List available rule sections | |
| test_rules | No | Rule section to test (e.g., Single, Wordlist, Extra) | |
| test_words | No | Words to test the rules against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates read-like operations but does not explicitly state non-destructiveness, nor does it explain interactions between the list and test modes (e.g., whether they are mutually exclusive or how output is presented).
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 conveys the tool's two capabilities without redundancy. Every word is useful, making it appropriately 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?
Given the absence of annotations and an output schema, the description is too sparse. It does not explain expected outputs, parameter combinations (e.g., what happens if both list and test_rules are set), or any error conditions, leaving the agent without sufficient behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides—it essentially restates the parameter purposes without clarifying relationships or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states two distinct actions: listing available mangling rules and testing rules against words. This is specific to rule management and differentiates from sibling tools like john_crack or john_show.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention dependencies, prerequisites, or situations where listing versus testing rules is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active and saved John the Ripper sessions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool lists both active and saved sessions, which is a clear behavioral trait. However, it does not disclose the return format, whether any filtering/ordering is applied, or any other side effects. For a simple read-only listing tool, this is adequate but not rich.
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 immediately conveys the tool's purpose. No filler or 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 no-parameter list tool, the description is sufficient to understand its main purpose. Since there is no output schema, the description could have mentioned what fields/details are returned (e.g., session names, status), but the core functionality is clear and complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% schema coverage). The description does not need to explain any parameters, and the baseline for zero-parameter tools 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 uses a specific verb ('List') and identifies the exact resource ('active and saved John the Ripper sessions'). It clearly distinguishes itself from sibling tools like john_status (status of a session) and john_restore (resume a session) by focusing on listing sessions.
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: call this when you need a list of all active and saved sessions. However, it does not explicitly state when to prefer it over alternatives or mention exclusions (e.g., 'Use john_status for details on a single session'). No explicit when-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show cracked passwords from a hash file or pot file
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Hash format to use | |
| hash_file | No | Path to the hash file to show cracked passwords for | |
| show_left | No | Show uncracked (left) passwords instead of cracked ones | |
| hash_content | No | Hash content (will be written to temp file). Use this OR hash_file. |
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, but it only states the surface action. It does not mention whether the operation is read-only, what output format to expect, or how the show_left parameter affects 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, focused sentence that states the tool's purpose without any fluff or repetition. It is well-structured 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?
The tool has four parameters and no output schema, yet the description only covers the basic purpose. It lacks usage context, expected output, and behavioral details, making it inadequate for an agent to fully understand the tool's capabilities.
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 adds no per-parameter meaning beyond what the schema already provides, but since the schema fully describes each parameter, this is acceptable.
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 shows cracked passwords from a hash or pot file, with a specific verb and resource. However, it does not explicitly distinguish from sibling tools like john_pot or john_status, so it falls 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?
No guidance is given on when to use this tool versus alternatives such as john_crack or john_restore. The description only states what it does, leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a cracking session
| Name | Required | Description | Default |
|---|---|---|---|
| session | No | Session name to check status for (default: default session) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It only states 'check the status' without explaining output format, side effects, or behavior when the session does not exist. Minimal transparency for a tool that could have nuanced 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, concise sentence that avoids unnecessary words. It is appropriately sized for the simplicity of the tool and front-loads the core 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 low complexity (one optional parameter) and no output schema, the one-line description may be minimally adequate. However, it omits what 'status' includes, relationship to sibling tools, and any safety or blocking behavior, which an agent might need.
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 provides 100% coverage for the single parameter, including a clear description and default. The tool description adds no parameter details, so the baseline of 3 applies without any credit beyond 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 uses a specific verb ('check') and resource ('status of a cracking session'), clearly distinguishing it from sibling tools like john_crack, john_show, and john_sessions. It immediately conveys the tool's purpose.
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 john_sessions or john_show. It does not mention prerequisites, such as needing an active session, or exclude use cases.
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.
v1.0.0john_benchmarkjohn_crackjohn_formatsjohn_hash_extractjohn_identifyjohn_killjohn_potjohn_restorejohn_rulesjohn_sessionsjohn_showjohn_statusMost tools have distinct purposes, but john_status and john_sessions could overlap since both deal with session information, and john_show and john_pot both relate to cracked passwords. However, descriptions clarify the specific roles, so confusion is minimal.
All tool names follow a consistent john_ prefix followed by a verb-noun combination (e.g., john_crack, john_show, john_hash_extract). The snake_case style is uniform, making the naming predictable and readable.
12 tools is well within the ideal range for a specialized utility. Each tool addresses a distinct aspect of John the Ripper's workflow, and there is no bloat or unnecessary duplication.
The tool set covers the full lifecycle of password cracking: hash extraction, identification, format listing, cracking, monitoring/restoring, showing results, pot management, benchmarking, rules, and session control. No obvious gaps for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Utility tools for AI agents: hashing, text stats, validation, DNS, currency, GEO audits.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-john-the-ripper-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
