Gitlab MCP Server

What jmrplens/gitlab-mcp-server does

GitLab API operations are presented through a catalog of more than 1,000 actions spanning GitLab REST and GraphQL capabilities. The catalog covers GitLab tiers from Free or Community Edition through Premium and Ultimate, including GitLab.com and self-managed deployments. The server detects the available GitLab tier and adjusts the action surface accordingly.

Rather than registering every catalog entry as an individual MCP tool, the default interface uses discovery and execution tools. This keeps the startup tool surface smaller while still allowing an agent to reach actions such as listing issues, reviewing merge requests, investigating pipelines, or generating release information.

How it works

gitlab_find_action searches a local action catalog without making a GitLab API request. It can return matching action IDs, aliases, parameter schemas, usage hints, destructive-operation indicators, and example calls. This is useful when the agent knows the intended task but not the exact catalog identifier or required parameters.

gitlab_execute_action runs one catalog action. The action is selected by canonical ID or alias, and parameters must be supplied as an object. For example, an issue listing can target a project using an action such as issue.list with a project_id parameter. Destructive actions require a top-level confirm=true value before execution.

The binary supports stdio for local desktop and editor integrations and HTTP for shared deployments. HTTP mode includes OAuth support and keeps credentials separated between users. The server can also expose one tool per domain or per action instead of the default dynamic surface.

Setup and configuration

Install the server through a native release artifact, package distribution, Docker image, or the Claude Desktop extension. Builds target Windows, Linux, and macOS on amd64 and arm64. Docker-based client registrations require Docker.

Set GITLAB_TOKEN to a GitLab personal, project, group, fine-grained, or other supported access token. A token with the api scope provides the broadest access; read_api can be used for actions that GitLab permits with read-only access. Fine-grained token permissions are evaluated per action.

Set GITLAB_MCP_READ_ONLY=true when the server must not write to GitLab. Safe mode can preview writes instead of applying them, and tools can be excluded by name. HTTP deployments can use OAuth rather than passing a token directly.

Tools and capabilities

• Search the local GitLab action catalog with gitlab_find_action.
• Execute catalog actions by canonical ID or alias with gitlab_execute_action.
• Inspect action schemas, parameter guidance, examples, and destructive flags before execution.
• Work across GitLab projects, groups, issues, merge requests, pipelines, and other API domains.
• Choose dynamic, domain-level, or action-level MCP tool surfaces.
• Connect through stdio or HTTP transports.
• Use read-only, safe-preview, confirmation, and tool-exclusion controls.
• Use GitLab OAuth in HTTP mode.

Limitations and notes

The breadth of the catalog means the agent may need to search before executing an action when the action name or parameters are unclear. Discovery is local and does not query GitLab, while execution does make the corresponding GitLab API request.

Destructive operations are guarded by confirmation, and read-only or safe modes change how write-capable actions behave. The token still needs the permissions required by the selected GitLab action. Dynamic mode is intended to reduce startup context compared with exposing every catalog action as an individual MCP tool.