Skip to main content
Glama

User

gitlab_user
Destructive

Manage GitLab user accounts: CRUD, block/unblock, approve; manage SSH/GPG keys, emails, personal access & impersonation tokens, user status, todos, events, notification settings, namespaces, avatars. Supports admin and current user.

Instructions

Example: {"action":"activate","params":{...}} For the params schema of any action, read the MCP resource gitlab://schema/meta/gitlab_user/.

User management for GitLab: full user account CRUD plus SSH/GPG keys, emails, personal access tokens (PATs), impersonation tokens, user status, todos, contribution events, notification settings, namespaces, and avatars. This is the canonical user management tool — covers the entire /users API surface. Delete / block / ban / reject actions are destructive. When to use: any user-management workflow — user CRUD (create / modify / delete / block / unblock / ban / unban / approve / reject / activate / deactivate), SSH/GPG key management, personal access token (PAT) management, impersonation tokens (admin), todos, contribution events, notification settings, namespaces, avatars, current-user status. NOT for: deploy tokens or project/group access tokens (use gitlab_access), instance-wide admin operations (use gitlab_admin), project/group memberships (use gitlab_project / gitlab_group).

Param conventions: * = required. User IDs are integers. List actions accept page, per_page. Actions ending in _for_user take the same params as the base action plus user_id*. Plain ssh_keys / gpg_keys / emails (no suffix) operate on the current authenticated user with no params.

Current user:

  • current / me: returns authenticated user info.

  • current_user_status: returns emoji, message, availability.

  • set_status: emoji, message, availability (not_set/busy), clear_status_after (30_minutes/3_hours/8_hours/1_day/3_days/7_days/30_days)

User CRUD (admin):

  • list: search, username, active, blocked, external, order_by, sort

  • get: user_id*

  • get_status: user_id*

  • create: email*, name*, username*, password, reset_password, force_random_password, skip_confirmation, admin, external, bio, location, job_title, organization, projects_limit, note

  • modify: user_id*, email, name, username, bio, location, job_title, organization, projects_limit, admin, external, note

  • delete: user_id*

  • associations_count: user_id*

User state (admin):

  • block / unblock / ban / unban / activate / deactivate / approve / reject / disable_two_factor: user_id*

SSH keys:

  • get_ssh_key: key_id*

  • get_ssh_key_for_user: user_id*, key_id*

  • add_ssh_key: title*, key*, expires_at, usage_type (auth/signing)

  • delete_ssh_key: key_id*

  • delete_ssh_key_for_user: user_id*, key_id*

GPG keys:

  • get_gpg_key: key_id*

  • get_gpg_key_for_user: user_id*, key_id*

  • add_gpg_key: key* (armored GPG public key)

  • delete_gpg_key: key_id*

  • delete_gpg_key_for_user: user_id*, key_id*

Emails:

  • get_email: email_id*

  • add_email: email*, skip_confirmation

  • add_email_for_user: user_id*, email*, skip_confirmation

  • delete_email: email_id*

  • delete_email_for_user: user_id*, email_id*

Tokens:

  • list_impersonation_tokens: user_id*, state (active/inactive)

  • get_impersonation_token: user_id*, token_id*

  • create_impersonation_token: user_id*, name*, scopes*, expires_at

  • revoke_impersonation_token: user_id*, token_id*

  • create_personal_access_token: user_id*, name*, scopes*, description, expires_at

  • create_current_user_pat: name*, scopes*, description, expires_at

Activity and events:

  • activities: (admin) from (YYYY-MM-DD)

  • memberships: user_id*, type (Project/Namespace)

  • contribution_events: user_id*, action, target_type, before, after, sort

  • event_list_project: project_id*, action, target_type, before, after, sort

  • event_list_contributions: action, target_type, before, after, sort

Todos:

  • todo_list: action, author_id, project_id, group_id, state (pending/done), type

  • todo_mark_done: id*

  • todo_mark_all_done: no params

Notifications:

  • notification_global_get / notification_global_update: no ID needed. Update params: level, notification_email, event booleans

  • notification_project_get / notification_project_update: project_id*. Update params: level, event booleans

  • notification_group_get / notification_group_update: group_id*. Update params: level, event booleans

Keys and namespaces:

  • key_get_with_user: key_id*. Returns SSH key with user info.

  • key_get_by_fingerprint: fingerprint*

  • namespace_list: search, owned_only

  • namespace_get: namespace_id*

  • namespace_exists: namespace*, parent_id

  • namespace_search: search*

  • avatar_get: email*, size

Misc:

  • create_runner: runner_type*, group_id, project_id, description, paused, locked, run_untagged, tag_list, access_level, maximum_timeout, maintenance_note

  • delete_identity: user_id*, provider*

See also: gitlab_access (deploy/access tokens), gitlab_admin (instance administration)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform. Pick exactly one of the values in `enum`. Each action expects its own `params` object — see the tool description for the per-action parameter list.
paramsNoAction-specific parameters as a JSON object. Required and optional fields differ per action; consult this tool's description for the chosen action. Send only the fields documented for that action — unknown keys are rejected with a validation error (only reserved meta keys like `confirm` are stripped before validation). For the JSON Schema of a specific action's `params`, read the MCP resource `gitlab://schema/meta/{tool}/{action}` (replace placeholders with the tool name and the chosen action).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
next_stepsNoOptional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
paginationNoPresent on list actions. Use `has_more` and `next_page` to paginate through results.
Behavior5/5

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

The annotations already set destructiveHint=true and openWorldHint=true. The description adds valuable behavioral context beyond the annotations: it explicitly labels actions as 'Delete / block / ban / reject actions are destructive,' explains param conventions like 'Actions ending in _for_user take the same params as the base action plus user_id', and describes the effect of each action category (e.g., 'set_status: emoji, message, availability (not_set/busy), clear_status_after'). No contradiction with annotations.

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 very long (over 300 words) but well-structured into sections (Current user, User CRUD, SSH keys, etc.) and uses bullet-style formatting. Every section adds necessary detail for the many actions. While a bit verbose, the structure makes it scannable. Could be slightly more concise, but it earns its length given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (dozens of actions), the simple input schema (2 params), and the presence of an output schema, the description is exceptionally complete. It covers all action categories, lists parameters per action, explains edge cases (e.g., 'current user' operations), and provides examples ('Example: {"action":"activate","params":{...}}'). The agent has all necessary context to select and invoke any action correctly.

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

Parameters5/5

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

The input schema defines only two parameters (action with enum, params as object). The description adds rich semantic meaning for the params object by listing per-action required and optional parameters, such as 'create: email*, name*, username*, password, reset_password, ...' and 'list: search, username, active, blocked, external, order_by, sort'. It also explains conventions like 'List actions accept page, per_page' and 'Plain ssh_keys / gpg_keys / emails (no suffix) operate on the current authenticated user with no params.' This greatly exceeds the baseline of 3 given 100% schema description coverage.

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 is for 'User management for GitLab: full user account CRUD plus SSH/GPG keys, emails...' and explicitly distinguishes from sibling tools by stating 'NOT for: deploy tokens or project/group access tokens (use gitlab_access), instance-wide admin operations (use gitlab_admin), project/group memberships (use gitlab_project / gitlab_group)'. It leaves no ambiguity about what it does and how it differs from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'When to use: any user-management workflow — user CRUD, SSH/GPG key management, personal access token (PAT) management, impersonation tokens (admin), todos, contribution events, notification settings, namespaces, avatars, current-user status.' It also gives clear exclusions with alternative tool names, and provides param conventions (e.g., '*' for required, user IDs are integers).

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

Install Server

Other Tools

Latest Blog Posts

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/jmrplens/gitlab-mcp-server'

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