GitLab shipped a set of MCP tools for platform teams in 19.4, and the framing is the governance question stated before the feature list: “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.” The answer is a default that splits on verb. Read-only tools — get_job, get_merge_request, list_merge_requests, list_commits, list_branches, get_work_item and the rest — ship as “Always allow,” so “read-only actions run without a human in the loop by default, so agents move at the pace of the work.” Anything that writes or deletes — save_pipeline, save_merge_request, save_merge_request_review, accept_merge_request, add_commit, fork_repository, save_vulnerability — ships as “Always ask.” The rule an operator inherits is the one they would have written anyway, and it arrives already applied.
The tools themselves are shaped by people who have watched agents fail at this. get_job returns a log only when asked for it, paginated by byte_offset and byte_limit at 512 KB a page, which is the difference between an agent reading a failure and an agent flooding its own context with one. accept_merge_request takes strategy: merge_when_checks_pass, so the agent can express “merge this when it is safe” rather than polling. And the sentence that matters for anyone running a third-party client is the last one: “whether an agent is internal or connects through a third-party MCP client, it now runs under the same rules.” Read that as a statement about where policy lives — in the server, not the client — and it is the right place. The caveats are stated: beta across Free, Premium and Ultimate, vulnerability tools on Ultimate only, and the merge-request-created trigger gated behind Premium with Duo Agent Platform on.
The catalog holds GitLab as one of the deepest records in the network, and every MCP tool in the announcement is a REST surface already indexed: the Pipelines API and Jobs API behind save_pipeline and get_job; the Merge Requests API behind the four merge-request tools; the Commits API, Branches API and Repositories API behind the repository tools; and the Vulnerabilities API behind the Ultimate-only set. The MCP layer adds no new capability. It adds a permission default over capabilities that already existed.
GitLab scores 72.0, exemplar on the Kin Score — access clarity 92.1, operational transparency 73.7 — one of the highest scores in the catalog. Agent Readiness is 49.3, agent-ready, on ten lit dimensions including mcp_server, error_semantics, event_surface_described, delegated_identity and protected_resource_metadata. The two dark ones are the two this release is quietly about. dry_run_mode is unlit — and “Always ask” is a human standing in for a dry run, which is a fine default and not the same as the API declaring which operations are safe to preview. And reversibility_documented is unlit, on a server whose accept_merge_request is the single least reversible thing an agent can do to a codebase. GitLab built the approval gate. The contract does not yet say which side of it each operation belongs on.