Gitlab MCP Server
The gitlab-mcp-server exposes the entire GitLab REST API v4 as MCP tools, resources, and prompts, enabling AI assistants to interact with GitLab using natural language.
Scale & Coverage
1006 individual MCP tools across 162 domain packages
42 meta-tools (57 with Enterprise) that group related operations to reduce LLM token overhead
24 read-only resources, 38 AI-optimized prompts, 11 sampling tools, and 4 elicitation wizards
Core GitLab Operations
Projects & Repositories: Create/read/update/delete projects; browse file trees, read/write/delete files, manage commits, diffs, branches, tags, cherry-pick, revert, compare, submodules
Merge Requests: Full lifecycle management including approvals, inline code review, draft notes, threaded discussions, rebase
Issues & Work Items: Full CRUD, linked issues, time tracking, notes, discussions, epics (GraphQL)
CI/CD: Manage pipelines, jobs, schedules, CI variables, runners, feature flags, job token scopes, CI catalog, lint CI config
Groups & Users: Manage groups, subgroups, members, labels, milestones; user lifecycle (block, ban, deactivate), SSH/GPG keys
Environments & Deployments: Full CRUD with approval/rejection workflows and protected environments
Packages & Registry: Package registry, container registry, protection rules, snippets, wikis
Administration: Instance settings, Sidekiq, OAuth apps, broadcast messages, system hooks, search across global/group/project scope
Access & Security: Deploy keys/tokens, project/group/personal access tokens, runner management
AI-Powered Analysis (Sampling Tools)
Code review of MR diffs, security review (OWASP Top 10), pipeline failure root cause analysis, issue scope assessment, CI config review, deployment history analysis, technical debt detection (TODO/FIXME/HACK), release notes generation, milestone reports
Interactive Wizards (Elicitation Tools)
Step-by-step guided creation of issues, merge requests, releases, and projects
Deployment & Security
Supports stdio and HTTP (Streamable HTTP) transports
Cross-platform: Windows, Linux, macOS (amd64 & arm64), Docker
Self-hosted GitLab support with custom TLS certificates
Read-only mode, safe mode (dry-run preview), automatic pagination and rate-limit retry
Continuous security monitoring via SonarCloud
Compatible with VS Code + Copilot, Claude Desktop, Claude Code, Cursor, Windsurf, JetBrains, Zed, Kiro, and other MCP clients
Compatible with Windsurf (Codeium's editor), enabling GitLab operations through the MCP server within the AI-assisted development environment.
Supports integration with VS Code through GitHub Copilot, allowing AI-assisted GitLab operations directly within the development environment via MCP server configuration.
Provides comprehensive GitLab REST API v4 coverage with 1006 tools across 162 domain sub-packages, enabling AI assistants to manage projects, branches, tags, releases, merge requests, issues, pipelines, jobs, groups, users, wikis, environments, deployments, packages, container registry, runners, and more through natural language commands.
Supports integration with JetBrains IDEs through the AI Assistant MCP configuration, allowing GitLab operations within IntelliJ-based development environments.
GitLab MCP Server
Connect your AI assistant to GitLab so it can review merge requests, triage pipelines, manage issues, and draft releases — in plain language. One static binary (or a container), 1000+ GitLab tools over the full REST + GraphQL API, working with Claude, Cursor, VS Code, and any MCP client.
You talk to your AI assistant; it does the GitLab work. No project IDs, API endpoints, or JSON to remember.
10,336 tokens of startup context by default, the same on every GitLab tier (1,671 with GITLAB_MCP_CAPABILITY_SURFACE=minimal). Two tools reach the whole catalog; measured with the cl100k_base tokenizer and verified in CI on every commit. How it is measured
"Review merge request !15 — is it safe to merge?" · "Why did the last pipeline fail?" · "List open issues assigned to me" · "Generate release notes from v1.0 to v2.0"
🤖 Using an AI assistant? Give it this repository URL and ask it to install the server for your client. Everything a model needs to do it headlessly — the declarative per-client config,
claude mcp addone-liners, and defaults — is inllms.txt(no interactive wizard required).
Install in 60 seconds
Pick one. Each path ends with you typing a prompt to your assistant. Every channel has a full guide: Installation.
Want to look before installing? The browser inspector signs in with OAuth and calls the hosted endpoint read-only from a browser tab — nothing downloaded. Running it yourself is still the way to keep using it.
One-click install
Each button registers the Docker-based server (auto-pulls the image on first run; you need Docker installed). The Claude Desktop row instead downloads a native .mcpb desktop extension (macOS universal + Windows, no Docker) — open it with Claude Desktop and fill in the settings. Need a token? Create a Personal Access Token with the api scope. Self-managed GitLab? Add a GITLAB_URL env var in your client's MCP config after install.
Claude Code (claude mcp add)
Docker (no install — pulls the image on first run):
claude mcp add gitlab --env GITLAB_TOKEN=glpat-xxxx --transport stdio \
-- docker run -i --rm -e GITLAB_TOKEN ghcr.io/jmrplens/gitlab-mcp-server:latestOr install the native binary first, then register it:
# Any platform (npm/pnpm) — downloads only your platform's prebuilt binary
npx -y @jmrp.io/gitlab-mcp-server # zero install; clients launch it directly
npm install -g @jmrp.io/gitlab-mcp-server # or install globally (npm)
pnpm add -g @jmrp.io/gitlab-mcp-server # or globally (pnpm)
# Any platform (Python: uv/pipx/pip) — platform wheel carrying the same native binary
uvx jmrplens-gitlab-mcp-server # zero install; clients launch it directly
pipx install jmrplens-gitlab-mcp-server # or install globally (pipx)
pip install jmrplens-gitlab-mcp-server # or into the active environment (pip)
# Linux wheels need glibc; on musl systems such as Alpine use the Docker image instead
# Any platform (.NET 10 SDK) — a .NET tool whose entry point is the same native binary
dnx gitlab-mcp-server # zero install; clients launch it directly
dotnet tool install -g gitlab-mcp-server # or install globally (dotnet tool)
# macOS/Linux (Homebrew)
brew install jmrplens/tap/gitlab-mcp-server
# Linux/macOS (script)
curl -fsSL https://raw.githubusercontent.com/jmrplens/gitlab-mcp-server/main/scripts/install.sh | sh
# Windows (winget)
winget install --id jmrplens.gitlab-mcp-server -e
# Windows (PowerShell)
irm https://raw.githubusercontent.com/jmrplens/gitlab-mcp-server/main/scripts/install.ps1 | iex
claude mcp add gitlab --env GITLAB_TOKEN=glpat-xxxx -- gitlab-mcp-serverClients that launch servers with npx, uvx or dnx need no install at all — point them at
npx -y @jmrp.io/gitlab-mcp-server, uvx jmrplens-gitlab-mcp-server or dnx gitlab-mcp-server.
Self-managed GitLab? Add --env GITLAB_URL=https://gitlab.example.com (and, for a self-signed certificate, mount the CA and set --env SSL_CERT_FILE=/path/to/ca-bundle.crt; GITLAB_MCP_SKIP_TLS_VERIFY=true is the blunt alternative, and OAuth mode refuses it for a non-loopback instance).
Run it once to check the install
Started in a terminal, or double-clicked on Windows, with no GITLAB_TOKEN set,
the binary prints what it is and what it needs and waits for Enter, so you can
confirm the install before configuring anything. Configuration itself lives in
your MCP client's JSON, below.
Manual JSON (Claude Desktop, Cursor, VS Code, …)
Native binary (Claude Desktop mcpServers, Cursor, etc.):
{
"mcpServers": {
"gitlab": {
"command": "/path/to/gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}VS Code (.vscode/mcp.json, note servers + type):
{
"servers": {
"gitlab": {
"type": "stdio",
"command": "/path/to/gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}Docker variant — replace "command"/"args" with:
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITLAB_TOKEN", "ghcr.io/jmrplens/gitlab-mcp-server:latest"]Cline (VS Code) — open the Cline sidebar → MCP servers icon → Edit Global MCP, or edit the settings file directly:
macOS:
~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.jsonLinux:
~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.jsonWindows:
%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
Cline uses the mcpServers shape shown above for the native binary.
For a shared, long-running HTTP deployment instead of per-user stdio, see HTTP Server Mode.
Try it without installing anything (hosted endpoint)
A public instance runs at https://mcp.jmrp.io/gitlab — nothing to install, no account beyond your own GitLab token. Point any HTTP-capable MCP client at it:
{
"mcpServers": {
"gitlab": {
"type": "http",
"url": "https://mcp.jmrp.io/gitlab",
"headers": { "Authorization": "Bearer glpat-xxxxxxxxxxxx" }
}
}
}The endpoint runs in OAuth mode, so the credential travels as Authorization: Bearer — a GitLab personal access token works there, verified exactly like an OAuth one, which is what keeps clients with no OAuth flow (and headless use) working. It travels per request and is never stored on the server. A client that speaks the OAuth flow needs no header at all: the 401 carries an RFC 9728 challenge it follows to authorize in the browser. PRIVATE-TOKEN is the legacy-mode header and is not accepted here; the instance is fixed to https://gitlab.com, so GITLAB-URL is ignored.
A read_api token is accepted and served a read-only tool surface — the write check is per action, so a credential that cannot break anything is a supported way to use the endpoint rather than a rejected one.
Two pages make it easier still. The server card lists the whole catalog with no credential at all and carries copy-paste config for Claude Code, Cursor and VS Code — including the OAuth client ID those clients need. The browser inspector calls the same endpoint read-only from a browser tab: sign in with OAuth, pick a tool, read the raw JSON-RPC it returns — nothing installed.
It is the fastest way to try the server, and the right way to keep using it is still locally (any option above) — for one concrete reason, not as a disclaimer: your token and every request pass through someone else's machine. Running it locally means your credentials and your GitLab traffic never leave your computer, which also makes it the only sensible option for a private self-managed instance.
The endpoint is stateless streamable HTTP on the default dynamic surface: POST is the transport and an authenticated GET answers 405 by design; with no credential, any method answers 401 carrying the RFC 6750 challenge an OAuth client follows — a bare curl that gets 401 is the endpoint working, not failing. https://mcp.jmrp.io/gitlab/health needs no credential and answers 200 with {"status":"ok",…}. A self-hosted HTTP deployment can also run --auth-mode=oauth --gitlab-url=https://gitlab.com --public-url=https://mcp.example.com/mcp (both are required: OAuth needs a fixed instance, and --public-url is the RFC 9728 resource identifier — pass exactly the URL your clients are configured with, since a client discards metadata naming a different one), where clients discover GitLab as the authorization server through that metadata and authorize in the browser instead of copying tokens — see OAuth App Setup. It is one of the servers listed at mcp.jmrp.io, a directory of the MCP servers I maintain, each reachable at its own endpoint; https://mcp.jmrp.io/servers.json is the same list for automated clients.
It is a personal service, run by one person and offered as-is: no SLA, no support channel, and no promise it is unchanged next week. It adds no quota of its own — every call spends GitLab.com's own limits, under your own token. And it moves on its own, normally to the newest release, so what it serves is never a pinned version.
Then just ask: open your AI client and try "List my GitLab projects." See the Getting Started guide for per-client details and more example prompts.
Related MCP server: GitLab MCP Server
Why this server
Plain-language GitLab. The AI translates "is MR !15 safe to merge?" into the right API calls. You don't touch endpoints, IDs, or JSON.
The whole platform — 1000+ tools. Broad GitLab REST v4 + GraphQL coverage: projects, branches, tags, releases, merge requests, issues, pipelines, jobs, groups, users, wikis, environments, deployments, packages, container registry, runners, feature flags, CI/CD variables, security, admin, tokens, and more.
Low-token by default. The default dynamic surface exposes just 2 tools (
find+execute) while reaching the full catalog — so it fits any client's context window. (Token footprint →)Proven with real models. An automated evaluator runs Anthropic, Google, OpenAI, and Qwen against live GitLab instances: 99.5% aggregate success across thousands of operations. (Results →)
Safe by design. Read-only mode, safe mode (dry-run preview of every mutation), TLS options for self-hosted GitLab, and continuous SonarCloud quality/security gates.
Runs anywhere. One static binary or container; Windows, Linux & macOS; amd64 & arm64; stdio (desktop) and HTTP (remote).
45 MCP resources (read-only data: projects, issues, pipelines, MRs, branches, members, the surface-aware
gitlab://toolsmanifest, and workflow best-practice guides). 26 resource kinds, single objects plus three single-parent lists, are also subscribable.37 MCP prompts (code review, pipeline status, risk assessment, release notes, standup, analytics, audit, and more).
4 elicitation wizards (interactive issue/MR/release/project creation).
4 MCP capabilities (completions, progress, elicitation, and resource subscriptions — live
resources/updatednotifications, honored by polling) and 51 tool icons (50 domain icons plus the project mark) for visual identification in MCP clients.Pagination on every list endpoint with full metadata.
Tool surfaces
The server can present GitLab in three shapes, controlled by GITLAB_MCP_TOOL_SURFACE. The default needs no configuration.
Surface | Visible tools | Best for |
Dynamic (default) | 2 ( | Lowest token cost; reaches the full catalog via find/execute. |
Meta-tools ( | 32 base / 49 Ultimate / 50 GitLab.com Ultimate | Domain-grouped dispatchers with an |
Individual ( | ~854 Free/CE · ~1007 Premium · 1073–1079 Ultimate | One MCP tool per GitLab operation; needs a large context window. |
Tool counts scale with your GitLab edition (GITLAB_MCP_TIER); higher tiers expose more actions. See Dynamic Toolset and Meta-Tools Reference for the ranking model, safety guards, and full catalogs. For dynamic runs where resources dominate context, set GITLAB_MCP_CAPABILITY_SURFACE=minimal.
Token Footprint
Measured with go run ./cmd/audit_tokens/ -footprint against the current catalog. Totals estimate startup context visible to an MCP client: visible tool schemas plus shared resources and prompts, using the cl100k_base tokenizer (GPT-4/GPT-3.5 encoding). For the full matrix (meta and individual surfaces, all GITLAB_MCP_META_PARAM_SCHEMA modes), see Token Footprint Reference.
Default configuration: with GITLAB_MCP_TOOL_SURFACE unset or GITLAB_MCP_TOOL_SURFACE=dynamic, GITLAB_MCP_CAPABILITY_SURFACE=full, GITLAB_MCP_META_TOOLS unset, GITLAB_MCP_META_PARAM_SCHEMA=opaque, and GITLAB_MCP_TIER unset (detected, fallback free), the server uses the dynamic find/execute surface. Use GITLAB_MCP_TOOL_SURFACE=meta only when you explicitly want domain meta-tools; use GITLAB_MCP_TOOL_SURFACE=individual only when your client can handle the full tool catalog.
Configuration ( | Tier | Visible tools | Reachable actions |
| Tool schema tokens | Shared tokens | Total tokens |
| Free/CE | 2 | 858 | n/a | 1,501 | 8,835 | 10,336 |
| Free/CE | 2 | 858 | n/a | 1,501 | 170 | 1,671 |
| Premium | 2 | 1,011 | n/a | 1,501 | 8,835 | 10,336 |
| Premium | 2 | 1,011 | n/a | 1,501 | 170 | 1,671 |
| Ultimate | 2 | 1,077 | n/a | 1,501 | 8,835 | 10,336 |
| Ultimate | 2 | 1,077 | n/a | 1,501 | 170 | 1,671 |
Rows use the base Community Edition catalog unless the Tier column says otherwise. GITLAB_MCP_TIER controls which actions are available; higher tiers expose more tools and thus more reachable actions.
Compatibility
MCP Capability | Support |
Tools | Up to 1079 individual / 32–50 meta |
Resources | 45 (static + templates) |
Prompts | 37 templates |
Completions | 18 argument names, among them projects, groups, users, branches, tags, MRs, issues, pipelines, jobs, labels, milestones and SHAs |
Server logs | Structured (text/JSON) to stderr — not the MCP |
Progress | Tool execution progress reporting |
Elicitation | 4 interactive creation wizards |
Subscriptions |
|
Tested with: VS Code + GitHub Copilot, Claude Desktop, Claude Code, Cursor, Windsurf, JetBrains IDEs, Zed, Kiro, Cline. See the full Compatibility Matrix.
AI Model Tool-Use Evaluation
The project includes an automated evaluator for model-facing MCP quality. It runs schema-only checks against the tool catalog or executes validated model tool calls through MCP against Docker GitLab CE or licensed Enterprise instances populated with fixtures. It measures whether each model chooses the correct action, sends valid parameters, recovers from actionable GitLab errors, and respects destructive-action safeguards — across Anthropic, Google, OpenAI, and Qwen.
Current published result: Docker CE dynamic 20260627-232303.
Provider | Model | Compatibility | Tool accuracy | Recovery | Docker live status |
Anthropic |
| OK | 100.0% | 100.0% (2/2) | 100.0% final across 555 ops |
| OK | 100.0% | 100.0% (4/4) | 100.0% final across 555 ops | |
OpenAI |
| Review | 99.3% | 84.6% (11/13) | 98.0% final across 555 ops |
Qwen |
| OK | 100.0% | 100.0% (5/5) | 100.0% final across 555 ops |
The published model-evaluation set covers 596 task attempts and 2220 expected MCP operations. Across the selected reports, models emitted 2265 tool calls over 2265 model requests, with 99.5% aggregate final success. See AI Model Evaluation Results for the detailed current matrix.
No CE meta-tools run has been published yet: make eval-surfaces-docker SURFACE=meta followed by --publish-docs fills this block.
Current published result: Docker Enterprise meta 20260527.
Provider | Model | Compatibility | Tool accuracy | Recovery | Docker live status |
Anthropic |
| OK | 100.0% | 100.0% (1/1) | 100.0% final across 84 ops |
| Review | 78.2% | 100.0% (7/7) | 100.0% final across 84 ops | |
OpenAI |
| Review | 100.0% | 100.0% (4/4) | 100.0% final across 84 ops |
Qwen |
| OK | 100.0% | 100.0% (1/1) | 100.0% final across 84 ops |
The published model-evaluation set covers 92 task attempts and 336 expected MCP operations. Across the selected reports, models emitted 345 tool calls over 350 model requests, with 100.0% aggregate final success. See AI Model Evaluation Results for the detailed current matrix.
Current published result: Docker Enterprise dynamic 20260628-015421.
Provider | Model | Compatibility | Tool accuracy | Recovery | Docker live status |
Anthropic |
| OK | 100.0% | 100.0% (1/1) | 100.0% final across 202 ops |
| OK | 100.0% | 100.0% (2/2) | 100.0% final across 202 ops | |
OpenAI |
| OK | 100.0% | No repairs | 100.0% final across 202 ops |
Qwen |
| OK | 100.0% | 100.0% (1/1) | 100.0% final across 202 ops |
The published model-evaluation set covers 124 task attempts and 808 expected MCP operations. Across the selected reports, models emitted 817 tool calls over 817 model requests, with 100.0% aggregate final success. See AI Model Evaluation Results for the detailed current matrix.
Documentation
Full documentation is at jmrp.io/docs/gitlab-mcp-server. Use this map for the source-of-truth reference on a specific area:
Document | Description |
Install paths, first query, per-client configuration | |
Every install channel (binary, Homebrew, winget, Docker, npm, PyPI, NuGet, | |
Per-client stdio, HTTP legacy, and HTTP OAuth examples | |
Environment variables, transport modes, TLS | |
Exhaustive environment variable table with defaults and examples | |
All command-line flags, exit codes, and runtime examples | |
Shared HTTP deployments, authentication, server pool isolation | |
GitLab OAuth application, scopes, redirect URIs, and which clients can complete a flow | |
Running the server inside GitLab CI and GitHub Actions pipelines | |
The response contract every tool follows: content blocks, pagination, next steps | |
Error classification, GitLab message extraction, and the hints tools return | |
All individual tools with input/output schemas, including GitLab.com-only Orbit | |
32/49/50 domain meta-tools with action dispatching | |
2-tool low-token mode with canonical action catalog, safety model, and examples | |
All 45 resources with URI templates | |
All 37 prompts with arguments and output format | |
Unit, E2E, schema model evaluation, Docker model evaluation, and curated model results | |
Security model, token scopes, input validation | |
System architecture, component design, data flow | |
Building, testing, CI/CD, contributing | |
Common startup, token, TLS, transport, and tool-discovery issues |
FAQ
Yes. Set GITLAB_URL to your instance URL. When GITLAB_URL is omitted, stdio mode uses https://gitlab.com. Self-signed TLS certificates are supported by installing the CA in the system trust store or pointing SSL_CERT_FILE at a bundle; GITLAB_MCP_SKIP_TLS_VERIFY=true skips verification instead, and --auth-mode=oauth refuses it for a non-loopback instance.
When you run it yourself, locally over stdio or on your own infrastructure over HTTP, every request goes to your GitLab instance and nowhere else. There is no update check, no license check and no telemetry: your instance is the only host this server contacts.
The exception is the hosted endpoint: using https://mcp.jmrp.io/gitlab means your token and every request pass through that machine. Nothing is stored there, but it is someone else's server, which is why the hosted section says to keep using it locally.
See PRIVACY.md for the full data-flow statement, and SECURITY.md for the security model.
Yes. Set GITLAB_MCP_READ_ONLY=true to disable all mutating tools (create, update, delete). Only read operations will be available.
Alternatively, set GITLAB_MCP_SAFE_MODE=true for a dry-run mode: mutating tools remain visible but return a structured JSON preview instead of executing. Useful for auditing, training, or reviewing what an AI assistant would do.
Both Community Edition (CE) and Enterprise Edition (EE). Set GITLAB_MCP_TIER=premium or GITLAB_MCP_TIER=ultimate in stdio mode to enable additional tools for Premium/Ultimate features (DORA metrics, vulnerabilities, compliance, etc.); leave it unset to detect the tier from the instance license (fallback free). In HTTP mode, --tier can force the tier, otherwise it is detected per token+URL pool entry from the license.
The server includes retry logic with backoff for GitLab API rate limits. Errors are classified as transient (retryable) or permanent, with actionable hints in error messages.
Any MCP-compatible client: VS Code + GitHub Copilot, Claude Desktop, Cursor, Claude Code, Windsurf, JetBrains IDEs, Zed, Kiro, and others. Each one's configuration snippet is in Getting Started, and the one-click buttons above cover the most common ones.
Building from Source
git clone https://github.com/jmrplens/gitlab-mcp-server.git
cd gitlab-mcp-server
make buildThe published container image is ghcr.io/jmrplens/gitlab-mcp-server:latest. See the Development Guide for cross-compilation, Docker Compose, and contributing guidelines.
Component | Technology |
Language | Go 1.27+ |
MCP SDK |
|
GitLab Client |
|
Transport | stdio (default), HTTP (Streamable HTTP) |
Privacy Policy
The server runs entirely on your machine and has no telemetry, analytics, or backend of its own — data flows only between your MCP client and the GitLab instance you configure (plus an optional signed-binary update check against GitHub Releases). Your token is used solely to authenticate GitLab requests and is never logged. Full details: PRIVACY.md.
Contributing & Security
Contributing: see CONTRIBUTING.md for development guidelines, branch naming, commit conventions, and the PR process.
Security: see SECURITY.md for the security policy and vulnerability reporting.
Code of Conduct: see CODE_OF_CONDUCT.md (Contributor Covenant v2.1).
Repository mirror: GitHub is the canonical repository. A read-only mirror is available on GitLab.com for discoverability; please open contributions on GitHub.
File counts
Category | Files | Lines |
Source ( | 1,143 | 231,411 |
Unit tests ( | 649 | 378,603 |
End-to-end tests | 235 | 61,898 |
Total | 2,027 | 671,912 |
Functions
Category | Count |
Source functions | 8,637 |
. Exported (public) | 2,817 |
. Unexported (private) | 5,820 |
Unit test functions ( | 13,375 |
Subtests ( | 5,089 |
End-to-end test functions | 582 |
Ratios worth noting
Observation | Value |
Test lines vs source lines | 1.64× more tests than code |
Average source file length | ~202 lines |
Average test file length | ~583 lines |
Comment lines in source | 35,972 (~15.5% of source) |
Test functions per source function | 1.5× |
Code patterns
Pattern | Count |
| 7,271 |
| 1,246 |
| 2,918 |
| 297 |
| 2 |
Project
Metric | Value |
Go packages | 253 |
Direct dependencies ( | 31 |
Indirect dependencies | 38 |
Hall of fame
Record | File |
Longest source file |
|
Longest test file |
|
Because why not
Fact | Value |
Source code printed at 55 lines/page | ~4,207 pages of A4 |
Source lines mentioning | 13,556 (impossible to avoid) |
Longest function name in source |
|
Longest test function name |
|
Maintained by José M. Requena Plens · Project page · Hosted instance: mcp.jmrp.io/gitlab
Available Tools
2 toolsgitlab_execute_actionGitLab Execute ActionADestructiveInspect
Execute one GitLab catalog action by canonical ID or alias. Always pass params as an object; destructive actions require top-level confirm=true. Use find first only when action or params are unclear.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Canonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close. | |
| params | Yes | Required action-specific parameters object validated by the selected action schema. Use an empty object for actions with no parameters. | |
| confirm | No | Set top-level confirm=true to explicitly approve destructive actions; do not put confirm inside params for gitlab_execute_action. |
Output Schema
| Name | Required | Description |
|---|---|---|
| next_steps | No | Optional. Suggested follow-up actions or tool calls for the LLM, contextual to the result. |
| pagination | No | Present on list actions. Use `has_more` and `next_page` to paginate through results. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds meaningful behavioral context beyond those hints by specifying that destructive actions require top-level confirm=true, which is essential for safe invocation of this dynamic executor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no wasted words. It front-loads the core purpose, follows with the most critical invocation constraints, and ends with a clear routing instruction for the sibling tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the annotations cover read-only, idempotency, and destructive behavior, the description provides the remaining key context: how to invoke the action, when confirmation is required, and when to defer to gitlab_find_action. Nothing essential is missing for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters well. The description reinforces the top-level confirm rule and the object-shaped params requirement, but it mostly restates what the schema already provides, so the added semantic value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Execute one GitLab catalog action by canonical ID or alias.' This clearly identifies what the tool does and distinguishes it from the sibling tool gitlab_find_action, which is about discovery rather than execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage routing: 'Use find first only when action or params are unclear.' It also provides concrete invocation guidance, such as always passing params as an object and using top-level confirm=true for destructive actions, which helps the agent call it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gitlab_find_actionGitLab Find ActionARead-onlyIdempotentInspect
Search the local GitLab action catalog; read-only and no GitLab API call. Use when the action ID or params are unclear; returns schemas, hints, destructive flags, and execute examples.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matches to return. Defaults to 20 and is capped at 50. | |
| query | Yes | Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable. | |
| explain | No | When true, include deterministic scoring reasons for each returned action. Defaults to false to keep responses compact. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of returned matches. |
| query | Yes | Original search query. |
| results | Yes | Matching GitLab catalog actions with schemas and execute examples. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond annotations: it searches a local catalog rather than making an external GitLab API call, and it returns schemas, hints, destructive flags, and execute examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences. The primary purpose and key behavioral distinction are front-loaded, followed by the intended use case and return contents. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with fully documented parameters, strong annotations, and an output schema, the description covers the essential use case, behavior, and return value expectations. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description reinforces that the query is a search against the local catalog but does not need to add further parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Search the local GitLab action catalog.' It is clearly distinguished from the sibling execution tool by noting it performs no GitLab API call and is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when 'the action ID or params are unclear,' giving a clear trigger condition. It does not name the sibling alternative directly, but the read-only/no-API-call contrast with gitlab_execute_action makes the intended usage evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v2.7.5- Changed
gitlab_execute_action1 field changed- changed
Input schema / properties / action / x-mcp-headerPrevious value: -"Mcp-Param-Action"New value: +"Action"
1 tool update
v2.6.0- Added
gitlab_execute_action
1 tool update
v2.5.2- Removed
gitlab_execute_action
3 tool updates
v2.1.3- Added
gitlab_execute_action - Removed
gitlab_execute_tool - Changed
gitlab_find_action4 fields changed- changed
Output schema / properties / results / items / properties / example / descriptionPrevious value: -"Example gitlab_execute_tool call."New value: +"Example gitlab_execute_action call." - changed
Output schema / properties / results / items / properties / example / properties / arguments / descriptionPrevious value: -"Example arguments for gitlab_execute_tool."New value: +"Example arguments for gitlab_execute_action." - changed
Output schema / properties / results / items / properties / id / descriptionPrevious value: -"Canonical action ID to pass to gitlab_execute_tool."New value: +"Canonical action ID to pass to gitlab_execute_action." - changed
Output schema / properties / results / items / properties / required_params / descriptionPrevious value: -"Required parameter names captured from the input schema."New value: +"Required action-specific parameter names to place inside gitlab_execute_action params."
2 tool updates
v2.0.2- Changed
gitlab_execute_tool3 fields changed- changed
Input schema / properties / action / descriptionPrevious value: -"Canonical action ID returned by gitlab_find_action, such as project.list."New value: +"Canonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close." - changed
Input schema / properties / confirm / descriptionPrevious value: -"Set true to explicitly confirm destructive actions."New value: +"Set top-level confirm=true to explicitly approve destructive actions; do not put confirm inside params for gitlab_execute_tool." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Result envelope. Top-level shape varies per action and matches the chosen action's typed output. Includes optional cross-cutting fields documented below.", + "properties": { + "next_steps": { + "description": "Optional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.", + "items": { + "type": "string" + }, + "type": "array" + }, + "pagination": { + "additionalProperties": true, + "description": "Present on list actions. Use `has_more` and `next_page` to paginate through results.", + "properties": { + "has_more": { + "description": "True when more pages are available after the current one.", + "type": "boolean" + }, + "next_page": { + "description": "Next page index when `has_more` is true.", + "type": "integer" + }, + "page": { + "description": "Current 1-based page index.", + "type": "integer" + }, + "per_page": { + "description": "Items per page.", + "type": "integer" + }, + "prev_page": { + "description": "Previous page index when applicable.", + "type": "integer" + }, + "total": { + "description": "Total item count when known (some endpoints omit it for performance).", + "type": "integer" + }, + "total_pages": { + "description": "Total page count when known.", + "type": "integer" + } + }, + "type": "object" + } + }, + "type": "object" +}
- Changed
gitlab_find_action1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"Search terms for GitLab actions, such as project create, merge request approve, pipeline retry, or ci variable."New value: +"Search terms combining a GitLab domain or resource with a verb, filter, or object name, such as project create, merge request approve, pipeline retry, issue delete, or ci variable."
30 tool updates
v2.0.1- Removed
gitlab_access - Removed
gitlab_admin - Removed
gitlab_analyze - Removed
gitlab_branch - Removed
gitlab_ci_catalog - Removed
gitlab_ci_variable - Removed
gitlab_custom_emoji - Removed
gitlab_environment - Added
gitlab_execute_tool - Removed
gitlab_feature_flags - Added
gitlab_find_action - Removed
gitlab_group - Removed
gitlab_issue - Removed
gitlab_job - Removed
gitlab_merge_request - Removed
gitlab_model_registry - Removed
gitlab_mr_review - Removed
gitlab_package - Removed
gitlab_pipeline - Removed
gitlab_project - Removed
gitlab_release - Removed
gitlab_repository - Removed
gitlab_runner - Removed
gitlab_search - Removed
gitlab_server - Removed
gitlab_snippet - Removed
gitlab_tag - Removed
gitlab_template - Removed
gitlab_user - Removed
gitlab_wiki
TDQS
gitlab_execute_action and gitlab_find_action have clearly distinct responsibilities: one runs a catalog action, the other searches for catalog information. There is no functional overlap or ambiguity between them.
Both tools use the same gitlab_<verb>_action pattern in snake_case. The verb-noun structure is consistent and predictable.
Two tools is slightly below the typical 3-15 range, but the split between finding and executing actions is a reasonable minimal surface for a catalog-driven server. It feels compact rather than incomplete.
The pair forms a complete discover-and-execute workflow: find_action provides schemas and execution examples, and execute_action performs the requested catalog action. Since execution is generic, the tool surface itself has no dead ends.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
GitLab MCP — wraps the GitLab REST API v4 (BYO API key)
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Related MCP Servers
- AlicenseBqualityAmaintenanceFirst gitlab mcp for you, building together117123,8991,953MIT
- -licenseNot gradedqualityNot gradedmaintenanceA Model Context Protocol server that enables AI assistants to interact with GitLab repositories, allowing tasks like managing merge requests, searching projects, and creating comments through RESTful API integration.192-
- AlicenseBqualityCmaintenanceA Model Context Protocol (MCP) server for GitLab and Jira integration. This server allows AI agents like gemini-cli to interact with your GitLab and Jira instances.321811MIT
- AlicenseNot gradedqualityAmaintenanceFull-coverage GitLab MCP server with 44 tools across 18 resource types. Agent-optimized CQRS design — one tool call handles complete multi-step operations. Supports OAuth 2.1, read-only mode, stdio/SSE/StreamableHTTP transports, and GraphQL-native work items with full hierarchy (epics,issues,etc)1,9226Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jmrplens/gitlab-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server