Skip to main content
Glama

Access

gitlab_access
Destructive

Provision, audit, and rotate GitLab access credentials: access tokens, deploy tokens, deploy keys, access requests, and invitations. Rotate tokens to renew without breaking CI. Revoke/delete are irreversible.

Instructions

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

Manage GitLab access credentials: access tokens (project/group/personal), deploy tokens, deploy keys, access requests, and invitations. Revoke/delete actions are destructive and irreversible. When to use: provision and audit who/what can access a project or group; rotate (not revoke+create) to roll a token without invalidating CI configurations. NOT for: SSH/GPG keys or impersonation tokens (use gitlab_user), PAT creation (use gitlab_user create_personal_access_token / create_current_user_pat — gitlab_access exposes token_personal_* for list/get/rotate/revoke only), instance admin operations (use gitlab_admin), project membership/permissions (use gitlab_project member_*), 2FA/MFA flows.

Returns:

  • token_list / deploy_token_list / deploy_key_list_* / request_list_* / invite_list_*: arrays with pagination.

  • token_get / tokencreate / tokenrotate / deploy_token_get / deploy_token_create_* / deploy_key_get / deploy_key_add / deploy_key_update / deploy_key_enable / approve_* / request_*: token / key / request / invitation object. Create / rotate include the cleartext token only ONCE — store it securely; subsequent reads return only the metadata.

  • token_revoke / deploy_token_delete / deploy_key_delete / deny_* : {success, message}. Errors: 401/403 (hint: requires Maintainer+ to manage project tokens, Owner for group, admin for instance / deploy_token_list_all / deploy_key_list_all / deploy_key_add_instance), 404 (hint: token_id and deploy_key_id are scoped to the project/group), 400 (hint: scopes must be a subset of {api, read_api, read_repository, write_repository, read_registry, write_registry}; expires_at must be a future ISO date).

Param conventions: * = required. List actions accept page, per_page. Token actions scope to project_id* or group_id*. Deploy token/key delete and token revoke are irreversible.

Access tokens (token_*) — project, group, and personal scopes. Rotate generates a new token and invalidates the old one:

  • token_project_list / token_group_list: project_id* or group_id*

  • token_project_get / token_group_get: project_id* or group_id*, token_id*

  • token_project_create / token_group_create: project_id* or group_id*, name*, scopes*, expires_at, access_level

  • token_project_rotate / token_group_rotate: project_id* or group_id*, token_id*, expires_at

  • token_project_rotate_self / token_group_rotate_self: project_id* or group_id*, expires_at

  • token_project_revoke / token_group_revoke: project_id* or group_id*, token_id*

  • token_personal_list: user_id

  • token_personal_get: token_id*

  • token_personal_rotate: token_id*, expires_at

  • token_personal_rotate_self: expires_at

  • token_personal_revoke: token_id*

  • token_personal_revoke_self: (no params)

Deploy tokens (deploy_token_*) — scoped to project or group, used for CI/CD registry access:

  • deploy_token_list_all: (admin only)

  • deploy_token_list_project / deploy_token_list_group: project_id* or group_id*

  • deploy_token_get_project / deploy_token_get_group: project_id* or group_id*, deploy_token_id*

  • deploy_token_create_project / deploy_token_create_group: project_id* or group_id*, name*, scopes*, expires_at

  • deploy_token_delete_project / deploy_token_delete_group: project_id* or group_id*, deploy_token_id*

Deploy keys (deploy_key_*) — SSH keys for read/write repo access without a user account:

  • deploy_key_list_project / deploy_key_list_user_project: project_id*

  • deploy_key_list_all: (admin only)

  • deploy_key_get: project_id*, deploy_key_id*

  • deploy_key_add: project_id*, title*, key*, can_push

  • deploy_key_update: project_id*, deploy_key_id*, title, can_push

  • deploy_key_delete: project_id*, deploy_key_id*

  • deploy_key_enable: project_id*, deploy_key_id*

  • deploy_key_add_instance: title*, key*

Access requests (request_, approve_, deny_*):

  • request_list_project / request_list_group: project_id* or group_id*

  • request_project / request_group: project_id* or group_id*

  • approve_project / approve_group: project_id* or group_id*, user_id*, access_level

  • deny_project / deny_group: project_id* or group_id*, user_id*

Invitations (invite_*):

  • invite_list_project / invite_list_group: project_id* or group_id*

  • invite_project / invite_group: project_id* or group_id*, email*, access_level*, expires_at

See also: gitlab_user (SSH/GPG keys, user PATs), gitlab_admin (instance admin), gitlab_project (project settings)

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?

Beyond the destructiveHint annotation, the description details irreversible revoke/delete actions, cleartext token one-time return, rotate behavior (new token invalidates old), and error hints (401/403/404/400) with actionable information.

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 lengthy but well-organized: starts with purpose, usage, returns, errors, conventions, then action breakdown. Slightly verbose but justified by the range of actions. Could be tightened without losing clarity.

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?

The description covers all bases: purpose, when/when not, behavioral impacts, return formats, error codes, param conventions, and references to external resources. It integrates well with the output schema mention and sibling tool references.

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 only defines two parameters (action, params) with minimal descriptions. The description supplies all per-action parameter lists, required fields, and meanings (e.g., token_project_create: project_id*, name*, scopes*, expires_at, access_level), which is essential given the open param object.

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 manages access credentials (tokens, deploy tokens, keys, requests, invitations) and differentiates from siblings by explicitly listing what it is NOT for (e.g., SSH keys via gitlab_user, PAT creation via gitlab_user, instance admin via gitlab_admin, project membership via gitlab_project).

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' (provision/audit, rotate tokens) and 'NOT for' sections with named alternative tools, giving clear guidance on when to use this tool versus siblings like gitlab_user and gitlab_project.

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