# Reported issues for KeyCloak MCP

Pod holds 14 of 14 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [KeyCloak MCP](/mcp/keycloak-mcp).

## Most discussed

### get_admin_events / get_user_attribute_history return raw attribute values in representation

## Summary

`get_admin_events` and `get_user_attribute_history` return the admin event `representation`
field verbatim (truncated at `max_repr`, default 500, and the caller can pass `-1` to disable
truncation). The representation of a user-update event is the full user JSON, including
`attributes`.

Deployments that keep a secret in a custom user attribute therefore get that secret echoed back
by a read-only tool. A concrete case: a realm that stores an operator-issued temporary password
in a us

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/87) · 2026-08-14 · open · 0 comments

### 調査: OAuth 2.1 リファレンス実装との突き合わせ(Cloudflare remote-mcp-github-oauth)

## 背景
トレンドMCP調査で Cloudflare の OAuth Provider リファレンス実装（cloudflare/ai の remote-mcp-github-oauth デモ）を確認。OAuth 2.1 の完全実装をライブラリ化し、Durable Objects で認証済みユーザーコンテキストを保持、SQL インジェクション対策・permission-based コントロールを明記した設計。

参考: https://github.com/cloudflare/ai/tree/main/demos/remote-mcp-github-oauth

## 検討したい点
本サーバーは Keycloak Admin REST API を Service Account 経由で扱う認証まわりのMCPサーバーであり、上記リファレンスの認可設計・入力サニタイズの考え方が直接参考になる可能性がある。

- [ ] 現行の認証・認可フローと比較し、抜け漏れがないか確認
- [ ] permission-based コントロールの粒度を見直す価値があるか

まだ検討段階。実装の優先度は

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/80) · 2026-08-06 · open · 0 comments

### Add a live smoke test that exercises every registered tool

## Motivation

Unit tests check logic against fixtures. They cannot tell you that a tool users actually call has stopped returning real data — a tool that exists but does not work is worse than no tool.

This happened for real in `jquants-mcp`: the earnings-calendar tools returned well-formed **empty** results for every query while the whole suite stayed green (shigechika/jquants-mcp#523). A live smoke test was built there to close the gap, and on its first production run it found three defects,

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/56) · 2026-07-25 · closed · 0 comments

### feat: spray/breach detection via per-external-IP success rate (single rule)

## Problem

Password-spray sources that breach accounts are **invisible to a raw failure-count threshold**. Real production evidence (an external attacker vs. a benign shared-egress gateway seen in the same window):

| source | failures | reality | old count-threshold verdict |
|--------|---------:|---------|-----------------------------|
| campus NAT gateway (internal range) | 328 | benign | (high count, ignored correctly) |
| **attacker (external)** | **86** | **spray, 2 breaches** | **"under 

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/48) · 2026-07-21 · open · 0 comments

### feat: classify known relay egress ranges (Cloudflare WARP / iCloud Private Relay) in detect_login_loops

## Background

Morning patrols repeatedly flag "login loops" that are not attacks but a UX artifact of encrypted relay services rotating egress IPs mid-session, which makes the Shibboleth SP session establishment spin (rapid successful LOGINs, zero LOGIN_ERROR, converging once the client reaches the SP or switches network).

Confirmed relay families in production:

- **Cloudflare WARP**: `2a09:bac2::/32`, `2a09:bac3::/32` (AS13335)
- **iCloud Private Relay / Fastly egress**: `2a04:4e41::/32` (ob

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/47) · 2026-07-21 · open · 0 comments

### robustness: set_user_enabled no-op check depends on brief-rep 'enabled' field

Follow-up from the review of #41.

The no-op fast path `if u.get("enabled") == enabled:` relies on the brief representation returned by `_resolve_user` including the `enabled` field. If it were ever absent, `None == False` is `False`, so the tool proceeds to a redundant GET+PUT instead of the intended no-op.

Impact is harmless (a redundant but correct write), so this is low priority. Consider fetching the current `enabled` from the full representation, or documenting the assumption.

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/44) · 2026-07-13 · open · 0 comments

### perf: set_user_enabled issues 3 HTTP round-trips

Follow-up from the review of #41.

`set_user_enabled` performs three sequential requests: username search (`_resolve_user`) + `GET /users/{id}` + `PUT /users/{id}`, versus two for `reset_password`.

The extra `GET /users/{id}` is currently justified: the list/search endpoint returns a *brief* representation without `attributes`, so reusing the `_resolve_user` result for the PUT would drop custom attributes. Reducing to two round-trips would require `_resolve_user` (or a variant) to fetch the ful

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/43) · 2026-07-13 · open · 0 comments

### feat: add get_ip_activity tool for exhaustive per-IP investigation

## Problem

`get_events(ip_address=...)` filters by IP client-side over a single page
(`max_results`, default 50). KeyCloak's `/events` endpoint has no server-side
IP filter, so activity from a given IP outside that page is silently missed.
No tool currently gives a complete picture of one IP's activity (users
touched, clients/SPs, timeline).

## Proposed Fix

Add `get_ip_activity(ip_address, event_types="LOGIN,LOGIN_ERROR", date_from="",
date_to="", max_timeline=200)`. Follows the same full-pag

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/30) · 2026-07-03 · closed · 0 comments

## Most recent

### docs: user documentation site on GitHub Pages (family rollout)

## Summary

Roll out the family documentation-site pattern to this repository: a task-oriented user guide on GitHub Pages, complementing the reference README.

Template (live example): https://github.com/shigechika/mcp-stdio — issue shigechika/mcp-stdio#284, scaffold PR shigechika/mcp-stdio#285, published at https://shigechika.github.io/mcp-stdio/ (Japanese at `/ja/`).

## Steps

1. Copy the three-piece scaffold from mcp-stdio and adapt:
   - `mkdocs.yml` — change `site_name` / `site_url` / `rep

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/29) · 2026-07-02 · closed · 0 comments

### tests: test_client.py fails under newer respx/httpx (AllMockedAssertionError)

## Problem

`tests/test_client.py` has ~23 failing tests on `main` (pre-existing, unrelated to recent feature work). They fail with `respx.models.AllMockedAssertionError`, a respx/httpx version incompatibility — the mocked routes are no longer matched the way the test fixtures assume.

Confirmed pre-existing: checking out `origin/main` and running the suite reproduces the same ~23 failures. The `health_check` PR (#20) only touched `tests/test_server.py` (all green) and did not introduce or fix t

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/21) · 2026-06-18 · closed · 0 comments

### events tools: default date_from to last 24h to prevent full-scan hang

## Problem

All event-based tools (`get_events`, `get_login_stats_by_client`, `get_login_stats_by_hour`, `detect_login_loops`, `get_login_failures_by_ip`) accept an optional `date_from` parameter. When `date_from` is omitted, the tool scans all events from the beginning of the database — potentially millions of records — causing the process to hang (RSS > 5 GB, no response for 60+ minutes).

This is documented as a known issue in keycloak-mcp v0.3.0 and requires the caller to always supply `date

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/11) · 2026-05-01 · closed · 0 comments

### _format_ts: use UTC to avoid OSError on Windows for epoch values near 0

## Background

\`keycloak_mcp/server.py:_format_ts\` currently does:

\`\`\`python
datetime.fromtimestamp(ts).astimezone().strftime(\"%Y-%m-%d %H:%M:%S\")
\`\`\`

On Windows, \`datetime.fromtimestamp(0)\` (and negative/near-zero timestamps) raises \`OSError\` because the underlying \`localtime()\` rejects pre-1970 values in the local timezone. The function catches \`OSError\` and falls back to \`str(epoch_ms)\`, so production is unaffected — but the formatted output is lost.

This surfaced in CI

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/4) · 2026-04-14 · closed · 0 comments

### ci: Windows smoke test should exercise stdio_server, not just pytest

## Background

PR #2 added a \`windows-latest × Python 3.12\` job to CI to guard against Windows-specific regressions (cf. [modelcontextprotocol/python-sdk#2433](https://github.com/modelcontextprotocol/python-sdk/issues/2433), where \`stdio_server()\` emits CRLF instead of LF on Windows and corrupts the NDJSON wire format).

However, the current Windows job only runs \`pytest\`, which exercises pure-Python logic (client helpers, formatters, etc.). It never actually spawns the MCP server and read

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/3) · 2026-04-14 · closed · 0 comments

### ci: add Windows smoke test to guard stdio regressions (cf. python-sdk#2433)

## Background

This project depends on the official `mcp` package (a.k.a. `modelcontextprotocol/python-sdk`), whose `stdio_server()` currently emits CRLF instead of LF on Windows, corrupting the NDJSON wire format used by MCP. The upstream bug is tracked at [modelcontextprotocol/python-sdk#2433](https://github.com/modelcontextprotocol/python-sdk/issues/2433).

Current CI only runs on `ubuntu-latest`, so any Windows-specific regression (stdio newlines, path handling, signal behavior) goes undetec

[Read the thread](https://github.com/shigechika/keycloak-mcp/issues/1) · 2026-04-14 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/shigechika/keycloak-mcp/issues).