KeyCloak MCP
PYPI · KEYCLOAK-MCP · SCANNED SEP 20
MCP server for KeyCloak Admin REST API via Service Account
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs setuptools.build_meta at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 0 of 29 dependencies flagged as unhealthy. View diagnostics → Pass
Provenance & Transparency32
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 0 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability60
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 5724 tokens (~178/item across 32 items; 32 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management90
- Stability observed for 27 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (91% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 32 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 32 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the KeyCloak MCP server?
KeyCloak MCP runs locally as a PyPI package, launched with uvx keycloak-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · keycloak-mcp
claude mcp add shigechika-keycloak-mcp -- uvx keycloak-mcp
{
"mcpServers": {
"shigechika-keycloak-mcp": {
"command": "uvx",
"args": [
"keycloak-mcp"
]
}
}
} {
"servers": {
"shigechika-keycloak-mcp": {
"command": "uvx",
"args": [
"keycloak-mcp"
]
}
}
} codex mcp add shigechika-keycloak-mcp -- uvx keycloak-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"shigechika-keycloak-mcp": {
"type": "local",
"command": [
"uvx",
"keycloak-mcp"
],
"enabled": true
}
}
} openclaw mcp add shigechika-keycloak-mcp --command uvx --arg keycloak-mcp
mcp_servers:
shigechika-keycloak-mcp:
command: "uvx"
args: ["keycloak-mcp"] {
"McpServers": {
"shigechika-keycloak-mcp": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"keycloak-mcp"
]
}
}
} assistant mcp add shigechika-keycloak-mcp -t stdio -c uvx -a keycloak-mcp
{
"mcpServers": {
"shigechika-keycloak-mcp": {
"command": "uvx",
"args": [
"keycloak-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Sept 26 0
- Stability: 0.87 → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Package version: 0.19.0 → 0.20.0 functional
- 19 Sept 26 +15
- Malware scan: unverified → pass ▲ security
- 18 Sept 26 −14
- Malware scan: pass → unverified ▼ security
- Package version: 0.18.0 → 0.19.0 functional
- 17 Sept 26 +12
- Malware scan: unverified → pass ▲ security
- Stability: pass → 0.80 functional
- 16 Sept 26 −15
- Malware scan: pass → unverified ▼ security
- Stability: 0.97 → pass security
- Schema quality: 136 → 163 ▼ functional
- Package version: 0.17.0 → 0.18.0 functional
- 15 Sept 26 +14
- Malware scan: unverified → pass ▲ security
- Stability: pass → 0.97 functional
- 14 Sept 26 −14
- Malware scan: pass → unverified ▼ security
- Stability: 0.97 → pass security
- 12 Sept 26 +16
- Malware scan: unverified → pass ▲ security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Analysed pypi/keycloak-mcp@0.20.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | setuptools.build_meta |
Background: Why install scripts are a supply-chain risk →
Dependencies 29 packages
| Packages resolved | 29 |
|---|---|
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
count_users ~16
Get total user count in the realm.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
daily_brief ~301
Run a morning Keycloak health check. Checks (all scoped to the last ``since_hours`` hours): - Login statistics (success / failure totals, top failing IPs) - Active sessions by client - Password update events - Admin events (CREATE/UPDATE/DELETE on USER/CLIENT resources) A single IP with login failures >= ``ip_failure_threshold`` is flagged as WARNING (possible brute-force). Independently, the same login events are run through the ``spray_check`` rule (external IP, >= 10 distinct users, success rate < 20%); a match is a [SPRAY] WARNING and the "Spray check" section lists the breached accounts with their evidence tuples (time / ip / username / client). Only accounts in that list may be called breached — see ``spray_check`` for the full row shape and to widen the window or tune the thresholds. ``since_hours`` defaults to 18 (≈ previous 15:00 for a 09:00 morning run). Output tiers: - CRITICAL — API connection failure - WARNING — anomalies detected - OK — clean Args: since_hours: Look-back window in hours (default 18). ip_failure_threshold: Login failures from a single IP that triggers a WARNING (default 50).
| Name | Type | Req | Description |
|---|---|---|---|
| ip_failure_threshold | integer | – | – |
| since_hours | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
detect_login_loops ~178
Detect users with rapid repeated logins (possible redirect loops). Scans all LOGIN events and finds users who logged in more than `threshold` times within `window_seconds`. Args: date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). Empty for all. threshold: Minimum logins within the window to flag (default 10). window_seconds: Time window in seconds (default 60). top: Number of top users to show (default 20). Use 0 for all.
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| threshold | integer | – | – |
| top | integer | – | – |
| window_seconds | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_admin_events ~291
Get KeyCloak admin events (changes performed via the Admin REST API). Admin events record operations performed by service accounts or admin users — e.g. custom user attribute updates (``provisioning_flag``), role / group assignments, client configuration changes. These are distinct from user events (login / password change). Use this when ``UPDATE_PROFILE`` in ``get_events`` is empty but an attribute is known to have changed. Args: operation_types: Comma-separated list of CREATE, UPDATE, DELETE, ACTION. resource_types: Comma-separated list of USER, CLIENT, ROLE, GROUP, REALM_ROLE, etc. resource_path: Filter by resource path (e.g. "users/{userId}"). date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). max_results: Maximum results (default 50). max_repr: Max chars of the representation field. 0 = omit, -1 = full.
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| max_repr | integer | – | – |
| max_results | integer | – | – |
| operation_types | string | – | – |
| resource_path | string | – | – |
| resource_types | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_brute_force_status ~41
Check if a user is temporarily locked due to brute force detection. Args: username: Exact username (email).
| Name | Type | Req | Description |
|---|---|---|---|
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_client ~180
Show one client's configuration, including its authentication flow overrides. Reports an explicit allowlist of fields rather than the raw client representation. A client representation can carry ``secret``, ``registrationAccessToken`` and, for SAML clients, signing material under ``attributes``; ``attributes`` and ``protocolMappers`` are therefore omitted entirely rather than filtered, so nothing credential-shaped reaches tool output, hence LLM context. The headline is ``authenticationFlowBindingOverrides``: pinning one client to a non-default browser flow is how a single SP is made to require OTP while the realm default stays untouched. KeyCloak stores those overrides as flow IDs, so they are resolved to flow aliases here. Args: client_id: The clientId (not the internal UUID).
| Name | Type | Req | Description |
|---|---|---|---|
| client_id | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_client_sessions ~66
Get active sessions for a specific client (SP). Args: client_id: Client ID (e.g., 'xflow', 'shadowserver'). max_results: Maximum results (default 100).
| Name | Type | Req | Description |
|---|---|---|---|
| client_id | string | yes | – |
| max_results | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_events ~189
Get KeyCloak events with optional filters. Args: event_type: Event type filter (e.g., LOGIN, LOGIN_ERROR, UPDATE_PASSWORD). username: Filter by exact username (email). Resolved to user ID internally. client_id: Filter by client ID (SP name). ip_address: Filter events by source IP (client-side filter). date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). max_results: Maximum results (default 50).
| Name | Type | Req | Description |
|---|---|---|---|
| client_id | string | – | – |
| date_from | string | – | – |
| date_to | string | – | – |
| event_type | string | – | – |
| ip_address | string | – | – |
| max_results | integer | – | – |
| username | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_ip_activity ~1,008
Exhaustive investigation of all activity from one source IP address. Unlike `get_events(ip_address=...)`, which filters a single page and can miss activity outside the most recent `max_results` events, this tool fully paginates every requested event type (via `get_events_all`) before filtering by IP, so the result is exhaustive over the requested date range. Use this for brute-force / credential-stuffing / shared-workstation investigations where `get_login_failures_by_ip` told you *which* IP to look at and you now need the full picture for that one IP. Returns a fixed-shape dict (JSON), not formatted text — every key below is always present, even when zero events match. Returns: error: None on success. Set to a descriptive message if event_types resolved to no event types (e.g. empty or all-whitespace/commas); every other key is still present, with an empty/zero result in that case (no data was fetched). ip_address: Echoes the input. site: Site name from KEYCLOAK_SITES_INI, or null if unmatched or unconfigured (see sites_configured to tell those apart). sites_configured: True if KEYCLOAK_SITES_INI was loaded at all. date_from / date_to: The resolved date range actually scanned. event_types: The event types scanned (echoes the input, split). summary: total_events, login_success, login_failure, unique_users, unique_clients, first_seen/last_seen (ISO 8601, null if no match). login_success/login_failure classify EVERY scanned event type by whether its type ends in "_ERROR" (matching the users/clients breakdown below), not just literal LOGIN/LOGIN_ERROR — so widening event_types always keeps these numbers reconciled with the per-user/per-client totals. Always computed over the FULL matched set, unaffected by max_timeline truncation. users: Per-user breakdown (success/failure counts, distinct error codes), sorted by total activity descending.…
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| event_types | string | – | – |
| ip_address | string | yes | – |
| max_timeline | integer | – | – |
No output schema declared.
No examples provided.
get_login_failures_by_ip ~107
Get login failure statistics broken down by source IP. Args: date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). Empty for all. top: Number of top IPs to show (default 20).
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| top | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_login_stats ~82
Get login success/failure statistics with full pagination. Args: date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). Empty for all.
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_login_stats_by_client ~84
Get login statistics broken down by client (SP). Args: date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). Empty for all.
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_login_stats_by_hour ~85
Get login statistics broken down by hour (local time). Args: date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). Empty for all.
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_password_update_events ~93
Get password update events. Args: date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). max_results: Maximum results (default 100).
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| max_results | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_realm_roles ~16
List all realm-level roles.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_realm_security_defenses ~124
Show the realm's security-defense settings (read-only). Reports the realm-level security configuration that the admin console groups under "Security defenses": - Brute force detection: whether it is enabled, the lockout strategy, and the thresholds (max login failures, wait increments, reset window). - Password policy. - Browser security headers. Use this to verify that brute-force protection is actually turned on and how aggressively it locks accounts — the per-user ``get_brute_force_status`` only reflects runtime state, not whether the policy itself is configured.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_session_stats ~16
Get active session count per client.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_totp_users ~260
Report how many users have TOTP (OTP) configured across the realm. Enumerates users and inspects each one's credentials for an ``otp`` entry. KeyCloak has no bulk credential endpoint, so this makes one credential request per user (N+1) — expect it to be slow on large realms; bound it with ``max_users`` (which also short-circuits the user enumeration). Users whose credential lookup fails are counted separately and skipped, so a single transient error does not abort the whole scan. Args: enabled_only: Only scan enabled users (default True). list_users: Include the list of usernames with TOTP (default True). max_users: Cap the number of users scanned. ``0`` (default) falls back to KEYCLOAK_MAX_USERS (default 5000) rather than the whole realm. The N+1 credential loop is also bounded by KEYCLOAK_DEADLINE, so a large realm returns a disclosed sample. When capped, the percentage covers only the sample, not the realm.
| Name | Type | Req | Description |
|---|---|---|---|
| enabled_only | boolean | – | – |
| list_users | boolean | – | – |
| max_users | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_user ~153
Get detailed user information by exact username (email). If KEYCLOAK_USER_ATTRIBUTE_WHITELIST names any custom attribute keys, this also does one extra by-ID lookup and appends whichever of those keys are present on the user (the search endpoint used to resolve the username returns a brief representation that omits ``attributes`` entirely). A whitelisted key whose name looks credential-shaped (contains "password", "secret", "token", etc. — see _looks_like_credential_key) is reported as blocked rather than shown, as a safety net on top of the whitelist itself. Args: username: Exact username (e.g., user@example.com).
| Name | Type | Req | Description |
|---|---|---|---|
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_user_attribute_history ~208
Get admin-side attribute change history for a single user. Queries admin events scoped to ``users/{userId}`` with UPDATE / ACTION operations. Intended for tracking custom attribute changes such as ``provisioning_flag`` which are written by admin API and do **not** surface in ``get_events`` (which only shows user-driven events like LOGIN / UPDATE_PASSWORD). Args: username: Exact username (email). date_from: Start date (YYYY-MM-DD). Defaults to last 24h when omitted (KEYCLOAK_DEFAULT_DATE_FROM_HOURS). date_to: End date (YYYY-MM-DD). max_results: Maximum results (default 100). max_repr: Max chars of the representation field. 0 = omit, -1 = full.
| Name | Type | Req | Description |
|---|---|---|---|
| date_from | string | – | – |
| date_to | string | – | – |
| max_repr | integer | – | – |
| max_results | integer | – | – |
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_user_credentials ~89
List the credential types configured for one user (password, otp, webauthn, …). Use this to check a single user's MFA status: an ``otp`` credential means TOTP/HOTP is configured. Reads ``/users/{id}/credentials`` (read-only; does not create a session). Args: username: Exact username (email).
| Name | Type | Req | Description |
|---|---|---|---|
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_user_sessions ~33
Get active sessions for a user. Args: username: Exact username (email).
| Name | Type | Req | Description |
|---|---|---|---|
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_check ~237
Report server version and KeyCloak backend connectivity / authentication. Call this at session start (or after a tool-call timeout) to confirm the MCP is up, see which version is running, and verify the KeyCloak Admin API is reachable and the service account can authenticate. Lightweight: it acquires an admin access token via the Client Credentials Grant (reusing the cached client) and does NOT enumerate users, events, or sessions. Always returns the same keys: ``status`` (healthy / degraded / error), ``service``, ``version``, ``keycloak_url`` (configured base URL, empty if unset), ``realm`` (configured realm), ``keycloak_version`` (None — not exposed by a cheap call), and ``auth`` (ok / error / missing-env). On a degraded or error result, ``detail`` carries the reason. This description is the only place those value sets are written down. The READMEs used to repeat them, which is three copies to keep in step and two that an LLM never reads — it is handed this text.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_clients ~19
List all SAML/OIDC clients in the realm.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
list_user_groups ~33
List groups a user belongs to. Args: username: Exact username (email).
| Name | Type | Req | Description |
|---|---|---|---|
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
list_users_by_group ~56
List all users in a group. Args: group_name: Group name (partial match). max_results: Maximum results (default 100).
| Name | Type | Req | Description |
|---|---|---|---|
| group_name | string | yes | – |
| max_results | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
logout_user ~36
Force logout a user by removing all their active sessions. Args: username: Exact username (email).
| Name | Type | Req | Description |
|---|---|---|---|
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
reset_password ~66
Reset a user's password. Args: username: Exact username (email). password: New password to set. temporary: If True, user must change password on next login.
| Name | Type | Req | Description |
|---|---|---|---|
| password | string | yes | – |
| temporary | boolean | – | – |
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
reset_passwords_batch ~111
Reset passwords for multiple users from CSV text. Each line should be: username,password If password column is empty, a random 12-char password is generated and included in the response (the caller cannot recover it otherwise). Caller-supplied passwords are never echoed back. Args: csv_text: CSV text with username,password per line (header optional). temporary: If True, users must change password on next login.
| Name | Type | Req | Description |
|---|---|---|---|
| csv_text | string | yes | – |
| temporary | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
search_users ~61
Search users by username, email, first name, or last name. Args: query: Search string (partial match). max_results: Maximum results to return (default 20).
| Name | Type | Req | Description |
|---|---|---|---|
| max_results | integer | – | – |
| query | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
set_user_enabled ~137
Enable or disable a user account. Disabling blocks all authentication (SSO logins) for the user — the containment action for a compromised or decommissioned account. Only the ``enabled`` flag is changed; custom attributes are preserved. Disabling does not terminate existing sessions (an already-issued token stays valid until it expires), so when disabling this reports how many sessions remain and to run ``logout_user`` to end them immediately. Args: username: Exact username (email). enabled: True to enable, False to disable.
| Name | Type | Req | Description |
|---|---|---|---|
| enabled | boolean | yes | – |
| username | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
spray_check ~1,348
Detect password-spray sources and name the accounts they breached — one rule, one call. For every EXTERNAL source IP (anything outside the ranges declared in KEYCLOAK_SITES_INI) seen in LOGIN / LOGIN_ERROR events during the last ``hours``, compute distinct users and success rate. An IP is a spray source when ``unique_users >= min_users`` AND ``success_rate < max_success_rate``. Its successful logins are the breach CANDIDATES; whether they may be called breached depends on the row's ``confidence``. The breach list is built ONLY from LOGIN events whose source IP is the flagged IP, inside the window. Every entry carries the evidence tuple ``{time, ip, username, user_id, client_id}``. A compromised account can therefore never be reported without an actual login event from the spray source — do not add names that are not in ``spray[].breached``. ``confidence`` separates a spray from a shared egress (school NAT, home line, VDI) that merely looks like one by volume. It is "low" — treat the successes as "verify with the owner", never publish them as breached — when any of these ``signals`` holds: ``user_success_rate`` (distinct users that logged in at least once ÷ distinct users) >= ``max_user_success_rate`` (real sprays sit at 0.0–0.06; a school NAT with students retyping a mistyped domain sat at 0.47), or ``failure_concentration`` (share of failures on the single most-failing username) >= ``max_failure_concentration`` (one locked-out user retrying from a shared line produced 0.91), or the IP is in KEYCLOAK_KNOWN_EGRESS. Only ``confidence: high`` rows are a breach verdict. Read ``top_failed_users`` and ``not_found_domains`` (domains of usernames that do not exist — typos of the real domain are humans, not a scraped list) before writing anything up. Returns a fixed-shape dict: window: {hours, since, until} actually scanned. complete: False if event pagination was cut short (KEYCLOAK_DEADLINE / KEYCLOAK_MAX_EVENTS). When False, treat the result as a lowe…
| Name | Type | Req | Description |
|---|---|---|---|
| hours | integer | – | – |
| max_failure_concentration | number | – | – |
| max_resolves | integer | – | – |
| max_success_rate | number | – | – |
| max_user_success_rate | number | – | – |
| min_report_users | integer | – | – |
| min_users | integer | – | – |
No output schema declared.
No examples provided.
What is the KeyCloak MCP server?
KeyCloak MCP is listed in the public MCP registry as io.github.shigechika/keycloak-mcp. MCP server for KeyCloak Admin REST API via Service Account. This page covers its PyPI package (keycloak-mcp).
Is the KeyCloak MCP server safe to use?
KeyCloak MCP scores 75 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the KeyCloak MCP server expose?
KeyCloak MCP exposes 32 tools: health_check, count_users, search_users, get_user, reset_password, and 27 more. Their descriptions and schemas cost roughly 5,724 tokens of context every time the server is loaded.
Is the KeyCloak MCP server still maintained?
KeyCloak MCP is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.