What it takes off you is the click path through a merge request: the agent lists the changed files, pulls diffs for the ones that matter, leaves draft notes as it reads, publishes them in one pass with a reviewer state, and resolves the threads that got fixed. Issues, branches and CI lint sit behind the same token, and the permission mode decides how far it can go.
A wide GitLab server built around the review loop. Merge requests are the deepest part of it: diffs by file or by version, threads resolved, draft notes held back and published together, approvals and merges. It speaks stdio for local clients, SSE for older ones, and Streamable HTTP when you run it as a shared server.
- Merge requests listed, created, updated, approved, merged, and read with deployment, commit and approval summaries
- Diffs at every grain: the whole request, one file, one version, between two branches, and the changed-file list without any diff content — the two-step path for reviewing a large branch
- Review threads: notes created, edited and resolved, and draft notes written as you go then published in one pass with a reviewer state
- Issues created, updated, linked and deleted, with descriptions patched by search-replace or unified diff instead of a full rewrite
- Emoji reactions on merge requests, issues and their notes
- Repository work: files read and written, multi-file commits pushed, branches created, protected and unprotected, the default branch changed, and the tree listed
- Commits listed and read with stats and diffs, blame narrowed to a line range, and commit statuses created
- Projects, groups, namespaces, members and labels read and managed, plus to-do items and event history
- CI configuration validated as content or as the project's own file, and the CI/CD catalog browsed
- A write boundary you set once: GITLAB_PERMISSION_MODE=readonly for reads only, or modify to allow create and update while every delete tool stays out of the list
- Toolsets kept out of the way until wanted — pipelines, milestones, wiki, releases, tags, workitems, webhooks, search, variables and more switch on through GITLAB_TOOLSETS, or discover_tools activates a category mid-session
Npx on your PATH and a GitLab personal access token in GITLAB_PERSONAL_ACCESS_TOKEN, scoped api or read_api. GITLAB_API_URL points at the instance and defaults to https://gitlab.com/api/v4, so a self-managed GitLab means setting it. Inside GitLab CI, GITLAB_JOB_TOKEN can stand in for the personal token; GITLAB_USE_OAUTH=true swaps the token for a browser sign-in instead.
One command plus a key — npm install -g @zereight/mcp-gitlab, then supply credentials