# jmrplens/gitlab-mcp-server [Health: Active]

**Category:** 🔄 Version Control  
**Repository:** https://github.com/jmrplens/gitlab-mcp-server  
**GitHub Stars:** 47  
**npm Downloads (last month):** 1242  
**Views:** 3  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/jmrplens-gitlab-mcp-server

## Description
Complete GitLab REST API v4 coverage with 1006 MCP tools across 162 domains, 42 meta-tools, 24 resources, and 38 prompts. Cross-platform Go binary with stdio and HTTP transports, OAuth support, auto-update, read-only and safe modes.

## Tools
Capabilities this server exposes over MCP:

- **gitlab_execute_action** — Execute one GitLab catalog action by canonical ID or alias. Always pass params as an object. Destructive actions require top-level confirm=true. Use find first only when action or params are unclear. Example: {"action":"issue.list","params":{"project_id":"group/project"}}
- **gitlab_find_action** — Search the local GitLab action catalog. Read-only and no GitLab API call. Use when the action ID or params are unclear. Returns schemas, hints, destructive flags, and execute examples. Example: {"query":"issue list"}

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "gitlab-mcp-server": {
    "command": "npx",
    "args": ["-y","@jmrp.io/gitlab-mcp-server"],
    "env": {
      "GITLAB_TOKEN": "",
      "GITLAB_MCP_READ_ONLY": ""
    }
  }
}
```

**Requires environment variables:** `GITLAB_TOKEN`, `GITLAB_MCP_READ_ONLY` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## 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.

_Full upstream README: https://allmcps.com/mcp/jmrplens-gitlab-mcp-server/readme_