The GitLab MCP server that checks IDs at the door

What it does

It bridges AI clients like Claude, Cursor, and Copilot to GitLab through the Model Context Protocol, letting them browse repositories, manage merge requests, file issues, and trigger pipelines. The server speaks stdio for local editors, SSE for legacy clients, and Streamable HTTP for remote deployments. It also handles custom GitLab instances and can switch API endpoints dynamically based on per-request headers.

The interesting bit

Rather than assuming one token fits all, it offers a full menu of authentication: personal access tokens, local browser OAuth, a remote OAuth proxy for MCP clients, and per-request remote authorization where callers supply their own tokens in HTTP headers. There is even a callback proxy mode so GitLab admins only need to register a single redirect URI instead of every client under the sun.

Key highlights

• Broad GitLab coverage: projects, repository browsing, merge requests, issues, pipelines, wiki, releases, tags, labels, milestones, and more
• Four auth modes: PAT, local OAuth2, MCP OAuth proxy, and per-request remote authorization via Private-Token or Authorization: Bearer headers
• Self-hosted ready with dynamic API URL routing, connection pooling, and proxy support
• Stateless mode available for multi-pod deployments behind horizontal pod autoscaling
• Granular controls: read-only mode and optional toggles for wiki, milestone, and pipeline APIs

Caveats

• Remote authorization requires Streamable HTTP and is explicitly incompatible with SSE transport
• OAuth proxy mode needs a publicly accessible HTTPS URL and a pre-registered GitLab OAuth application, so local testing requires a tunnel
• The setup surface is large; choosing between PAT, OAuth, proxy, or remote auth demands careful reading

Verdict

Grab it if you need AI assistants talking to self-hosted GitLab or running in shared, multi-user environments. Pass if you only want quick, personal gitlab.com access and prefer minimal configuration.