Connecting agents to GitLab with the MCP server¶

GitLab publishes an MCP server that gives an agent an authenticated route into issues, merge requests, pipelines and repository contents. We treat it as the default way for an agent to work with GitLab, and we keep glab and the API for the cases it doesn't cover.

This page explains what the server is, how its authentication bounds what an agent can do, and why we draw the line where we do. To set it up, follow Connect Claude Code to the GitLab MCP server.

Where MCP stands today¶

Parts of the industry still distrust MCP, and some of that scepticism is well founded. The protocol launched in November 2024 with a thin security model, and by mid-2025 the most widely shared criticism was Armin Ronacher's tools post.

He argued that MCP isn't truly composable and that it wastes context, because every tool definition is loaded up front and every call costs more tokens than a script would. That argument still holds for bulk work, and it shapes where we still reach for glab.

Four revisions have rebuilt the authentication story since then.

March 2025 added OAuth 2.1 with PKCE.
June 2025 reclassified MCP servers as OAuth 2.0 Resource Servers and required RFC 8707 resource indicators, which bind an access token to one server so a stolen token can't be replayed against another.
November 2025 added incremental scope consent.
2026-07-28, the current stable specification, added RFC 9207 issuer validation to close authorisation-server mix-up attacks, along with a formal deprecation policy carrying at least twelve months' notice.

Ownership moved as well. Anthropic created MCP and in December 2025 donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation. Anthropic, Block and OpenAI contributed the founding projects, and the launch announcement lists Amazon Web Services, Bloomberg, Cloudflare, Google and Microsoft as platinum members. The foundation now holds the copyright and the project is moving from MIT to Apache-2.0, so the protocol no longer depends on a single vendor.

The live risk now sits with the servers themselves. Research through 2026 found tool-poisoning attacks succeeding more than 60% of the time against major agents, and around 200,000 server instances exposed to the public internet. Both figures are an argument for being selective about which servers we connect to.

A first-party server, published by the vendor whose data it exposes and running on our own GitLab instance, sits at the low end of that risk. It is the same distinction our GenAI policy draws when it limits us to trusted servers.

How authentication works¶

The first time Claude Code connects, it registers itself with GitLab as an OAuth application. The developer authorises it in the browser with their own GitLab credentials, and the client receives an access token that it then stores and refreshes. Nobody mints a token by hand or pastes one into a config file, and the token can be revoked from GitLab account settings at any time.

The token carries the mcp scope, which reaches three things and nothing else.

What the `mcp` scope allows	What it leaves out
A single endpoint, `POST /api/v4/mcp`	Every other REST and GraphQL endpoint on the instance
The tools GitLab publishes on that endpoint	Anything those tools don't expose
Issues, merge requests, pipelines, repository contents and search	Project settings, members, CI/CD variables, deploy keys, tokens, webhooks and protected branch rules

The scope enforces least privilege on its own. There is no broader variant of mcp to grant by mistake, because its ceiling is the published tool list.

Permissions then apply a second time on every call. GitLab's documentation on tool groups is explicit that "listing a tool does not grant access. Each tool still checks your project and namespace permissions when called." An agent acting for a developer is bounded by that developer's GitLab role, so it cannot reach a project they cannot reach, and a Reporter's agent cannot do a Maintainer's work.

Claude Code's permission rules can tighten that further where we want it. They accept individual tool names in the form mcp__GitLab__<tool>, so a tool can be denied outright or made to require approval on each call.

What the tools can and can't do¶

GitLab publishes over 50 tools, weighted heavily towards reading. There are list_, get_ and search tools for projects, groups, merge requests, work items, pipelines, jobs, commits, branches, releases, tags, wikis and vulnerabilities, plus semantic search across the instance. The write tools cover everyday collaboration, so an agent can open a merge request, comment, review, create a work item, add a branch, add a commit, fork a project and retry a pipeline.

The absences are what bound the blast radius. No tool deletes a project, a group or a branch, none adds or removes members, and nothing touches CI/CD variables, deploy keys, access tokens, webhooks, protected branch rules or project settings. Those are the operations we would worry about an agent reaching, and the scope has no route to any of them.

Where glab and the API still fit¶

The server doesn't replace the CLI. Four kinds of work are still better done with glab or the API directly.

In CI. A pipeline job cannot complete an interactive OAuth flow, so our jobs continue to use the CI job token with glab and glab api.
Bulk and scripted work. Ronacher's composability point bites hardest here. The same operation across 300 projects is 300 tool calls, which is slow and token-hungry, where a loop over glab api is one script. MCP suits conversational, exploratory work, where the agent decides what to do next from what it finds.
Real git operations. add_commit writes a commit through the API, with no git involved. Cloning, rebasing, conflict resolution and pushing remain git and glab work.
Anything with no tool. Releases, tags, members, variables, protected branches, settings and webhooks have no MCP tool, which leaves the API as the only route.

Most of what we ask agents to do is reading and routine merge request and issue work, so the MCP tools are our first choice. glab covers the cases above.

Starting with the tools also keeps our skills short. A skill can say "use the GitLab MCP tools to fetch the open issues" in a line of prose, instead of carrying a script that someone has to maintain alongside it.

Limitations¶

Prompt injection remains ours to manage. GitLab's documentation warns against "prompt injection when you use these tools" and advises using them "only on GitLab objects you trust". An agent reading issue descriptions and merge request comments is reading text that other people wrote. Isolating agentic AI coding tools covers how we contain agents more generally.

The tool list is GitLab's to change. Curation is a vendor policy decision, so the absences above are a reasonable expectation and not a boundary we control. GitLab could publish sharper tools later. Client-side permission rules are the only way to make that boundary ours.

Dynamic client registration is on the way out. The 2026-07-28 specification deprecates it in favour of Client ID Metadata Documents. The twelve-month minimum window means nothing breaks soon, although the registration step will change.

Summary¶

The GitLab MCP server authenticates with OAuth and the mcp scope, which reaches one endpoint and GitLab's published tools, well short of the whole API, and every call is checked again against the developer's own GitLab permissions. That gives us least privilege with no long-lived token to manage. It is not a sandbox, because write tools exist and the usual prompt injection exposure applies.

We use it by default for reading and for routine merge request and issue work, and keep glab for CI, bulk operations and everything the tools don't reach.