Agentic tools are moving fast past code completion into running pipelines, opening merge requests, and triaging work on a team's behalf. The Model Context Protocol (MCP) has become the common way these agents reach into a team's existing tools, which means the agents touching an organization's software delivery pipeline are no longer only the ones a platform team chose and configured themselves.

That reach is also where automation typically stalls. The more an agent can do, the more a platform team has to think about what it should be allowed to do without asking first, and that's a governance problem that tends to get solved by restricting access rather than by extending it. Left unaddressed, it doesn't resolve on its own: Teams either lock agents down to a handful of safe, read-only actions, or they open things up and hope, neither of which scales.

GitLab's answer is to make wide tool access and consistent governance travel together. As platform engineers roll out agents across their organization, whether that's a GitLab flow or a third-party client connected through the GitLab MCP server, it needs the same reach into GitLab. But broader reach raises the stakes on control: a human should decide which actions an agent can take on its own and which need a reviewer, so routine, read-only lookups move fast while anything that writes, merges, or deletes waits for the reviewer that team chose.

GitLab Transcend returns in October

Coding agents are increasing your speed of development, but your reviews, security policies, and release cycles still have to keep pace. Our Transcend event on October 6 will demonstrate how GitLab is helping teams close that gap and explore what it takes to carry the speed of agentic AI across the software lifecycle.

Register for the livestream today!

Built for how platform teams scale automation

With GitLab 19.4, platform teams can automate more of the software lifecycle end to end: An agent can run a pipeline, open and update a merge request, or triage a vulnerability, not just look one up. Read-only actions run without a human in the loop by default, so agents move at the pace of the work. Anything that writes, merges, or deletes still waits for the reviewer a team chose, so widening what agents can touch doesn't widen what they can do unsupervised.

The GitLab MCP server's tool set grows substantially with this release, adding CI/CD, merge request, work item, vulnerability, and project tools.

See these MCP server tools in action:

GitLab is adding a substantial set of new MCP server tools, giving agents the coverage they need to complete real work end to end.

• CI/CD tools. save_pipeline runs, retries, cancels or renames a pipeline. get_job returns job by default; passing include: ["log"] adds the job trace, paginated via byte_offset and byte_limit (512 KB per page), so an agent can pull a failed build's log and diagnose the problem directly.
• Merge request tools. save_merge_request opens and updates an MR. get_merge_request can return diffs, conflicts, or approvals (one at a time via the include param), with diffs defaulting to stats-level detail unless you request detail: full_patch for the patch text. list_merge_requests works at group scope. save_merge_request_review covers the full review flow in one tool: posting a line-level or summary comment, replying in or resolving a discussion, submitting a full review, triggering a Duo review, and approving or unapproving. accept_merge_request merges an MR immediately by default, or waits for checks to pass when you pass strategy: merge_when_checks_pass (or adds it to a merge train with add_to_merge_train_when_checks_pass).
• Repository tools: list_repository_tree allows exploring the file tree. list_branches and list_tags enumerate refs and list_releases allows inspecting published releases. list_commits, get_commit, and add_commit allow for direct interaction with the repositories contents and history. fork_repository forks a project to allow an agent to do change without affecting the upstream repository.
• Project and user tools. get_project and list_projects find and read project details. list_project_members lists members and their roles. get_user looks up user details for assignment and mentions.
• Work item tools. get_work_item reads a single item in depth and covers what get_issue did, list_work_items searches across a group or project, and save_work_item creates or updates any supported work item type, covering what create_issue did. Issues and epics are themselves work item types. save_note comments on a work item or merge request and can reply inside an existing thread. It supersedes create_merge_request_note and create_workitem_note.
• Vulnerability tools (available on Ultimate). list_vulnerabilities lists vulnerabilities in a project, filterable by severity and report type, with cursor pagination. get_vulnerability returns full details for a single vulnerability by ID. save_vulnerability consolidates five write actions, dismiss, confirm, revert to detected, update severity, and create a linked issue, into a single tool.
• A new merge request trigger. GitLab 19.4 adds Created as a trigger action for merge requests: A flow or external agent can now run the moment someone opens a merge request, once GitLab generates the diff. Use it for a first-pass review, or to pull in context from related issues. Configure it under AI > Triggers in your project, or when you enable a flow.

Alongside the tool set, tool governance now extends to the GitLab MCP server, so every agent touching GitLab, whether internal or third-party, is governed from the same place with the same controls. Platform engineers now have one governance model that applies across a much wider set of agent capabilities.

GitLab MCP server tools appear next to internal GitLab Duo Agent Platform tools in the same group and project settings, with a mode you can set per tool:

• Read-only tools default to Always allow, so routine lookups run without interrupting the team.
• Write and delete tools default to Always ask, giving a reviewer a checkpoint before an agent changes anything.

Whether an agent is internal or connects through a third-party MCP client, it now runs under the same rules, easily configured in the same place.

Scale automation, one agent at a time

The expanded set of tools are currently available in beta. Together with governance, they mark a first step toward a platform where every agent, internal or third-party, runs under the same governed rules and reaches the same depth of GitLab context. As more tools and triggers ship, that governance model extends with them, so platform engineers configure guardrails once rather than for every new client.

Ready to try it? Start with the MCP server tools documentation and tool governance documentation.

The new MCP server tools and governance are available in beta on the Free, Premium, and Ultimate tiers, with the exception of the vulnerability tools, which require Ultimate. The Merge request created trigger requires Premium or Ultimate and GitLab Duo Agent Platform turned on. See the triggers documentation to configure it for your project.

Already on Premium or Ultimate and want the Merge request created trigger? Start by turning on Duo Agent Platform and use the GitLab Credits included with your subscription.