Skip to main content
Glama

MCP Scorecard: 74/100

Password Ai MCP

MEOK AI Labs GSPC License PyPI

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 claude

Related 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

councilof.ai

EU AI Act compliance marketplace

safetyof.ai

AI safety & monitoring

meok.ai

Sovereign AI platform

cobolbridge.ai

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 governance

Free 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

https://buy.stripe.com/5kQ6oJ0xS3ce8sl7ew8k91j

Quick Kit

Β£9

EU AI Act Article 50 implementation guide (C2PA + EU-Icon)

https://buy.stripe.com/5kQ6oJ0xS3ce8sl7ew8k91j

Founder Call

Β£29

30-min 1-on-1 with the founder

https://buy.stripe.com/5kQ6oJ0xS3ce8sl7ew8k91j

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_password to …"

  • "Use check_strength to …"

  • "Use hash_password to …"

Available Tools

4 tools
check_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
passwordYes
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
passwordYes
guesses_per_secondNo
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
lengthNo
uppercaseNo
lowercaseNo
digitsNo
symbolsNo
exclude_ambiguousNo
countNo
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
passwordYes
algorithmNosha256
saltNo
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

  1. 4 tool updatesv1.0.0
    • First observedcheck_strength
    • First observedestimate_crack_time
    • First observedgenerate_password
    • First observedhash_password

TDQS

A4/5.0

Scored across 4 tools

Disambiguation5/5

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.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (check_strength, estimate_crack_time, generate_password, hash_password), using snake_case throughout.

Tool Count5/5

Four tools is an appropriate number for a password utility, covering analysis, estimation, generation, and hashing without being too few or excessive.

Completeness4/5

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

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers