What can you do with this server?

The Advanced Keycloak MCP Server provides comprehensive tools for managing Keycloak administration tasks through LLM interfaces. * User Management: Create, delete, and list users with detailed attributes (username, email, names), reset passwords, enable/disable accounts, and verify emails * Realm Administration: Retrieve and manage all available realms in the Keycloak instance * Role Management: List client roles, add or remove roles for users within a realm * Credential Management: Set temporary credentials and manage password resets with configurable options

Which integrations are available for this server?

Provides comprehensive tools for Keycloak administration, enabling management of users, realms, roles, and other Keycloak resources through its API.

How do I use Advanced Keycloak MCP server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Advanced Keycloak MCP server create a new user named jane.smith with email jane@company.com in the marketing realm" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Advanced Keycloak MCP server

by Octodet

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Octodet Keycloak MCP Server

npm version License: MIT

A powerful Model Context Protocol server for Keycloak administration, providing a comprehensive set of tools to manage users, realms, roles, and other Keycloak resources through LLM interfaces.

Features

User Management: Create, delete, and list users across realms
Realm Administration: Comprehensive realm management capabilities
Secure Integration: Authentication with admin credentials
Easy Configuration: Simple setup with environment variables
LLM Integration: Seamless use with Claude, ChatGPT, and other MCP-compatible AI assistants

Related MCP server: mcp-keycloak

Installation

Via NPM (Recommended)

The server is available as an NPM package:

# Direct usage with npx
npx -y @octodet/keycloak-mcp

# Or global installation
npm install -g @octodet/keycloak-mcp

Configuration

Environment Variables

Variable	Description	Default
KEYCLOAK_URL	Keycloak server URL	http://localhost:8080
KEYCLOAK_ADMIN	Admin username	admin
KEYCLOAK_ADMIN_PASSWORD	Admin password	admin
KEYCLOAK_REALM	Default realm	master

MCP Client Configuration

VS Code

Add this to your settings.json:

{
  "mcp.servers": {
    "keycloak": {
      "command": "npx",
      "args": ["-y", "@octodet/keycloak-mcp"],
      "env": {
        "KEYCLOAK_URL": "http://localhost:8080",
        "KEYCLOAK_ADMIN": "admin",
        "KEYCLOAK_ADMIN_PASSWORD": "admin"
      }
    }
  }
}

Claude Desktop

Configure in your Claude Desktop configuration file:

{
  "mcpServers": {
    "keycloak": {
      "command": "npx",
      "args": ["-y", "@octodet/keycloak-mcp"],
      "env": {
        "KEYCLOAK_URL": "http://localhost:8080",
        "KEYCLOAK_ADMIN": "admin",
        "KEYCLOAK_ADMIN_PASSWORD": "admin"
      }
    }
  }
}

For Local Development

{
  "mcpServers": {
    "keycloak": {
      "command": "node",
      "args": ["path/to/build/index.js"],
      "env": {
        "KEYCLOAK_URL": "http://localhost:8080",
        "KEYCLOAK_ADMIN": "admin",
        "KEYCLOAK_ADMIN_PASSWORD": "admin"
      }
    }
  }
}

Available Tools

The server provides a comprehensive set of MCP tools for Keycloak administration. Each tool is designed to perform specific administrative tasks across realms, users, and roles.

📋 Tool Overview

Tool	Category	Description
`create-user`	User Management	Create a new user in a specified realm
`delete-user`	User Management	Delete an existing user from a realm
`list-users`	User Management	List all users in a specified realm
`list-realms`	Realm Management	List all available realms
`list-roles`	Role Management	List all roles for a specific client
`update-user-roles`	Role Management	Add or remove client roles for a user

👥 User Management

`create-user`

Creates a new user in a specified realm with comprehensive user attributes and optional credentials.

Required Parameters:

realm (string): Target realm name
username (string): Unique username for the new user
email (string): Valid email address
firstName (string): User's first name
lastName (string): User's last name

Optional Parameters:

enabled (boolean): Enable/disable user account (default: true)
emailVerified (boolean): Mark email as verified
credentials (array): Array of credential objects for setting passwords

Credential Object Structure:

type (string): Credential type (e.g., "password")
value (string): The credential value
temporary (boolean): Whether password must be changed on first login

Example Usage:

{
  "realm": "my-app-realm",
  "username": "john.doe",
  "email": "john.doe@company.com",
  "firstName": "John",
  "lastName": "Doe",
  "enabled": true,
  "emailVerified": true,
  "credentials": [
    {
      "type": "password",
      "value": "TempPassword123!",
      "temporary": true
    }
  ]
}

Response: Returns the created user ID and confirmation message.

`delete-user`

Permanently removes a user from the specified realm. This action cannot be undone.

Required Parameters:

realm (string): Target realm name
userId (string): Unique identifier of the user to delete

Example Usage:

{
  "realm": "my-app-realm",
  "userId": "8f5c21e3-7c9d-4b5a-9f3e-8d4f6a2e7b1c"
}

Response: Confirmation message of successful deletion.

⚠️ Warning: This operation is irreversible. Ensure you have the correct user ID before execution.

`list-users`

Retrieves a list of all users in the specified realm with their basic information.

Required Parameters:

realm (string): Target realm name

Example Usage:

{
  "realm": "my-app-realm"
}

Response: Returns a formatted list showing usernames and user IDs for all users in the realm.

🏛️ Realm Management

`list-realms`

Retrieves all available realms in the Keycloak instance.

Parameters: None required

Example Usage:

{}

Response: Returns a list of all realm names available in the Keycloak installation.

Use Cases:

Discovering available realms
Validating realm names before other operations
Administrative overview of the Keycloak setup

🔐 Role Management

`list-roles`

Lists all roles defined for a specific client within a realm. Useful for understanding available permissions and roles before assignment.

Required Parameters:

realm (string): Target realm name
clientId (string): Client ID or UUID of the target client

Example Usage:

{
  "realm": "my-app-realm",
  "clientId": "my-application"
}

Alternative with Client UUID:

{
  "realm": "my-app-realm",
  "clientId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

Response: Returns a formatted list of all role names available for the specified client.

💡 Tip: You can use either the client's human-readable ID or its UUID identifier.

`update-user-roles`

Manages client role assignments for a user. Allows both adding and removing roles in a single operation.

Required Parameters:

realm (string): Target realm name
userId (string): User's unique identifier
clientId (string): Client ID or UUID

Optional Parameters:

rolesToAdd (array): List of role names to assign to the user
rolesToRemove (array): List of role names to remove from the user

Example Usage - Adding Roles:

{
  "realm": "my-app-realm",
  "userId": "8f5c21e3-7c9d-4b5a-9f3e-8d4f6a2e7b1c",
  "clientId": "my-application",
  "rolesToAdd": ["admin", "user-manager", "report-viewer"]
}

Example Usage - Removing Roles:

{
  "realm": "my-app-realm",
  "userId": "8f5c21e3-7c9d-4b5a-9f3e-8d4f6a2e7b1c",
  "clientId": "my-application",
  "rolesToRemove": ["temporary-access", "beta-tester"]
}

Example Usage - Combined Operation:

{
  "realm": "my-app-realm",
  "userId": "8f5c21e3-7c9d-4b5a-9f3e-8d4f6a2e7b1c",
  "clientId": "my-application",
  "rolesToAdd": ["senior-user"],
  "rolesToRemove": ["junior-user", "trainee"]
}

Response: Detailed summary of roles added, removed, and any errors encountered.

🔍 Notes:

At least one of rolesToAdd or rolesToRemove must be provided
Non-existent roles are skipped with warnings
The operation is atomic per role list (all or none for each operation type)

🚀 Usage Tips

User IDs vs Usernames: Most operations require user IDs (UUIDs), not usernames. Use list-users to find the correct user ID.
Client Identification: The clientId parameter accepts both human-readable client IDs and UUID identifiers.
Realm Validation: Always verify realm names using list-realms before performing operations.
Role Discovery: Use list-roles to discover available roles before attempting role assignments.
Error Handling: All tools provide detailed error messages for troubleshooting authentication, permission, or parameter issues.

Development

Setting Up Your Development Environment

# Clone the repository
git clone <repository-url>

# Install dependencies
npm install

# Start the development server with watch mode
npm run watch

Adding New Tools

To add a new tool to the server:

Define the tool schema in src/index.ts using Zod
Add the tool definition to the ListToolsRequestSchema handler
Implement the tool handler in the CallToolRequestSchema switch statement
Update this README to document the new tool

Testing

Using MCP Inspector

The MCP Inspector is a great tool for testing your MCP server:

npx -y @modelcontextprotocol/inspector npx -y @octodet/keycloak-mcp

Integration Testing

For testing with a local Keycloak instance:

# Start Keycloak with Docker
docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:latest start-dev

# In another terminal, run the MCP server
npm run build
node build/index.js

Deployment

NPM Package

This project is published to NPM under @octodet/keycloak-mcp.

Automated Deployment

This project uses GitHub Actions for CI/CD to automatically test and publish to NPM when a new release is created.

Prerequisites

Node.js 18 or higher
Running Keycloak instance

License

This project is licensed under the MIT License - see the LICENSE file for details.

Author

Octodet - Building intelligent tools for developers

Available Tools

7 tools

create-userB

Create a new user in a specific realm

ParametersJSON Schema

Name	Required	Description
`realm`	Yes	Realm name
`username`	Yes	Username for the new user
`email`	Yes	Email address for the new user
`firstName`	Yes	First name of the user
`lastName`	Yes	Last name of the user
`enabled`	No	Whether the user is enabled
`emailVerified`	No	Whether the email is verified
`credentials`	No	User credentials

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose behavioral traits such as permissions required, idempotency, error handling, or whether the operation is reversible. The description only restates the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Front-loaded with the key action and resource.

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?

Given the moderate complexity (8 parameters) and lack of output schema or annotations, the description is too minimal. It does not explain what happens after creation (e.g., return value, error scenarios, or side effects).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it merely says 'in a specific realm', which is already captured by the 'realm' parameter.

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 the verb 'Create' and the resource 'new user in a specific realm'. It distinguishes well from sibling tools like delete-user, list-users, etc.

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?

No guidance on when to use this tool versus alternatives. For example, no mention of prerequisites or scenarios where update-user or reset-user-password would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete-userB

Delete a user from a specific realm

ParametersJSON Schema

Name	Required	Description	Default
`realm`	Yes	Realm name
`userId`	Yes	User ID to delete

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description lacks details on behavior such as irreversibility, error handling (e.g., if user not found), or side effects on related data (e.g., sessions). Annotations are absent, so the description carries the full burden, which it does not meet.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, efficient sentence that conveys the core purpose without superfluous words.

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?

Given the tool's destructive nature and absence of output schema or annotations, the description is insufficient. It omits critical context such as success/failure behavior, error conditions, and whether the action rolls back related data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with 'realm' and 'userId' already clearly described. The description adds no extra semantic context beyond what the schema provides.

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 the action (delete), the resource (user), and the scope (from a specific realm), distinguishing it from sibling tools like create-user and list-users.

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?

No guidance is provided on when to use this tool, prerequisites, or alternatives. For instance, it does not indicate that the user must exist or that permissions are required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-realmsB

List all available realms

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should provide behavioral details. It only mentions listing all realms but lacks info on read-only behavior, pagination, authentication, or response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single sentence front-loading the purpose. No wasted words.

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?

For a simple list tool with no parameters or output schema, the description is minimally adequate but lacks details on return structure or any potential filters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters and schema description coverage is 100%, so the description adds no param semantics. Baseline of 3 is appropriate for a no-parameter tool.

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 'List all available realms' clearly states the action (list) and resource (realms), with 'available' implying no filtering. It is distinct from sibling tools like create-user or list-users.

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?

No guidance on when to use this tool or when alternatives might be better. The description gives no context for exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-rolesA

List all roles of a specific client in a specific realm

ParametersJSON Schema

Name	Required	Description	Default
`realm`	Yes	Realm name
`clientId`	Yes	Client ID

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only says 'list' without detailing behavioral traits like pagination, read-only nature, or result format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence that effectively communicates the tool's purpose without unnecessary verbosity.

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?

Adequate for a simple listing tool, but lacks explanation of return values or any output structure; could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions; the description adds no extra meaning beyond what the schema provides.

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 the tool lists roles for a specific client in a realm, distinguishing it from siblings like list-users or list-realms.

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?

No explicit guidance on when to use this tool versus alternatives; usage is implied but not clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-usersB

List users in a specific realm

ParametersJSON Schema

Name	Required	Description	Default
`realm`	Yes	Realm name

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose behavioral traits such as whether the operation is read-only, pagination, or authentication requirements. Minimal transparency beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with purpose, no unnecessary words. Highly concise and well-structured.

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?

For a simple one-parameter list tool with no output schema and no annotations, the description is minimally complete. However, it lacks context on return format, pagination, or permissions, which could be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds little beyond the schema's parameter description ('Realm name'). Baseline score of 3 is appropriate as schema already provides adequate documentation.

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 the verb 'List' and the resource 'users' with a specific scope 'in a specific realm'. It distinguishes from siblings like list-realms and other user tools.

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?

No guidance on when to use this tool versus alternatives like list-realms or other user tools. Lack of context for prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reset-user-passwordB

Reset or set a new password for a user in a specific realm

ParametersJSON Schema

Name	Required	Description
`realm`	Yes	Realm name
`userId`	Yes	User ID
`password`	Yes	New password
`temporary`	No	Whether the password is temporary

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action without revealing traits like required permissions, side effects (e.g., email notification), or behavior for temporary passwords.

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 a single, clear sentence with no wasted words. It is appropriately front-loaded, but could be slightly more comprehensive without losing conciseness.

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?

Given the absence of annotations and output schema, the description is too minimal for a mutation tool with 4 parameters. It does not explain return values, error conditions, or how the 'temporary' parameter affects behavior, leaving gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the description adds no additional meaning beyond what is already in the schema. It does not clarify constraints like password complexity or implications of the 'temporary' flag.

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 the action (reset/set password) and the resource (user in a specific realm). It is distinct from sibling tools like create-user or update-user-roles, which perform different operations.

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 implies when to use the tool (to change a password) but does not explicitly state when not to use it or mention alternatives. It lacks guidance on prerequisites or conditions, but the purpose is reasonably clear from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update-user-rolesA

Add and/or remove client roles for a user in a specific realm and client

ParametersJSON Schema

Name	Required	Description
`realm`	Yes	Realm name
`userId`	Yes	User ID
`clientId`	Yes	Client ID
`rolesToAdd`	No	Roles to add
`rolesToRemove`	No	Roles to remove

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description explains the core action (add/remove roles). However, it omits side effects, permissions, idempotency, or error behavior, which are important for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action verb, no redundancy. Efficient and to the point.

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 simplicity, the description lacks completeness: no output schema, no explanation of response format, error cases, or prerequisites. For a modification tool, more context is needed for confident use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions; the tool description adds no extra semantic value beyond restating the action, so baseline 3 is appropriate.

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?

Description clearly states the tool adds/removes client roles for a user in a realm and client, distinguishing it from sibling tools that handle user CRUD, listing, or password reset.

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?

Usage is implied by the description, but no explicit guidance on when to use vs. alternatives like list-roles or when to avoid; lacks when-not or prerequisite conditions.

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. Dates show when Glama detected each change.

7 tool updatesAug 15, 2025
- First observedcreate-user
- First observeddelete-user
- First observedlist-realms
- First observedlist-roles
- First observedlist-users
- First observedreset-user-password
- First observedupdate-user-roles

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct operation (create, delete, list, reset password, update roles) on specific resources (user, realm, role). There is no overlap or ambiguity between tool purposes.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with hyphens (e.g., create-user, list-realms, reset-user-password). No mixing of styles or inconsistent patterns.

Tool Count5/5

With 7 tools covering user creation, deletion, listing, password reset, role management, and realm/role listing, the count is well-scoped for a focused Keycloak management server.

Completeness4/5

The set covers essential user lifecycle operations (create, delete, list, password reset, role updates). Missing a get-user tool and realm role management, but core workflows are supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-docs B
io.fusionauth
FusionAuth Documentation MCP server
Documentation Access Developer Tools Security
22
Security Mcp A
io.github.varvararatta
MCP server for Security
Security Penetration Testing
2
auth-token-mcp-service
ai.getvda
Auth Token MCP Service
1
Product Management Mcp D
io.github.varvararatta
MCP server for Product Management
Product Management Project Management
2

Related MCP Servers

keycloak-mcp
Security Developer Tools
shigechika
A
license
A
quality
A
maintenance
An MCP server for Keycloak Admin REST API, enabling user, group, event, and security management through service account authentication.
Updated 4 days ago (2026-09-02 19:08 UTC)
30
MIT
mcp-keycloak
Security Developer Tools
xuancanhit99
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that provides a natural language interface for managing Keycloak identity and access management through its REST API.
Updated 7 months ago (2026-02-13 04:42 UTC)
MIT
keycloak-mcp
Security Developer Tools
Faust-Systems
A
license
A
quality
C
maintenance
An MCP server that lets an AI assistant inspect and modify Keycloak realm, client, and protocol-mapper configuration across multiple Keycloak hosts.
Updated 2 months ago (2026-07-09 14:54 UTC)
7
48
MIT
keycloak-mcp-server
Security Developer Tools
hakkisagdic
A
license
Not graded
quality
B
maintenance
Enables administration of Keycloak identity and access management through MCP, allowing management of realms, clients, users, roles, groups, identity providers, and sessions from any MCP client.
Updated 2 months ago (2026-07-21 00:31 UTC)
37
Apache 2.0

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Octodet/keycloak-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server