Connecting agents to GitLab with the MCP server¶

GitLab publishes an MCP server that gives an agent a direct, authenticated route into issues, merge requests, pipelines and repository contents. We think it should be the first thing you reach for when you want an agent to work with GitLab. This page explains what it is, how its authentication constrains what an agent can do, and where it fits alongside the tools we already use. Setup takes a few minutes and GitLab documents it well, so we won't repeat it here.

Where MCP stands today¶

MCP still carries a reputation problem in parts of the industry, and it isn't baseless. The protocol launched in November 2024 with a thin security story, and by mid-2025 a widely shared critique was Armin Ronacher's tools post. His argument was that MCP isn't truly composable and that it burns context, because you load every tool definition up front and every call costs more tokens than just writing a script would. For bulk work that argument is still fair, and we come back to it below.

What's changed is everything underneath. The protocol gained OAuth 2.1 with PKCE in March 2025. The June 2025 revision reclassified MCP servers as OAuth 2.0 Resource Servers and required RFC 8707 resource indicators, which bind an access token to one specific server so a stolen token can't be replayed elsewhere. November 2025 added incremental scope consent. The current stable specification, 2026-07-28, adds RFC 9207 issuer validation to close authorisation-server mix-up attacks, and introduces a formal deprecation policy with a twelve-month minimum window.

Governance moved too. Anthropic created MCP, but 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 alongside them as platinum members. Copyright now sits with the foundation and the project is moving from MIT to Apache-2.0, so the protocol no longer depends on a single vendor.

So the protocol's authentication story is settled. The live risk has moved from the protocol to the question of which servers you trust. Research through 2026 found tool-poisoning success rates above 60% against major agents, and around 200,000 publicly exposed server instances. Those are real numbers, and they're an argument for being selective rather than an argument for abstaining. A first-party server, published by the vendor whose data it exposes, running on our own instance, is about the lowest-risk category there is. That's exactly the distinction our GenAI policy already draws when it says to use trusted servers only.

How authentication works¶

When Claude Code first connects, it registers itself with GitLab as an OAuth application, you authorise it in the browser with your own GitLab credentials, and it receives an access token. No token is minted by hand, none is pasted into a config file, and the client refreshes and stores it for you. You can revoke it from your GitLab account settings at any time.

The convenience is nice. The important part is the scope.

What the `mcp` scope unlocks	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

Least privilege here is a property of the scope, not of how carefully you use it. There's no all-permissions variant of the mcp scope to accidentally grant, because the scope's ceiling is the tool list itself.

Permissions then apply a second time on every call. GitLab is explicit about this in its documentation on tool groups. "Listing a tool does not grant access. Each tool still checks your project and namespace permissions when called." An agent acting for you is bounded by your GitLab role, so it can't reach a project you can't reach, and a Reporter's agent can't do a Maintainer's work.

If you want a harder boundary than GitLab's curation gives you, Claude Code's permission rules take individual tool names in the form mcp__GitLab__<tool>, so you can deny specific tools outright or require approval per call.

What the tools can and can't do¶

GitLab publishes over 50 tools, and the shape of that list is the point. It's heavily weighted towards reading data. You get list_, get_ and search tools across projects, groups, merge requests, work items, pipelines, jobs, commits, branches, releases, tags, wikis and vulnerabilities, plus semantic search across the instance. The write tools are the everyday collaborative ones. You can open a merge request, comment, review, create a work item, add a branch, add a commit, fork, and retry a pipeline.

What's absent matters more than what's present. There is no tool to delete a project or a group, no tool to delete a branch, no tool to add or remove members, nothing for CI/CD variables, deploy keys, access tokens, webhooks, protected branch rules or project settings. Those are precisely the operations you would worry about an agent reaching, and the scope gives it no route to any of them.

Where glab and the API still fit¶

The MCP server isn't a replacement for the CLI, and reaching for it reflexively would be its own mistake.

In CI. There's no interactive OAuth flow in a pipeline job. Use the CI job token with glab or glab api, as we do today.
For bulk or scripted work. This is where Ronacher's composability point bites hardest. If you need the same operation across 300 projects, one tool call per project is slow and expensive, and a script that loops over glab api is the right answer. MCP suits conversational, exploratory work where the agent is deciding what to do next.
For real git operations. add_commit writes a commit through the API. It isn't git. Cloning, rebasing, resolving conflicts and pushing all belong to git and glab.
For anything with no tool. Releases, tags, members, variables, protected branches, settings, webhooks. If it's not in the tool list, the API is your only route.

So the two complement each other. Use the MCP tools for reading and for routine merge request and issue work, which is most of what agents get asked to do, and use glab deliberately for the cases above. One practical benefit of starting with the tools is that a skill can say "use the GitLab MCP tools to fetch the open issues" in a line of prose, rather than carrying a script that has to be maintained alongside it.

What this doesn't give you¶

Being straight about the limits, because anyone evaluating this will find them anyway.

Prompt injection is still yours to manage. GitLab's own documentation warns you to guard "against prompt injection when you use these tools" and to use them "only on GitLab objects you trust". An agent reading issue descriptions and merge request comments is reading text that other people wrote. See isolating agentic AI coding tools for how we contain that more broadly.

The tool list is GitLab's to change. Curation is a policy decision by a vendor, not a security boundary you control. GitLab may publish sharper tools later. If you need a guarantee rather than a reasonable expectation, express it as client-side permission rules.

Dynamic client registration is on the way out. The 2026-07-28 specification formally deprecates it in favour of Client ID Metadata Documents. There's a twelve-month minimum window, so nothing breaks soon, but the flow described above will change.

Summary¶

The GitLab MCP server authenticates with OAuth and the mcp scope, which unlocks one endpoint and a curated tool list rather than the whole API, and every call is still checked against your own GitLab permissions. That gives you least privilege by design rather than by discipline, and it removes a long-lived token from the picture. It isn't a sandbox. There are write tools, and the usual prompt injection exposure applies. Use it as the 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.