Installation

GitLab MCP Server is one self-contained Go binary. Every channel on this page delivers that same binary, or a container that wraps it, and the same gitlab-mcp-server command, so the choice is about what you already have on the machine and how you want upgrades to arrive, not about features. Whatever you pick, the server needs one value to run: a GitLab personal access token in GITLAB_TOKEN (api scope; a read_api token also works: the server detects it at startup and serves the actions GitLab accepts from it, on stdio as in HTTP mode and on the hosted endpoint). GITLAB_URL defaults to https://gitlab.com, so set it only for a self-managed instance.

Pick a channel

Channel	What you get	Needs	Upgrade path	Platforms
Native binary	The release binary, placed by an install script or by hand	Nothing (the script needs curl or wget; PowerShell on Windows)	Re-run the script, or download the newer release	Linux, macOS, Windows; amd64 and arm64
Homebrew	The release binary, installed by a formula from the jmrplens/tap tap	Homebrew	brew upgrade	macOS and Linux; Apple Silicon, Intel and arm64
Windows (winget)	The release executable as a portable package with a PATH alias	winget	winget upgrade	Windows; x64 and arm64
Docker	A container image on GHCR, mirrored on Docker Hub	Docker or a compatible runtime	Pull a newer tag and recreate the container	linux/amd64 and linux/arm64 images, wherever Docker runs
npm and npx	A launcher package plus one platform package carrying the binary	Node.js 18 or newer	npm update -g; npx -y resolves the newest version on a cold run	Linux (glibc), macOS, Windows; x64 and arm64
PyPI, uvx and pipx	A wheel that places the binary on the environment’s scripts path	Python 3.9 or newer (uv or pipx optional)	pipx upgrade, pip install -U or uv tool upgrade; uvx resolves the newest version on a cold run	Linux (glibc), macOS 11 or newer, Windows; x64 and arm64
NuGet and dnx	A .NET tool whose entry point is the binary, one package per runtime identifier	The .NET 10 SDK or newer	dotnet tool update -g; dnx resolves the newest version on every launch	Linux (glibc), macOS, Windows; x64 and arm64
Agent Plugins	A plugin manifest that runs the Docker image over stdio	A conformant host (Cursor, Claude Code, VS Code, OpenCode) and Docker	The image’s latest tag, pulled again	Wherever the host and Docker run
Claude Desktop (.mcpb)	A desktop extension per operating system: the macOS universal binary, the Windows executable, or the Linux x64 and arm64 binaries (from the first release after 3.1.0; up to 3.1.0, one universal bundle for all three)	Claude Desktop 0.10.0 or newer	A new extension version ships with every release	macOS (Apple Silicon and Intel), Windows (x64), Linux (glibc; x64 and arm64)
Hosted endpoint	Nothing installed: a public streamable HTTP endpoint	An HTTP-capable MCP client and a GitLab.com token	Moves on its own, normally to the newest release	Any

The server never updates itself

It never checks for updates and never replaces its own binary, on any channel. Upgrades come from whatever installed it: brew upgrade, winget upgrade, npm update, dotnet tool update, a newer image tag, a newer extension version, or a fresh download. An earlier self-update subsystem was removed: the package manager that installed the files is the one that owns them. gitlab-mcp-server --version prints gitlab-mcp-server <version> (commit: <commit>), so you can always see what you have; the current release is 3.2.0.

Which one?

• You want the smallest footprint and no runtime. The native binary. Homebrew and winget install that same binary and take care of upgrades.
• Your client already launches servers with npx, uvx or dnx. The npm, PyPI and NuGet packages: nothing to install ahead of time, and the client resolves the newest version on its own.
• You would rather not put anything on the host, or you are deploying for a team. Docker, over stdio for one client or in HTTP mode behind a port.
• You use Claude Desktop. The .mcpb extension: one click, and the token is encrypted with a key from the operating system’s credential store where one exists.
• You just want to look first. The hosted endpoint, from any HTTP-capable client or straight from the browser inspector.

Native binaryInstall script, PowerShell one-liner, or a download from GitHub Releases. Verify the checksum and signature.

Homebrewbrew install jmrplens/tap/gitlab-mcp-server on macOS or Linux; upgrades with brew upgrade.

Windows (winget)winget install --id jmrplens.gitlab-mcp-server -e, a portable package with a PATH alias.

Dockerghcr.io/jmrplens/gitlab-mcp-server over stdio for a desktop client, or as an HTTP service on a port.

npm and npxnpx -y @jmrp.io/gitlab-mcp-server, or a global install; only your platform's binary is downloaded.

PyPI, uvx and pipxuvx jmrplens-gitlab-mcp-server, pipx or pip; the wheel carries the native binary.

NuGet and dnxdnx gitlab-mcp-server or dotnet tool install; a .NET tool whose entry point is the native binary.

Agent Plugins/plugin install jmrplens/gitlab-mcp-server on Cursor, Claude Code, VS Code or OpenCode.

Claude Desktop (.mcpb)The one-click desktop extension for macOS, Windows and Linux (x64 and arm64).

Hosted endpointhttps://mcp.jmrp.io/gitlab: try the server with nothing installed, then run it locally.

After installing

Every channel ends at the same place: your MCP client launches gitlab-mcp-server (or the docker, npx, uvx or dnx command that wraps it) with GITLAB_TOKEN in its environment. Each channel page closes with the minimal client snippet for its command, and the Quick Start has the per-client tabs for VS Code, Claude Desktop, Cursor, Claude Code, Windsurf, JetBrains, Zed, Kiro, Cline and Codex. Every client’s entry over stdio, and over HTTP with a token or with OAuth, is on Client configuration.

Two things worth knowing before the first run:

• If you start the binary in a terminal, or double-click it on Windows, without both GITLAB_URL and GITLAB_TOKEN set, it prints what it is and the two values it needs, then waits for Enter. An MCP client never sees that screen, because it connects pipes rather than a terminal. There is no setup wizard.
• The token can stay out of client JSON entirely: an explicit environment variable wins over the file GITLAB_MCP_ENV_FILE names, which wins over ~/.gitlab-mcp-server.env (one KEY=value per line). A .env in the working directory is not read. See Configuration.

Then open your client and ask “Who am I on GitLab?”. On the default dynamic surface the assistant calls gitlab_find_action and then gitlab_execute_action with the user.current action, and answers with your GitLab profile.

How a release reaches every channel

The native binary, Homebrew, winget, npm, PyPI, NuGet and the Claude Desktop extension all carry the binary GoReleaser built for the release, byte for byte; the container image, and the Agent Plugins entry that runs it, carry a build of their own. The release workflow publishes them in an order that keeps a partial release out of sight:

1. The container image is built by its own job from the same tag, with its own copy of the binary (see Docker). Both platform variants are started and asked for their version before the image is pushed, and it is signed and attested before any other channel is published.
2. The GitHub release is created as a draft with the binaries, checksums.txt and its Cosign signature, the SBOMs and the Claude Desktop bundles, which are assembled in the same job from the same binaries. It is published only after every asset is attached and attested, so a release you can see is never a partial one.
3. npm, PyPI and NuGet are packed afterwards, each in a job of its own that downloads the published release assets and checks them against the signed checksums.txt before packing anything.
4. A read-back job then downloads what npm, PyPI and NuGet serve and compares the binaries inside the packages with the same signed checksums.txt; from the first release after 3.1.0 it also holds each NuGet package, with NuGet.org’s repository signature removed, to the digest the release attested for it.
5. Nothing that advertises the version runs before that comparison passes: the Homebrew tap, the MCP Registry entry, the manifest commit to main and the winget pull request all wait on it. A release whose npm, PyPI or NuGet publish failed leaves them on the previous version.

How to check a download yourself is on the Native binary page, and the background is under Verifying release integrity.