GitLab MCP Server
MCP serverDocs & knowledgeGitLab MCP server for projects, merge requests, issues, pipelines, wiki, releases, and more.
Unavailable. This server has no hosted endpoint yet, so ahel can't serve it.
Connect ahel once, and every AI you use reads what you have installed.
From the project's README
As published by zereight/gitlab-mcp in README.md.
📖 Documentation → Setup guides, environment variables, and the full tool reference live on the hosted docs site.
@zereight/mcp-gitlab
Agent-workflow-optimized GitLab MCP — manage projects, merge requests, issues, pipelines, wiki, releases, tags, milestones, and more through stdio, SSE, and Streamable HTTP.
Supports PAT, OAuth, read-only mode, dynamic API URLs, and remote authorization for VS Code, Claude, Cursor, Copilot, and other MCP clients.
Why use this GitLab MCP?
- 261 tools +
discover_tools— start with a small toolset; activate more at runtime without CQRS-style grouping - MR 2-step review —
list_merge_request_changed_files→ batchedget_merge_request_file_diff - Agent Skill built in — workflow guidance in
skills/gitlab-mcp/ - Flexible auth — Personal Access Token, local OAuth2 browser flow, MCP OAuth proxy, and per-request remote authorization
- Multiple transports — stdio for local clients, SSE for legacy clients, and Streamable HTTP for modern remote deployments
- Client-friendly setup — examples for Claude Code, Codex, Antigravity, OpenCode, Copilot, Cline, Roo Code, Cursor, Kilo Code, and Amp Code
- Self-hosted ready — works with custom GitLab instances, proxy settings, and dynamic API URL routing
How we compare
| @zereight/mcp-gitlab | GitLab MCP A (community CQRS-style) | |
|---|---|---|
| Best for | AI agent workflows | Enterprise multi-instance / grouped tools |
| Tool model | ~261 granular tools + discover_tools | ~50–60 grouped browse_* / manage_* tools |
| MR review | 2-step batched diff | Varies |
| Node.js | >=18.17 | Often >=24 |
| License | MIT | Varies |
Quick start: choose either Personal Access Token or OAuth2 setup below, install @zereight/mcp-gitlab, and use zereight-mcp-gitlab in your MCP client configuration.
Client Setup Guides
- Claude Code Setup Guide
- VS Code Setup Guide
- GitHub Copilot Setup Guide
- Codex Setup Guide
- Cursor Setup Guide
- JSON-Based MCP Clients Setup Guide - for Factory AI Droid, OpenClaw, and OpenCode style clients
- OAuth2 Authentication Setup Guide
- Environment Variables Reference
- Stateless Mode — Multi-Pod HPA
- Custom Agents and Multiple PAT Setup
Usage
Setup Overview
Authentication Methods
The server supports four authentication methods:
For local/desktop use (most common):
- Personal Access Token (
GITLAB_PERSONAL_ACCESS_TOKEN) — simplest setup - OAuth2 — Local Browser (
GITLAB_USE_OAUTH) — recommended for better security
For server/remote deployments:
- OAuth2 — MCP Proxy (
GITLAB_MCP_OAUTH) — for remote MCP clients such as Claude.ai - Remote Authorization (
REMOTE_AUTHORIZATION) — multi-user deployments where each caller provides their own token
Quick setup paths
- Claude Code: see Claude Code Setup Guide
- VS Code: see VS Code Setup Guide
- GitHub Copilot: see GitHub Copilot Setup Guide
- Codex: see Codex Setup Guide
- Cursor: see Cursor Setup Guide
- Factory AI Droid / OpenClaw / OpenCode style clients: see JSON-Based MCP Clients Setup Guide
- OAuth browser flow details: see OAuth2 Authentication Setup Guide
- OAuth without a localhost callback (SSO, remote shell, background clients): run
zereight-mcp-gitlab auth(GitLab 17.9+ device flow; 17.2–17.8 needoauth2_device_grant_flow), then start the server withGITLAB_USE_OAUTH=true. See standalone device-flow command.
For the simplest local setup, start with a Personal Access Token. For browser-based local auth, use OAuth2. For remote or multi-user deployments, continue to the MCP OAuth and Remote Authorization sections later in this README.
Install the server once:
brew tap zereight/gitlab-mcp https://github.com/zereight/gitlab-mcp
brew install zereight/gitlab-mcp/zereight-mcp-gitlab
Or with npm:
npm install -g @zereight/mcp-gitlab
Or with Nix, by adding this flake to your own:
# flake.nix
inputs.gitlab-mcp.url = "github:zereight/gitlab-mcp";
# wherever you configure your MCP client:
command = lib.getExe inputs.gitlab-mcp.packages.${system}.default;
The store path is pinned by your lock file; update it with nix flake update gitlab-mcp.
The examples use zereight-mcp-gitlab, a less collision-prone alias for the legacy mcp-gitlab binary. If your MCP client cannot find it, use the absolute path from which zereight-mcp-gitlab.
No global install? Pin npx to the previous stable release (the version these docs recommend), for example npx -y @zereight/mcp-gitlab@2.1.60. If you always want the newest release, use npx -y @zereight/mcp-gitlab@latest instead. The server prints a notice to stderr on startup when a newer version is available (disable with GITLAB_DISABLE_VERSION_CHECK=true).
Using CLI Arguments (for clients with env var issues)
Some MCP clients (like GitHub Copilot CLI) have issues with environment variables. Use CLI arguments instead:
{
"mcpServers": {
"gitlab": {
"command": "zereight-mcp-gitlab",
"args": ["--token=YOUR_GITLAB_TOKEN", "--api-url=https://gitlab.com/api/v4"],
"tools": ["*"]
}
}
}
Available CLI arguments:
--token- GitLab Personal Access Token (replacesGITLAB_PERSONAL_ACCESS_TOKEN)--api-url- GitLab API URL (replacesGITLAB_API_URL)--read-only=true- Enable read-only mode (replacesGITLAB_READ_ONLY_MODE, deprecated — prefer--permission-mode=readonly)--permission-mode- Permission level:readonly,modify(no delete tools), orfull(replacesGITLAB_PERMISSION_MODE, defaultfull)--use-wiki=true- Enable wiki API (replacesUSE_GITLAB_WIKI, legacy — preferGITLAB_TOOLSETS=wiki)--use-milestone=true- Enable milestone API (replacesUSE_MILESTONE, legacy — preferGITLAB_TOOLSETS=milestones)--use-pipeline=true- Enable pipeline API (replacesUSE_PIPELINE, legacy — preferGITLAB_TOOLSETS=pipelines)--disable-version-check=true- Disable the startup new-version notice (replacesGITLAB_DISABLE_VERSION_CHECK)
CLI arguments take precedence over environment variables.
zereight-mcp-gitlab auth is a subcommand (not an MCP server flag). It runs GitLab device flow and exits. See CLI Arguments.
Fine-grained tool filtering: use
GITLAB_PERMISSION_MODE=modifyto allow create/update while blocking every delete tool (including delete mutations throughexecute_graphqlandpush_filesdelete/moveactions), orGITLAB_PERMISSION_MODE=readonlyfor read-only access. You can also enable toolset groups withGITLAB_TOOLSETS=<group,…>, allow-list individual tools withGITLAB_TOOLS=<tool,…>(e.g. read-only groups plus a few specific write tools), and deny-list by pattern withGITLAB_DENIED_TOOLS_REGEX. The legacyUSE_GITLAB_WIKI/USE_MILESTONE/USE_PIPELINEflags are kept for backward compatibility only. See Tools Reference and Environment Variables.
- sse
docker run -i --rm \
-e HOST=0.0.0.0 \
-e GITLAB_PERSONAL_ACCESS_TOKEN=your_gitlab_token \
-e GITLAB_API_URL="https://gitlab.com/api/v4" \
-e GITLAB_PERMISSION_MODE=readonly \
-e GITLAB_TOOLSETS=wiki,milestones,pipelines \
-e SSE=true \
-e SSE_AUTH_TOKEN=your_mcp_sse_token \
-p 3333:3002 \
zereight050/gitlab-mcp
{
"mcpServers": {
"gitlab": {
"type": "sse",
"url": "http://localhost:3333/sse",
"headers": {
"Authorization": "Bearer your_mcp_sse_token"
}
}
}
}
- streamable-http
docker run -i --rm \
-e HOST=0.0.0.0 \
-e REMOTE_AUTHORIZATION=true \
-e GITLAB_API_URL="https://gitlab.com/api/v4" \
-e GITLAB_PERMISSION_MODE=readonly \
-e GITLAB_TOOLSETS=wiki,milestones,pipelines \
-e STREAMABLE_HTTP=true \
-p 3333:3002 \
zereight050/gitlab-mcp
{
"mcpServers": {
"gitlab": {
"type": "streamable-http",
"url": "http://localhost:3333/mcp",
"headers": {
"Authorization": "Bearer glpat-..."
}
}
}
}
Using MCP OAuth Proxy (GITLAB_MCP_OAUTH)
For server/remote deployments only. This mode requires the MCP server to be deployed with a publicly accessible HTTPS URL. For local/desktop use, see
GITLAB_USE_OAUTHabove.
For remote MCP clients that support the MCP OAuth specification (e.g. Claude.ai).
The server acts as a full OAuth 2.0 authorization server — unauthenticated requests
receive a 401 + WWW-Authenticate response, which triggers the OAuth browser flow
automatically on the client side.
Remote MCP clients such as OpenCode, MCPJam, and Claude.ai can send their own
callback URL during authorization. If you cannot register every client callback
URL in GitLab, enable GITLAB_OAUTH_CALLBACK_PROXY=true. With callback proxy
mode, GitLab only needs one registered redirect URI: {MCP_SERVER_URL}/callback.
GITLAB_OAUTH_REDIRECT_URI is for local OAuth (GITLAB_USE_OAUTH) only. It does
not override remote MCP OAuth client callback URLs and should not be used to fix
remote Unregistered redirect_uri errors.
This variable exists because the local OAuth flow starts a browser on the same
machine as the MCP server and listens for the callback on a local HTTP server,
for example http://127.0.0.1:8888/callback.
Remote MCP OAuth is different. In GITLAB_MCP_OAUTH=true mode, the MCP client
provides its own callback URL during /authorize. GITLAB_OAUTH_REDIRECT_URI
does not replace that client-provided URL.
| Mode | Enable with | Callback variable | GitLab redirect URI |
|---|---|---|---|
| Local OAuth | GITLAB_USE_OAUTH=true | GITLAB_OAUTH_REDIRECT_URI | http://127.0.0.1:8888/callback or your local callback |
| Remote MCP OAuth | GITLAB_MCP_OAUTH=true | GITLAB_OAUTH_CALLBACK_PROXY=true | {MCP_SERVER_URL}/callback |
Use GITLAB_OAUTH_REDIRECT_URI only when the MCP server itself owns the local
browser callback. Use GITLAB_OAUTH_CALLBACK_PROXY=true when a remote MCP client
owns the callback URL.
How it works: You deploy this MCP server somewhere with a public HTTPS URL. MCP
clients connect to {MCP_SERVER_URL}/mcp. The server handles the OAuth 2.0 flow,
exchanging credentials with GitLab on behalf of the client.
Prerequisites:
- A publicly accessible HTTPS server URL (
MCP_SERVER_URL) — use ngrok for local testing - A pre-registered GitLab OAuth application with
api(orread_api) scopes — Go toAdmin area→Applications, set Redirect URI to{MCP_SERVER_URL}/callback
| Environment Variable | Required | Description |
|---|---|---|
GITLAB_MCP_OAUTH | ✅ | Set to true to enable |
GITLAB_API_URL | ✅ | GitLab API base URL |
GITLAB_OAUTH_APP_ID | ✅ | GitLab OAuth Application ID |
MCP_SERVER_URL | ✅ | Public HTTPS URL of this MCP server |
STREAMABLE_HTTP | ✅ | Must be true |
GITLAB_OAUTH_CALLBACK_PROXY | optional | Set to true to use the MCP server's fixed /callback URL |
GITLAB_OAUTH_SCOPES | optional | Comma-separated scopes (default: api,read_api,read_user) |
GITLAB_OAUTH_ALLOWED_GROUPS | optional | Comma-separated group full paths — only members (and subgroup members) may obtain a token (replaces deprecated GITLAB_ALLOWED_GROUPS) |
When STREAMABLE_HTTP=true, server-side GitLab credentials (GITLAB_PERSONAL_ACCESS_TOKEN, GITLAB_JOB_TOKEN, GITLAB_AUTH_COOKIE_PATH, or GITLAB_USE_OAUTH) require REMOTE_AUTHORIZATION=true, GITLAB_MCP_OAUTH=true, or STREAMABLE_HTTP_AUTH_TOKEN.
Troubleshooting
Unregistered redirect_uriCheck the
redirect_uriin the browser URL. If it points to a client callback such ashttp://127.0.0.1:xxxxx/.../callback, enable:GITLAB_OAUTH_CALLBACK_PROXY=trueDo not fix remote MCP OAuth by changing
GITLAB_OAUTH_REDIRECT_URI. That variable is for local OAuth (GITLAB_USE_OAUTH) only.
docker run -i --rm \
-e HOST=0.0.0.0 \
-e GITLAB_MCP_OAUTH=true \
-e GITLAB_OAUTH_CALLBACK_PROXY=true \
-e STREAMABLE_HTTP=true \
-e MCP_SERVER_URL=https://your-server.example.com \
-e GITLAB_API_URL="https://gitlab.com/api/v4" \
-e GITLAB_OAUTH_APP_ID=your_app_id \
-p 3000:3002 \
zereight050/gitlab-mcp
MCP client configuration:
{
"mcpServers": {
"gitlab": {
"type": "http",
"url": "https://your-server.example.com/mcp"
}
}
}
Using Remote Authorization (REMOTE_AUTHORIZATION)
For server/remote deployments only. Each HTTP caller provides their own GitLab token directly in request headers — no OAuth flow involved.
For multi-user or multi-tenant deployments where each caller provides their own GitLab token in the HTTP request header. No OAuth flow — the MCP server forwards the token to GitLab on behalf of the caller.
Header priority: Private-Token > JOB-TOKEN > Authorization: Bearer
| Environment Variable | Required | Description |
|---|---|---|
REMOTE_AUTHORIZATION | ✅ | Set to true to enable |
STREAMABLE_HTTP | ✅ | Must be true |
ENABLE_DYNAMIC_API_URL | optional | Allow per-request GitLab URL via X-GitLab-API-URL header |
GITLAB_ALLOWED_HOSTS | optional | Comma-separated allowed X-GitLab-API-URL hosts; GITLAB_API_URL hosts are always allowed |
GITLAB_ALLOW_UNAUTHENTICATED_TOOL_DISCOVERY | optional | Allow unauthenticated initialize, notifications/initialized, tools/list, and server/discover only (tool calls still require auth) |
MCP_SERVER_URL / MCP_ALLOWED_HOSTS / MCP_ALLOWED_ORIGINS | optional | Allowed public /mcp host/origin values for DNS rebinding protection |
MCP_TRUST_PROXY | optional | Trust Forwarded / X-Forwarded-* headers behind a reverse proxy (download URLs, Express req.ip, /mcp IP rate limits, OAuth rate limits) |
GITLAB_ALLOW_UNAUTHENTICATED_TOOL_DISCOVERY=true is intended for MCP gateways
or admin UIs that need to inspect tool metadata before a user provides a GitLab
token. Leave it disabled unless the tool list is safe to expose in your deployment.
When MCP_SERVER_URL is not set, remote download URLs fall back to the local
server address. Set MCP_TRUST_PROXY=true only if the server is reachable through a
trusted reverse proxy and direct client access to the MCP server is blocked.
This enables Express trust proxy for Streamable HTTP and SSE, derives public
download URLs from Forwarded / X-Forwarded-Proto / X-Forwarded-Host /
X-Forwarded-Prefix, and keeps OAuth endpoint rate limiting working when
proxies send X-Forwarded-For with a client port (for example 1.2.3.4:5678).
Existing OAuth+proxy deployments must set this explicitly after the flag was
introduced.
Example request headers:
Private-Token: glpat-xxxxxxxxxxxxxxxxxxxx
or using a Bearer token:
Authorization: Bearer glpat-xxxxxxxxxxxxxxxxxxxx
⚠️
REMOTE_AUTHORIZATIONis not compatible with SSE transport.STREAMABLE_HTTP=trueis required.
Environment Variables
Use the dedicated reference for the full environment variable list:
Most users only need one of these starting sets:
- Local PAT:
GITLAB_PERSONAL_ACCESS_TOKEN,GITLAB_API_URL - Local OAuth:
GITLAB_USE_OAUTH=true,GITLAB_OAUTH_CLIENT_ID,GITLAB_OAUTH_REDIRECT_URI,GITLAB_API_URL - Remote multi-user HTTP:
STREAMABLE_HTTP=true,REMOTE_AUTHORIZATION=true(orGITLAB_MCP_OAUTH=true),MCP_TRUST_PROXY=true(behind a reverse proxy),MAX_REQUESTS_PER_MINUTE=300,MCP_SERVER_URLorMCP_ALLOWED_HOSTS,HOST,PORT - Multiple side-by-side deployments: set a distinct
MCP_SERVER_NAMEper instance (e.g.gitlab-selfhosted-readonly) so clients, logs, and telemetry can tell them apart - Multi-pod HPA (stateless): above +
OAUTH_STATELESS_MODE=true,OAUTH_STATELESS_SECRET(same across all pods). See Stateless Mode.
Commonly referenced variables:
GITLAB_API_URLGITLAB_PERSONAL_ACCESS_TOKENGITLAB_USE_OAUTHREMOTE_AUTHORIZATIONMCP_TRUST_PROXYMAX_REQUESTS_PER_MINUTEMAX_SESSIONSMCP_ALLOWED_HOSTSMCP_ALLOWED_ORIGINSGITLAB_MCP_OAUTHGITLAB_OAUTH_CALLBACK_PROXYOAUTH_REGISTER_RATE_LIMIT_PER_HOUROAUTH_STATELESS_MODEOAUTH_STATELESS_SECRET
The reference document also covers:
- auth and OAuth variables
- MCP OAuth proxy variables
- project and tool filtering variables
- dynamic tool discovery via
discover_tools(on-demand toolset activation) - transport and session variables
- proxy and TLS variables
For callback proxy mode details, see GitLab MCP OAuth Callback Proxy.
Remote Authorization Setup (Multi-User Support)
When using REMOTE_AUTHORIZATION=true, the MCP server can support multiple users, each with their own GitLab token passed via HTTP headers. This is useful for:
- Shared MCP server instances where each user needs their own GitLab access
- IDE integrations that can inject user-specific tokens into MCP requests
Setup Example:
# Start server with remote authorization
docker run -d \
-e HOST=0.0.0.0 \
-e STREAMABLE_HTTP=true \
-e REMOTE_AUTHORIZATION=true \
-e GITLAB_API_URL="https://gitlab.com/api/v4" \
-e GITLAB_PERMISSION_MODE=readonly \
-e SESSION_TIMEOUT_SECONDS=3600 \
-p 3333:3002 \
zereight050/gitlab-mcp
Client Configuration:
Your IDE or MCP client must send one of these headers with each request:
Authorization: Bearer glpat-xxxxxxxxxxxxxxxxxxxx
or
Private-Token: glpat-xxxxxxxxxxxxxxxxxxxx
The token is stored per session (identified by mcp-session-id header) and reused for subsequent requests in the same session.
Remote Authorization Client Configuration Example with Cursor
{
"mcpServers": {
"GitLab": {
"url": "http(s)://<your_mcp_gitlab_server>/mcp",
"headers": {
"Authorization": "Bearer glpat-..."
}
}
}
}
Important Notes:
- Remote authorization only works with Streamable HTTP transport
- Each session is isolated - tokens from one session cannot access another session's data Tokens are automatically cleaned up when sessions close
- Session timeout: Auth tokens expire after
SESSION_TIMEOUT_SECONDS(default 1 hour) of inactivity. After timeout, the client must send auth headers again. The transport session remains active. - Each request resets the timeout timer for that session
- Rate limiting:
/mcprequests are limited toMAX_REQUESTS_PER_MINUTEper client IP, and per MCP session when using OAuth or remote authorization (default 60). See environment-variables.md. - Capacity limit: Server accepts up to
MAX_SESSIONSconcurrent sessions (default 1000)
MCP OAuth Setup (Claude.ai Native OAuth)
When using GITLAB_MCP_OAUTH=true, the server acts as an OAuth proxy to your GitLab
instance. Claude.ai (and any MCP-spec-compliant client) handles the entire browser
authentication flow automatically — no manual Personal Access Token management needed.
Prerequisites:
Shortened here. Read the whole README on GitHub.
Signals
- GitHub stars
- 2k
- Forks
- 354
- Last commit
- Sep 2026
ahel review
S4info
community integration — published by zereight, not gitlab
Automated review, not a security audit. Ruleset v1.
Advanced
- Delivery
- gitlab-mcp MCP server → your ahel gateway (mcp.ahel.ai) → every connected AI client.
- Catalog kind
- mcp-server
- Gateway key
io-github-zereight-gitlab-mcp- Source
- github.com/zereight/gitlab-mcp