GitLab MCP Server Reaches General Availability With GitLab 19.5

Why GitLab built it around MCP

GitLab argues that many agents still operate as separate tools, leaving teams to stitch together context, handoffs and permissions. When agents use APIs, they often guess at endpoints and use up their context window on extra calls, according to the company.

Model Context Protocol (MCP) is an open standard built for agents. An MCP server tells an agent what it can do and offers a curated set of tools designed around real workflows. GitLab says this lets agents get the tools they need with more focused context, in fewer calls, and with less data to carry through each task.

Each action runs under the user's existing GitLab permissions, so access follows what each person is already allowed to do.

New tools for code, pipelines and orientation

On top of the tools announced in 19.4, the server now covers more of the workflow:

• Code: add_branch starts a feature branch, get_repository_file reads a file at any ref, and semantic_search finds code by meaning, so an agent can answer "where is this implemented?" without knowing the file or symbol name.
• Pipelines: get_pipeline shows why a pipeline is red, with jobs, downstream pipelines and artifacts on request. list_pipelines surfaces patterns across recent runs, and get_artifact_file reads a single file from a job's artifacts without downloading the whole archive.
• Orientation: list_groups lets an agent browse the group hierarchy instead of guessing at identifiers, and the opt-in list_wiki_pages surfaces runbooks and docs before it answers a how-to question.

GitLab 19.5 also simplifies the tool catalog by consolidating related tools. get_merge_request can return a merge request's commits, diffs, pipelines, conflicts or notes, and get_pipeline now includes get_pipeline_jobs. The company says agents spend less time choosing the right tool and pull in only the details a task needs.

Toolsets let teams choose which groups of tools the server returns. A smaller set makes it less likely that an agent picks the wrong tool and has to retry. Most groups are on by default, while code security and wikis are opt-in.

Starting Duo Agent Platform flows from the client

An agent can now also hand a job to GitLab Duo Agent Platform and follow it to the result without leaving the client. It can find a project's flows with list_duo_agents_and_flows, start a flow from a plain-language goal with start_duo_session, and check progress with get_duo_session and list_duo_sessions.

The work runs in a CI job inside GitLab, under the same context layer, policy checks and audit trail as any other Duo Agent Platform session. When a session needs a decision, it pauses for input. With send_duo_session_input, a user can approve or reject the proposed action, or answer the agent's question. GitLab's example shows Claude Code starting the Fix Pipeline flow this way. The duo_agent_platform toolset is included by default.

Availability and what it means for teams

The MCP server is available on the Free, Premium and Ultimate tiers, on GitLab.com, GitLab Self-Managed and GitLab Dedicated. On GitLab.com, per-user rate limits are 60 calls per minute on Free and 600 on Premium and Ultimate.

GitLab's documentation includes setup instructions for Claude Code, Claude Desktop, Cursor, GitHub Copilot, OpenAI Codex, Gemini, Kiro, Zed and other MCP-compatible clients. For teams, this means they can connect the agents they already use rather than adopting a single tool, while permissions, policy checks and audit trails stay in GitLab. Teams new to Duo Agent Platform can start a free trial, and those on Premium or Ultimate can use the GitLab Credits included with their subscription.