Password AI MCP
Password AI MCP is a zero-knowledge password management server that provides tools for generating, analyzing, and securing passwords. All processing happens locally β no input data is stored, logged, or transmitted.
Generate passwords (
generate_password): Create secure random passwords with customizable length, character sets (uppercase, lowercase, digits, symbols), exclusion of ambiguous characters, and batch generation.Check password strength (
check_strength): Analyze a password's strength with detailed scoring and feedback.Hash passwords (
hash_password): Hash a password using MD5, SHA1, SHA256, SHA512, or SHA3-256, with optional salt.Estimate crack time (
estimate_crack_time): Calculate how long it would take to brute-force a password at a specified guess rate (default: 10 billion guesses/second).
Password Ai MCP
Password manager MCP β generate, strength-check, breach monitoring, entropy calculation
Password manager MCP β generate, strength-check, breach monitoring, entropy calculation. Zero-knowledge. MIT.
π Quick Start
# Install via pip
pip install password_ai_mcp
# Or install via Smithery
npx -y @smithery/cli@latest install password-ai-mcp --client claudeRelated MCP server: Encoder AI MCP
β¨ Features
MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance
π Documentation
π‘οΈ Compliance
This MCP server is built with EU AI Act compliance built-in:
β Article 9 β Risk Management System
β Article 13 β Transparency & Instructions for Use
β Article 15 β Bias Detection & Testing
β Article 26 β FRIA Support (where applicable)
β Article 50 β AI Content Watermarking (where applicable)
Need help getting compliant? Book a free 15-min diagnostic β
π’ Enterprise
Need custom development, SLA guarantees, or white-label deployment?
Pro: $99/mo β Full MCP suite + EU AI Act tracking
Enterprise: $499/mo β Custom dev + SLA + Dedicated support
View Pricing β | Contact Sales β
π€ Part of the MEOK Ecosystem
This server is part of the MEOK AI Labs ecosystem β 300+ MCP servers for sovereign AI governance.
Domain | Purpose |
EU AI Act compliance marketplace | |
AI safety & monitoring | |
Sovereign AI platform | |
Legacy modernization |
π License
MIT Β© CSOAI-ORG
Pairs with MEOK Governance Suite
Build something that touches users? You need compliance. MEOK ships 38 governance MCPs that drop in alongside this tool β EU AI Act, DORA, NIS2, CRA, GDPR, ISO 42001, FDA SaMD, MDR, Basel, MiFID II, MiCA, COPPA, and more.
# One-shot install of the governance pack
npx meok-setup --pack governanceFree tier: 10 calls/day per MCP. Pro tier (Β£79/mo): unlimited + cryptographically signed compliance attestations your auditor verifies independently.
β Full catalogue: councilof.ai/catalogue β MEOK AI Labs: meok.ai
πΈ Try MEOK in 30 seconds β instant buy ladder
Tier | Price | What you get | Stripe |
Smoke test | Β£1 | Signed sample MCP-Hardening report + Article 50 PDF | |
Quick Kit | Β£9 | EU AI Act Article 50 implementation guide (C2PA + EU-Icon) | |
Founder Call | Β£29 | 30-min 1-on-1 with the founder |
Refundable. UK Stripe β VAT-clean. Builds on the 81-MCP MEOK fleet. Verify any signed report at https://meok.ai/verify.
Configuration
Add to your claude_desktop_config.json (Claude Desktop) or your MCP client config:
{
"mcpServers": {
"password-ai-mcp": {
"command": "uvx",
"args": ["password-ai-mcp"]
}
}
}Or: pip install password-ai-mcp then run the password-ai-mcp command (stdio transport).
Examples
Once configured, ask your assistant, for example:
"Use
generate_passwordto β¦""Use
check_strengthto β¦""Use
hash_passwordto β¦"
Available Tools
4 toolscheck_strengthA
Analyze password strength with detailed scoring.
Behavior: This tool is read-only and stateless β it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: password (str): The password to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent β calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | ||
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It explicitly states read-only, stateless, idempotent behavior, rate limits, authentication needs, error handling, and data privacy. This is comprehensive and beyond typical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings but contains redundancy (e.g., 'Behavior' and 'Behavioral Transparency' overlap). It is longer than necessary, which slightly reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It covers authentication, rate limits, idempotency, and error handling. However, the 'When to use' section is too generic, and the parameter descriptions are weak, leaving minor 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?
Schema description coverage is 0%, so the description must compensate. The 'Args' section provides basic info ('The password to analyze or process') but lacks detailβe.g., the api_key's purpose is unclear despite optionality. The descriptions add minimal value over the schema's type names.
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 'Analyze password strength with detailed scoring', which is a specific verb+resource. It distinguishes from sibling tools (estimate_crack_time, generate_password, hash_password) as its focus is on strength analysis, not generation or time estimation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'When to use' and 'When NOT to use' sections, providing context. However, the when-to-use guidance ('structured analysis or classification') is generic and does not explicitly differentiate from siblings or specify prerequisites. Lacks mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_crack_timeA
Estimate how long to brute-force a password at given guess rate.
Behavior: This tool is read-only and stateless β it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: password (str): The password to analyze or process. guesses_per_second (float): The guesses per second to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent β calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | ||
| guesses_per_second | No | ||
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: read-only, stateless, idempotent, rate limits, authentication, error handling, and data privacy. This is comprehensive and exceeds typical disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings and a front-loaded first sentence. While lengthy, each section contributes to understanding. It is appropriately sized for the detail needed, though some redundancy exists between the 'Behavior' and 'Behavioral Transparency' sections.
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 explains purpose, usage, and behavior well, but fails to describe the output format or structure, despite an output schema existing. It also omits any comparison to sibling tools in terms of when to use each. Overall, it is adequate but has notable 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?
The 'Args' section merely restates parameter names (e.g., 'The password to analyze or process') without adding meaning beyond the schema. Default values are mentioned in the schema but not in the description. Given 0% schema coverage, the description should compensate but does not.
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 opens with a specific verb+resource: 'Estimate how long to brute-force a password at given guess rate.' This clearly distinguishes it from siblings like check_strength, generate_password, and hash_password, which handle different aspects of password management.
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 explicit 'When to use' and 'When NOT to use' sections, guiding the agent on appropriate contexts. However, the 'When to use' phrasing is somewhat generic ('structured analysis or classification') and does not directly contrast with sibling tools, which could improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_passwordB
Generate secure random passwords.
Behavior: This tool generates structured output without modifying external systems. Output is deterministic for identical inputs. No side effects. Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: length (int): The length to analyze or process. uppercase (bool): The uppercase to analyze or process. lowercase (bool): The lowercase to analyze or process. digits (bool): The digits to analyze or process. symbols (bool): The symbols to analyze or process. exclude_ambiguous (bool): The exclude ambiguous to analyze or process. count (int): The count to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent β calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | ||
| uppercase | No | ||
| lowercase | No | ||
| digits | No | ||
| symbols | No | ||
| exclude_ambiguous | No | ||
| count | No | ||
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description thoroughly covers side effects (read-only, no side effects), authentication (none for basic use, API key for pro), rate limits (10/day free, unlimited pro), error handling, idempotency, and data privacy. This fully compensates for missing annotations.
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?
While structured with clear sections, the description is overly verbose and repetitive (e.g., Behavioral Transparency duplicates Behavior). It could be much shorter for a simple tool like password generation.
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?
Despite behavioral details, the description lacks essential context about the output format and fails to explain parameters meaningfully. Given 8 parameters and no output schema details provided here, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section uses generic phrases like 'The length to analyze or process' for every parameter, failing to explain their specific meaning for password generation (e.g., length of password). Schema coverage is 0%, so the description should add meaning but does not.
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 'Generate secure random passwords,' which is a specific verb and resource. It also distinguishes from sibling tools like check_strength, estimate_crack_time, and hash_password that 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 'When to use' and 'When NOT to use' sections are generic and mismatched with password generation (e.g., 'structured analysis or classification of inputs'). They do not provide clear guidance on when to use this tool versus its siblings or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hash_passwordA
Hash a password. Algorithms: md5, sha1, sha256, sha512, sha3_256.
Behavior: This tool is read-only and stateless β it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: password (str): The password to analyze or process. algorithm (str): The algorithm to analyze or process. salt (str): The salt to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent β calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | ||
| algorithm | No | sha256 | |
| salt | No | ||
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides an extensive 'Behavioral Transparency' section covering side effects (read-only, stateless, idempotent), authentication needs (optional API key for pro tiers), rate limits (10/day free), error handling (structured errors), and data privacy (no storage). Since no annotations exist, this fully compensates and even exceeds expectations.
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 redundantly structuredβ'Behavior:' and 'Behavioral Transparency:' sections overlap (both mention read-only, idempotent). The 'When to use' section is vague and adds no real guidance. While it is organized with headings, it could be trimmed to essential information without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, algorithms, behavioral traits, error handling, and rate limits comprehensively. It mentions the output schema is available (not described, but that's permissible per instructions). However, it lacks explicit instruction on how to use the api_key parameter for pro/enterprise tiers, leaving 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?
Schema description coverage is 0%, yet the description's 'Args' section only repeats parameter names with generic phrases like 'The password to analyze or process.' It does not clarify valid algorithm values (though listed earlier), the role of salt, or how api_key is used. More detail is needed to guide correct parameter usage 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 'Hash a password' and lists supported algorithms (md5, sha1, sha256, sha512, sha3_256), which directly conveys the tool's function. It distinguishes from siblings like check_strength and estimate_crack_time by focusing on hashing rather than analysis or estimation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'When to use' and 'When NOT to use' sections, but they are generic ('structured analysis or classification') and do not specifically guide when to use hashing versus sibling tools. It fails to mention that this tool is appropriate for password storage or verification, nor does it contrast with check_strength or generate_password.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v1.0.0- First observed
check_strength - First observed
estimate_crack_time - First observed
generate_password - First observed
hash_password
TDQS
Scored across 4 tools
Each tool has a unique and clearly distinct purpose: check_strength analyzes strength, estimate_crack_time estimates cracking time, generate_password creates passwords, and hash_password hashes them. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (check_strength, estimate_crack_time, generate_password, hash_password), using snake_case throughout.
Four tools is an appropriate number for a password utility, covering analysis, estimation, generation, and hashing without being too few or excessive.
The tool set covers the main password-related operations: strength analysis, crack time estimation, generation, and hashing. Minor gaps like entropy calculation or password comparison are not critical for the core functionality.
Maintenance
Related MCP Connectors
MCP server for Flux AI image generation
MCP server for NanoBanana AI image generation and editing
MCP server for Qwen Image 3 AI image generation
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceBackup AI - MCP server providing AI-powered tools and automation by MEOK AI Labs4 npm121 PyPIMIT

Encoder AI MCPofficial
AlicenseCqualityBmaintenanceEncoder AI - MCP server providing AI-powered tools and automation by MEOK AI Labs57 npm89 PyPIMIT- AlicenseNot gradedqualityAmaintenanceBlockchain AI - MCP server providing AI-powered tools and automation by MEOK AI Labs5 npm104 PyPIMIT
- AlicenseNot gradedqualityFmaintenanceConsciousness Engine - MCP server providing AI-powered tools and automation by MEOK AI Labs4 npm92 PyPIMIT