GitLab MCP Server: Setup, Tools and MCP vs glab

GitLab’s official MCP server is part of GitLab itself, at https://gitlab.com/api/v4/mcp on GitLab.com or https://<your-instance>/api/v4/mcp on a self-managed or Dedicated instance. It uses HTTP transport and signs you in with OAuth, registering your assistant as an OAuth application on first connection, so there is no token to paste. It is in beta and available on the Free, Premium and Ultimate tiers, but somebody has to switch it on first: a top-level group Owner on GitLab.com, or an administrator on a self-managed instance. Once it is on, Claude Code connects with one command. This guide covers that switch, each client, the tools, and when the glab command line is the better choice for an agent.

If MCP itself is new to you, start with what MCP is.

Before you start: turn it on

The server refuses requests until access is allowed. On GitLab.com, an Owner of the top-level group goes to Settings > General, expands Permissions and group features, and ticks Allow connection to GitLab in the MCP client access section, as GitLab’s group settings page↗ (opens in a new tab) describes. On GitLab Self-Managed and Dedicated, an administrator ticks the same box under Admin > Settings > General > Visibility and access controls, and turning it off makes the MCP API reject every request.

If a client connects, completes sign-in and then gets 403 Forbidden (or 404 on GitLab 19.4 and earlier), this switch is the usual cause. The response body says which: disabled for the instance, or not enabled for any top-level group you belong to.

On a self-managed instance, the version matters. GitLab’s history notes say the server became a beta in 18.6 and moved to the Free tier in 19.2; toolset selection arrived in 19.5 behind a feature flag that is off by default. Check your instance’s version before following any step that depends on a recent change.

Add it to Claude Code

claude mcp add -s user --transport http GitLab https://gitlab.com/api/v4/mcp

Replace gitlab.com with your instance’s host if you self-manage. The -s user scope makes the server available in every project; without it, it is added for the current directory only. Then start claude, type /mcp, choose GitLab and approve the request in your browser. GitLab’s MCP server documentation↗ (opens in a new tab) notes that claude mcp add will not overwrite an existing entry with the same name, so if an older local-scope entry exists, remove it with claude mcp remove GitLab -s local first.

Cursor, VS Code and other clients

• Cursor: Settings > Cursor Settings > Tools & MCP > New MCP Server, then add "GitLab": { "type": "http", "url": "https://gitlab.com/api/v4/mcp" } under mcpServers. Save, and approve the OAuth page when your browser opens.
• GitHub Copilot in VS Code: run MCP: Add Server from the Command Palette, choose HTTP, enter the URL and the ID GitLab. The authorisation page should follow. The general Copilot setup is on the GitHub Copilot integration page.
• Claude Desktop and Zed connect through the mcp-remote proxy, which needs Node.js 20 or later on the PATH: the command is npx with the arguments -y, mcp-remote and the server URL.
• GitLab also documents Gemini CLI, OpenAI Codex, Kiro, OpenCode and Amazon Q Developer, each in its own configuration format.

Sign-in and self-managed instances

Every client uses OAuth 2.0 Dynamic Client Registration: on first connection the assistant registers itself as an OAuth application on your instance, you approve it in the browser, and it receives an access token for your account. On a large self-managed instance that can create many OAuth applications, and GitLab rate-limits registrations to 10 per hour per IP address, which people behind one corporate egress address can hit.

The fix is a shared, pre-registered OAuth application with the mcp scope and Confidential cleared, created for the instance, a group or a single user. Clients that accept a clientId then reuse it, and each person still signs in with their own GitLab account; the shared app is the client identity, not a shared credential. If an administrator turns registration off, this is the only way in. The redirect URI must match exactly what your client sends, so different clients may need separate applications.

Tools and toolsets

The GitLab MCP server tools reference↗ (opens in a new tab) lists what the server offers: get_project, list_projects, search across scopes such as work items, merge requests and projects; list_work_items, get_work_item, save_work_item and link_work_items; get_merge_request, list_merge_requests, save_merge_request, save_merge_request_review and accept_merge_request; get_pipeline, list_pipelines, get_job and manage_pipeline; plus branch, commit, file, release and wiki tools. Older tools such as create_issue are unlisted in favour of the work item tools but stay callable while callers migrate.

Where toolset selection is enabled, the X-Gitlab-Enabled-Mcp-Server-Toolsets header narrows the list. The defaults are core, merge_requests, work_items, repository and ci; wikis, code_security and duo_agent_platform are opt-in, and all asks for everything. In Claude Code, pass it with --header:

claude mcp add -s user --transport http GitLab https://gitlab.com/api/v4/mcp \
  --header "X-Gitlab-Enabled-Mcp-Server-Toolsets: core,work_items"

Connected to more than one GitLab instance, or to another server with similar tool names? The X-Gitlab-Mcp-Server-Tool-Name-Prefix header adds a prefix of up to 32 characters to every tool name.

First prompts and permissions

• “Which GitLab MCP server version am I connected to?” A quick check that sign-in worked.
• “List the open work items assigned to me in acme/payments.”
• “Summarise merge request 88, its unresolved discussions and its latest pipeline.”
• One write you can check: “Create an issue in acme/payments titled ‘Retry job double-charges on timeout’ with these steps.”

The server acts on your behalf with your GitLab permissions: it lists projects where you have at least the Guest role, and a tool like accept_merge_request can only do what your role allows. GitLab also warns, on every client’s setup section, that you are responsible for guarding against prompt injection and should use the tools only on GitLab objects you trust. Issue text and merge request comments on a public project are written by anyone; the risk is laid out in MCP security risks. In Claude Code, keep the save, accept and manage tools on ask.

GitLab MCP server vs glab for agents

An agent with a shell can also use glab, GitLab’s CLI; the general trade-off is in MCP vs CLI for AI agents. Commands such as glab issue list --assignee=@me --output json, glab mr view 88 --comments and glab api for anything the commands do not cover give it the same data. The choice comes down to a few points:

• Where the agent runs. glab needs a terminal on a machine you control. The MCP server works in clients with no shell, such as Claude Desktop, and needs nothing installed for HTTP clients.
• Sign-in. glab auth login↗ (opens in a new tab) stores a token or an OAuth login in your operating system’s keyring, and every command runs with it. The MCP server gets its own OAuth grant per client, which you can see and revoke separately.
• Context cost. MCP tool definitions are loaded into the conversation; glab costs nothing until the agent runs --help or a command. Narrow toolsets close much of that gap.
• Structured results. Both return JSON: glab with --output json, the MCP server by design.
• Maturity. glab mcp serve exists, but its own page calls it an experiment that is not ready for production use. GitLab’s built-in server is the supported MCP route.

A reasonable split: a coding agent in your terminal uses glab for merge requests and pipelines it is already working on, and assistants in chat apps, or shared team setups, use the MCP server. The same trade-off for other trackers is worked through in Jira MCP vs the Jira API and Linear MCP vs CLI vs API.

Limits and removing it

• Beta. Tool names and parameters are still changing between releases.
• Protocol versions. GitLab supports MCP revisions up to 2025-11-25 and answers a client asking for 2026-07-28 with 2025-11-25.
• It works as you. There is no separate assistant identity with narrower rights.

Remove it with claude mcp remove GitLab. The OAuth application the client registered stays on your account until you revoke it in your GitLab user settings under applications, so do that too.

If the work is a task list

GitLab work items are the right home for work that lives next to the code. When the list also needs a client, a designer or a tester who will never open GitLab, fenbs is a board they can join with an email and a role. An AI assistant joins it the same way, over OAuth to https://fenbs.ai/api/mcp with the scopes you approve, and every change it makes is recorded under its name. The setup is on the MCP docs page.