GitLab MCP Server
GitLab for your AI assistant: a Model Context Protocol server exposing GitLab REST API v4 and GraphQL operations as MCP tools. Projects, issues, merge requests, pipelines, CI/CD, wikis, releases, users, groups, search and more, against GitLab.com or any self-managed instance.
This package is a .NET tool whose entry point is the native gitlab-mcp-server binary (written in Go). It is a pointer package plus one package per runtime identifier, the layout the .NET 10 SDK uses for tools that ship a platform-specific executable: dotnet tool install and dnx resolve the package for your operating system and architecture and run the binary directly. No .NET runtime is involved once the server is running, nothing compiles, and nothing is downloaded at install time beyond the two packages.
Quick start
Run it directly with dnx (the .NET 10 SDK's tool runner):
GITLAB_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx dnx gitlab-mcp-server
Or install it on your PATH:
dotnet tool install -g gitlab-mcp-server
Either way the command is gitlab-mcp-server. Two things about dnx worth knowing: it reads its own options anywhere on the command line, so arguments meant for the server go after -- (dnx gitlab-mcp-server -- --version; without the separator, --version is read as dnx's own option and prints its usage); and the .NET 10 SDK's dnx installs the tool without asking when its standard input is not a terminal, which is how an MCP client starts it, so a client configuration needs no extra flag. A third: every dnx launch contacts NuGet.org, pinned (dnx gitlab-mcp-server@<version>) or not, cached or not: on a host that cannot reach NuGet.org, run the command dotnet tool install placed instead.
Typical MCP client configuration (stdio):
{
"mcpServers": {
"gitlab": {
"command": "dnx",
"args": ["gitlab-mcp-server"],
"env": {
"GITLAB_URL": "https://gitlab.com",
"GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx"
}
}
}
}
GITLAB_TOKEN is the only required setting. GITLAB_URL defaults to https://gitlab.com; point it at your own host for self-managed instances.
Verify what you run
The binary the SDK runs is the release asset byte for byte, so the build provenance attestation GitHub holds for it verifies it with the GitHub CLI: gh attestation verify ~/.nuget/packages/gitlab-mcp-server.<rid>/<version>/tools/any/<rid>/gitlab-mcp-server -R jmrplens/gitlab-mcp-server --signer-workflow jmrplens/gitlab-mcp-server/.github/workflows/release.yml for what dnx runs from the NuGet cache, and gh attestation verify "$(readlink -f "$(command -v gitlab-mcp-server)")" -R jmrplens/gitlab-mcp-server --signer-workflow jmrplens/gitlab-mcp-server/.github/workflows/release.yml after dotnet tool install -g on Linux and macOS, where the shim links into the tool store. --signer-workflow holds the attestation to the release workflow, since -R alone accepts one any workflow of the repository minted, and --source-ref refs/tags/v<version> holds it to one release. From the first release after 3.1.0 the packages themselves are attested as they were before NuGet.org added its repository signature: remove .signature.p7s from a downloaded copy with zip -d and run the same gh attestation verify on what is left. The steps are in the NuGet installation page.
Configuration
Everything is configured through environment variables: GITLAB_MCP_TOOL_SURFACE (dynamic, meta or individual tool catalogs), GITLAB_MCP_READ_ONLY, GITLAB_MCP_SAFE_MODE, GITLAB_MCP_TIER, rate limiting, telemetry and more. See the configuration guide for the full reference.
Platform support
Packages are published for linux-x64, linux-arm64, osx-x64, osx-arm64, win-x64 and win-arm64. The Linux binaries need glibc; on musl systems such as Alpine, use the container image ghcr.io/jmrplens/gitlab-mcp-server instead. Installing or running the tool needs the .NET 10 SDK or newer; the tool manifest format the runtime-specific packages use does not exist in older SDKs.
Links
License
MIT