GitLab 19.5: MCP Server GA Lets Outside Agents In, With Limits

GitLab 19.5: MCP Server GA Lets Outside Agents In, With Limits

Enterprise Developer Platforms

Until this release, GitLab’s AI governance tooling tracked only GitLab’s own agents, and 19.5 opens the door to everyone else’s: Claude Code, Cursor and Codex can now reach GitLab’s full tool catalog and show up in its governance dashboard. The GitLab 19.5 release notes, published October 15, pair that openness with something agent users will notice first, a per-user rate limit on the MCP server. Platform and security teams now have to decide how much of GitLab outside agents can touch, and how they will see what those agents did.

What Happened

The GitLab MCP server is generally available on every tier. Any MCP-compatible agent gets direct access to the expanded catalog of GitLab tools, plus GitLab Duo Agent Platform agents and flows. New tools let an agent read a single file from a CI/CD job’s artifacts without downloading the archive, browse the group hierarchy with list_groups, and start and track Duo sessions. Administrators can choose which toolsets the server exposes, which GitLab notes keeps unneeded tools from wasting context window space.

Starting October 15, GitLab.com limits each user to 60 MCP requests a minute on Free and 600 on Premium and Ultimate. Every reconnect and retry counts.

GitLab Secrets Manager, built on OpenBao, is also generally available on GitLab.com and Self-Managed for Premium and Ultimate. It scopes each CI secret to the job that needs it by environment, branch and branch protection rules, logs every create, read, update and delete, and consumes GitLab Credits.

Why It Matters

The governance change is what makes outside agents manageable. Until now, the AI Governance Dashboard showed only GitLab’s own Agent Platform agents. In 19.5, after a one-time glab govern setup, externally connected agents such as Claude Code, Cursor and Codex can report into it, capturing who ran each session, which agent, which project and when, with tool calls in the dashboard and audit events streamed to a SIEM. Tool output isn’t sent, apart from short error messages, and the feature is in beta.

The rate limit matters because agents retry aggressively. GitLab’s own advice is that an agent hitting HTTP 429 errors should have its reconnect and retry settings checked before anyone upgrades a tier.

What This Means for Builders

Several 19.5 features shift work from people to flows. The Recommend Reviewers Flow, now generally available, suggests the minimum reviewers for each approval rule based on availability, workload, time zone and recent activity. Code Review Flow follow-ups now read earlier threads and replies, so GitLab Duo stops repeating points a developer already answered. A new auto mode in GitLab Duo CLI runs tools without per-step approval; it is off by default, admins can lock it off, and GitLab advises using it only in trusted repositories on branches you can discard. Self-managed teams on Amazon Bedrock can now assign a separate IAM role per model. Stack Archive covered where this platform started in GitLab 19.0: Secrets Manager, Agentic Merge Requests, and the DevSecOps Platform Bet.

The So What

Platform teams that let developers use Claude Code or Cursor against GitLab should do three things this sprint: restrict the MCP server to the toolsets those agents need, run the glab govern setup so external agent sessions reach the AI Governance Dashboard, and check agent retry settings against the 60 or 600 requests-a-minute limits before GitLab.com starts returning 429 errors.

Source: GitLab

Content created with AI assistance and reviewed for accuracy.

💬

Join the conversation

Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.

Join Stack Insiders →

Newsletter coming soon.

Curated digests across AI, biohacking, photography, travel, and more. Be the first to know when we launch.