Zitadel MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | DEBUG, INFO, WARN, ERROR (default: INFO) | INFO |
| ZITADEL_ISSUER | Yes | Zitadel instance URL | |
| ZITADEL_ORG_ID | Yes | Organization ID | |
| ZITADEL_PROJECT_ID | No | Default project ID for role operations | |
| PORTAL_DATABASE_URL | No | Postgres connection string (enables portal tools) | |
| ZITADEL_SERVICE_ACCOUNT_KEY_ID | Yes | Key ID from the JSON key file | |
| ZITADEL_SERVICE_ACCOUNT_USER_ID | Yes | Service account user ID | |
| ZITADEL_SERVICE_ACCOUNT_PRIVATE_KEY | Yes | Base64-encoded RSA private key (the key field from the downloaded JSON) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| zitadel_list_usersB | List or search users in the Zitadel instance. Returns user details including name, email, status, and login names. |
| zitadel_get_userA | Get detailed information about a specific user by their user ID. |
| zitadel_create_userA | Create a new human user in Zitadel. An invitation email will be sent automatically so the user can set their password. Optionally supply your own userId for idempotent retries (a re-create then conflicts cleanly). |
| zitadel_deactivate_userA | Deactivate a user account. The user will no longer be able to log in. Requires confirm: true. |
| zitadel_reactivate_userB | Reactivate a previously deactivated user account. |
| zitadel_lock_userA | Lock a user account. The user will not be able to log in until unlocked. Requires confirm: true. |
| zitadel_unlock_userA | Unlock a previously locked user account. |
| zitadel_delete_userA | Permanently delete a user. This action cannot be undone. Requires confirm: true. Consider using zitadel_deactivate_user instead (reversible). |
| zitadel_list_projectsB | List all projects in the Zitadel organization. |
| zitadel_get_projectB | Get details of a specific project by its ID. |
| zitadel_create_projectB | Create a new project in Zitadel. Projects contain applications, roles, and grants. |
| zitadel_list_appsB | List all applications in a Zitadel project. |
| zitadel_get_appA | Get details of a specific application including its Client ID and OIDC configuration. |
| zitadel_create_oidc_appA | Create a new OIDC application in a Zitadel project. Returns the Client ID (and Client Secret for confidential clients). Configure redirect URIs, response types, and grant types. |
| zitadel_update_appB | Update an OIDC application's configuration (redirect URIs, auth method, grant types, etc.). |
| zitadel_list_project_rolesB | List all roles defined in a Zitadel project (e.g., "admin", "standard"). |
| zitadel_create_project_roleB | Create a new role in a Zitadel project. For the standardized RBAC model use the keys "admin" or "standard" (see zitadel_provision_user). |
| zitadel_list_user_grantsB | List role grants (authorizations) for a specific user, showing which project roles they have been assigned. |
| zitadel_create_user_grantA | Assign project roles to a user via the v2 AuthorizationService. Validates that the roles exist in the project before granting. For the standardized two-role model prefer "admin"/"standard"; other keys are allowed but flagged as drift. |
| zitadel_remove_user_grantA | Remove a role grant (authorization) from a user by grant ID. Requires confirm: true. |
| zitadel_create_service_userA | Create a new service account (machine user) for API access. Service accounts authenticate via JWT keys, not passwords. |
| zitadel_create_service_user_keyA | Generate a new key pair for a service account. The private key is returned ONLY at creation time — save it immediately. |
| zitadel_list_service_user_keysA | List existing keys for a service account. Shows key metadata only (not private keys). |
| zitadel_get_orgA | Get details of the current organization (based on the configured ZITADEL_ORG_ID). |
| zitadel_list_org_manager_rolesA | List the org-level manager (administrator) role keys this Zitadel org supports (e.g. ORG_OWNER, ORG_USER_MANAGER, ORG_USER_PERMISSION_EDITOR). Use to confirm the exact keys before granting. |
| zitadel_list_org_managersA | List users who hold org-level manager (administrator) grants, with their manager roles. Optionally filter to a single role key (e.g. ORG_OWNER) to see who holds it. |
| zitadel_grant_org_managerA | Grant org-level manager (administrator) role(s) to a user. For the no-super-admin pattern, grant ORG_USER_MANAGER to every Admin so they can manage any user. Idempotent: merges with any existing manager roles. Defaults to ["ORG_USER_MANAGER"]. |
| zitadel_revoke_org_managerA | Revoke org-level manager role(s) from a user. Omit roles to remove the entire manager membership. Guards against removing the last ORG_OWNER. Requires confirm: true. |
| zitadel_provision_userA | Atomically provision a user for the core SSO apps (the app-portal cascade-up). Creates the human user (idempotent by email or supplied userId), assigns the Admin|Standard project role via the v2 AuthorizationService, and — for Admins — grants ORG_USER_MANAGER so they can manage any user (no-super-admin pattern). Returns { zitadelUserId, role, authorizationId }. Safe to re-run. |
| zitadel_offboard_userA | Offboard a user: remove their Admin|Standard project role assignment, revoke any org-manager grant, and deactivate the account. Guards: cannot remove the last Admin, cannot self-demote (pass actingUserId), cannot remove the last ORG_OWNER. Requires confirm: true. |
| zitadel_get_login_policyA | Get the login policy of the current organization (ZITADEL_ORG_ID), including whether self-registration (allowRegister) is on and whether the policy is inherited from the instance default or a custom org policy. |
| zitadel_get_hosted_login_translationA | Read the Login V2 (new "hosted login" / TypeScript login) text overrides for a locale, via the Settings v2 API. This is the ONLY text-customization that affects the new login — the legacy Management "Custom Login Texts" do not. By default returns the merged, effective file (your overrides on top of the shipped defaults); pass onlyOverrides=true to see just what is stored at this level. Defaults to the configured org; pass level:"instance" for the whole instance. Override keys mirror apps/login/locales/.json in zitadel/zitadel (e.g. "password.errors.couldNotCreateSessionForUser"). |
| zitadel_set_hosted_login_translationA | Override texts of the Login V2 (new "hosted login" / TypeScript login) for a locale, via the Settings v2 API — the correct lever for the new login (the legacy Management "Custom Login Texts" are ignored by it). Pass |
| zitadel_get_auth_configA | Get the environment variables needed for a new application's .env.local file. Fetches the app details and formats them as ready-to-paste configuration. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 34 tools
Tools are mostly distinct: user lifecycle, grants, org managers, projects, apps, and translations each have clear boundaries. The only mild overlap is between composite helpers (provision_user, offboard_user) and their constituent low-level operations, but descriptions make the intended use clear.
All tools use the zitadel_ prefix with snake_case verb_noun naming (e.g. zitadel_list_users, zitadel_create_user_grant, zitadel_grant_org_manager). Conventions are consistent across the entire set.
34 tools is above the 25-tool threshold for 'too many' in the rubric; while Zitadel is broad, the surface feels heavy and includes several composite wrappers alongside granular operations.
User lifecycle is complete (create, list, get, deactivate, reactivate, lock, unlock, delete), and grants/managers are well covered. However, projects and apps lack update/delete operations, login policy is read-only, and service-user keys have no delete/revoke, leaving notable gaps.