The Skycloak MCP server gives your AI assistant your whole platform: clusters, realms, applications, SSO, custom domains, WAF, webhooks, SIEM and branding. One command, browser sign-in, nothing to install.
$ claude mcp add --transport http skycloak https://mcp.skycloak.io
No API key to create, paste into a config file, or forget to rotate. Your client opens a browser and you approve.
An MCP server for Keycloak is a Model Context Protocol endpoint that lets an AI assistant read and change your identity infrastructure through defined tools instead of a dashboard or hand-written API calls. The Skycloak MCP server is hosted at https://mcp.skycloak.io and exposes every operation the Skycloak platform API supports, spanning managed Keycloak clusters, realms, applications, identity providers, users, custom domains, edge security, webhooks, SIEM destinations, branding and SMTP. It authenticates over OAuth in your browser, and an assistant only ever gets the access the signed-in account already has.
Point an agent at a Keycloak admin API and it can edit realms. It cannot provision a cluster, verify a custom domain, change a WAF rule, or ship events to your SIEM. Those surfaces are the managed platform, and they are exactly where an assistant saves the most time.
Provision, resize, upgrade and inspect the managed Keycloak clusters themselves.
list_clusters, get_cluster, create_cluster, update_cluster, list_cluster_upgrades, get_cluster_upgrade_path, get_cluster_insights
Read and change the protection in front of the cluster, not just the settings inside it.
get_cluster_security, update_cluster_security
Add a domain, get back the DNS records to create, then trigger verification and manage routes.
list_domains, create_domain, verify_domain, list_domain_routes, create_domain_route
Subscribe to platform events, inspect what is subscribed, and fire a test delivery.
list_webhook_subscriptions, list_webhook_event_types, create_webhook_subscription, test_webhook_subscription
Wire cluster events into Splunk, Datadog, Sentinel or a webhook sink, and test the pipe.
list_siem_destinations, create_siem_destination, update_siem_destination, test_siem_destination
Query authentication and admin events, read logs, and export realms or event history.
query_events, get_logs, create_export, export_cluster_events, create_realm_export
The Keycloak layer: realms, users, roles, groups and membership.
list_realms, create_realm, list_realm_users, create_realm_user, assign_realm_user_role, add_realm_user_to_group
OIDC and SAML clients, their roles and sessions, plus the identity providers behind sign-in.
list_applications, create_application, rotate_application_secret, list_identity_providers, create_identity_provider, discover_oidc
Login and email branding, theme upload and per-client theme assignment.
list_themes, set_theme_assignment, upsert_login_branding, upsert_email_branding
Install and upgrade Keycloak extensions, and configure or test outbound mail.
list_extensions, install_extension, upgrade_extension, get_smtp, upsert_smtp, test_smtp
“Which realms across my clusters still have self-registration enabled?”
“Which of my clusters are behind on their Keycloak version, and what is the upgrade path for the oldest one?”
“Pull the last 200 failed logins for realm acme and group them by IP.”
“Which identity providers are configured on the checkout realm, and is the Google one still enabled?”
“Show me the admin events for realm acme this week. Did anyone change the login settings?”
“Create a staging cluster in the EU, add a realm called checkout, and wire up Microsoft Entra ID sign-in.”
“Add login.acme.com as a custom domain and tell me exactly which DNS records to create.”
“Rotate the client secret for the checkout application and show me the new one.”
Read questions run against your live platform. Anything that changes state is bounded by your own permissions, and deletions need an explicit confirmation.
The scary part of handing an assistant your identity provider is not that it does nothing useful. It is that it does something very useful to the wrong realm. So there is no second permission system to reason about.
Tools are registered against the scopes of the credential you signed in with. If your account cannot rotate a client secret, neither can your assistant. Nothing to configure, nothing that can drift out of step with your real access.
Deleting a realm, an application or an identity provider requires an explicit confirm=true. Without it the tool declines and says why, so an ambiguous instruction cannot cascade into a deletion.
Sign-in runs through your Skycloak account over OAuth. There is no long-lived key sitting in a config file on a laptop, and revoking access is the same action you already use.
claude mcp add --transport http skycloak https://mcp.skycloak.io. For a client that takes JSON configuration, add an entry with "type": "http" and "url": "https://mcp.skycloak.io". On first use the server returns a 401 carrying its OAuth metadata and your client opens a browser for you to sign in. See the MCP documentation for the full setup.confirm=true, so a vague instruction cannot cascade into a deletion.Connect in one command, or start a free trial and spin up a cluster to point it at. Unlimited users on every plan, real upstream Keycloak, no lock-in.