Gitlab MCP Server
GitLab MCP Server
Verbinde deinen KI-Assistenten mit GitLab, damit er Merge Requests prüfen, Pipelines auswerten, Issues verwalten und Releases entwerfen kann – in einfacher Sprache. Ein einziges statisches Binary (oder ein Container), 1000+ GitLab-Tools für die gesamte REST- und GraphQL-API, kompatibel mit Claude, Cursor, VS Code und jedem MCP-Client.
Du sprichst mit deinem KI-Assistenten; er erledigt die GitLab-Arbeit. Keine Projekt-IDs, API-Endpunkte oder JSON, die du dir merken musst.
„Prüfe Merge Request !15 – ist er sicher zu mergen?" · „Warum ist die letzte Pipeline fehlgeschlagen?" · „Liste offene Issues auf, die mir zugewiesen sind" · „Erstelle Release Notes von v1.0 bis v2.0"
🤖 Nutzt du einen KI-Assistenten? Gib ihm diese Repository-URL und bitte ihn, den Server für deinen Client zu installieren. Alles, was ein Modell braucht, um das ohne Benutzeroberfläche zu erledigen – die deklarative Konfiguration pro Client,
claude mcp add-Einzeiler und die Standardwerte – steht inllms.txt(kein interaktiver Assistent erforderlich).
Installation in 60 Sekunden
Wähle eine Option. Jeder Weg endet damit, dass du deinem Assistenten einen Prompt eingibst.
Installation mit einem Klick
Jeder Button registriert den Docker-basierten Server (das Image wird beim ersten Start automatisch gezogen; du musst Docker installiert haben). In der Zeile Claude Desktop wird stattdessen eine native .mcpb-Desktop-Erweiterung heruntergeladen (macOS universal + Windows, kein Docker) – öffne sie mit Claude Desktop und trage die Einstellungen ein. Du brauchst einen Token? Erstelle ein Personal Access Token mit dem api-Scope. Self-managed GitLab? Füge nach der Installation eine GITLAB_URL-Umgebungsvariable in der MCP-Konfiguration deines Clients hinzu.
Claude Code (claude mcp add)
Docker (keine Installation – zieht das Image beim ersten Start):
claude mcp add gitlab --env GITLAB_TOKEN=glpat-xxxx --transport stdio \
-- docker run -i --rm -e GITLAB_TOKEN ghcr.io/jmrplens/gitlab-mcp-server:latest --http=falseOder installiere zuerst das native Binary und registriere es dann:
# 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-serverSelf-managed GitLab? Füge --env GITLAB_URL=https://gitlab.example.com hinzu (und --env GITLAB_SKIP_TLS_VERIFY=true für selbstsignierte Zertifikate).
Geführte Einrichtung (jeder Client, keine Flags zum Merken)
Das Binary enthält einen Setup-Assistenten, der dein GitLab-Token abfragt und deinen MCP-Client für dich konfiguriert – ideal, wenn du kein JSON bearbeiten möchtest:
gitlab-mcp-server --setupEr erkennt VS Code, Claude Desktop, Claude Code, Cursor und Windsurf automatisch und schreibt die passende Konfiguration. Unter Windows startest du ihn per Doppelklick auf die .exe.
Manuelles JSON (Claude Desktop, Cursor, VS Code, …)
Natives Binary (Claude Desktop mcpServers, Cursor usw.):
{
"mcpServers": {
"gitlab": {
"command": "/path/to/gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}VS Code (.vscode/mcp.json, beachte servers + type):
{
"servers": {
"gitlab": {
"type": "stdio",
"command": "/path/to/gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}Docker-Variante – ersetze "command"/"args" durch:
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITLAB_TOKEN", "ghcr.io/jmrplens/gitlab-mcp-server:latest", "--http=false"]Cline (VS Code) – öffne die Cline-Seitenleiste → MCP-Server-Symbol → Edit Global MCP oder bearbeite direkt die Einstellungsdatei:
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 verwendet die oben gezeigte mcpServers-Struktur für das native Binary.
Für ein gemeinsames, langlaufendes HTTP-Deployment anstelle von stdio pro Benutzer siehe HTTP-Server-Modus.
Ausprobieren ohne Installation (gehosteter Endpunkt)
Eine öffentliche Instanz läuft unter https://mcp.jmrp.io/gitlab – keine Installation, kein Konto außer deinem eigenen GitLab-Token. Richte einen beliebigen HTTP-fähigen MCP-Client darauf aus:
{
"mcpServers": {
"gitlab": {
"type": "http",
"url": "https://mcp.jmrp.io/gitlab",
"headers": { "PRIVATE-TOKEN": "glpat-xxxxxxxxxxxx" }
}
}
}PRIVATE-TOKEN ist erforderlich und wird pro Anfrage mitgesendet – er wird nie auf dem Server gespeichert. GITLAB-URL ist optional und standardmäßig auf https://gitlab.com gesetzt; setze sie, um eine andere Instanz zu erreichen (sie muss aus dem öffentlichen Internet erreichbar sein).
Das ist der schnellste Weg, den Server auszuprobieren, und die richtige Art, ihn dauerhaft zu nutzen, ist immer noch lokal (eine der Optionen oben) – aus einem konkreten Grund, nicht als Haftungsausschluss: Dein Token und jede Anfrage laufen über die Maschine eines anderen. Wenn du ihn lokal ausführst, verlassen deine Zugangsdaten und dein GitLab-Datenverkehr deinen Computer nie – das macht ihn auch zur einzig sinnvollen Option für eine private Self-managed-Instanz.
Der Endpunkt ist stateless streamable HTTP auf der standardmäßigen dynamic-Oberfläche: POST ist der Transport, GET darauf antwortet absichtlich mit 405, und https://mcp.jmrp.io/gitlab/health antwortet mit 200 und {"status":"ok",…}. Ein selbst gehostetes HTTP-Deployment kann auch mit --auth-mode=oauth --gitlab-url=https://gitlab.com --public-url=https://mcp.example.com ausgeführt werden (beide sind erforderlich: OAuth benötigt eine feste Instanz und den von außen erreichbaren Origin, über den RFC 9728 die Ressource identifiziert). Dabei entdecken Clients GitLab über diese Metadaten als Autorisierungsserver und autorisieren im Browser, statt Token zu kopieren – siehe OAuth-App-Setup. Er ist einer der Server, die unter mcp.jmrp.io aufgelistet sind, einem Verzeichnis der MCP-Server, die ich pflege; jeder ist über einen eigenen Endpunkt erreichbar. https://mcp.jmrp.io/servers.json ist dieselbe Liste für automatisierte Clients.
Dann frag einfach: Öffne deinen KI-Client und probiere „Liste meine GitLab-Projekte auf.“ Siehe den Leitfaden „Getting Started“ für Details pro Client und weitere Beispiel-Prompts.
Related MCP server: GitLab MCP Server
Warum dieser Server
GitLab in klarer Sprache. Die KI übersetzt „Ist MR !15 sicher zu mergen?“ in die richtigen API-Aufrufe. Du musst keine Endpunkte, IDs oder JSON anfassen.
Die gesamte Plattform – 1000+ Tools. Breite Abdeckung von GitLab REST v4 + GraphQL: Projekte, Branches, Tags, Releases, Merge Requests, Issues, Pipelines, Jobs, Gruppen, Benutzer, Wikis, Umgebungen, Deployments, Pakete, Container-Registry, Runner, Feature Flags, CI/CD-Variablen, Sicherheit, Admin, Tokens und mehr.
Standardmäßig mit geringem Token-Verbrauch. Die standardmäßige dynamische Oberfläche stellt nur 2 Tools (
find+execute) bereit und erreicht dabei den gesamten Katalog – passt also in das Kontextfenster jedes Clients. (Token-Verbrauch →)Mit echten Modellen erprobt. Ein automatisierter Evaluator führt Anthropic, Google, OpenAI und Qwen gegen Live-GitLab-Instanzen aus: 99,5 % Gesamterfolg bei Tausenden von Operationen. (Ergebnisse →)
Sicher per Design. Read-only-Modus, Safe-Modus (Dry-Run-Vorschau jeder Mutation), TLS-Optionen für selbst gehostetes GitLab und kontinuierliche Qualitäts-/Sicherheits-Gates von SonarCloud.
Läuft überall. Eine einzelne statische Binärdatei oder ein Container; Windows, Linux & macOS; amd64 & arm64; stdio (Desktop) und HTTP (remote).
45 MCP-Ressourcen (schreibgeschützte Daten: Projekte, Issues, Pipelines, MRs, Branches, Mitglieder, das oberflächenbewusste
gitlab://tools-Manifest und Best-Practice-Leitfäden für Workflows). 26 Einzelobjekt-Arten sind ebenfalls abonnierbar.37 MCP-Prompts (Code-Review, Pipeline-Status, Risikobewertung, Release-Notes, Standup, Analysen, Audit und mehr).
4 Elicitation-Assistenten (interaktive Issue/MR/Release/Projekt-Erstellung).
4 MCP-Fähigkeiten (Completions, Fortschritt, Elicitation und Ressourcen-Abonnements – Live-
resources/updated-Benachrichtigungen, die per Polling bedient werden) und 51 Tool-Icons (50 Bereichs-Icons plus das Projekt-Logo) zur visuellen Identifikation in MCP-Clients.Paginierung bei jedem Listen-Endpunkt mit vollständigen Metadaten.
Tool-Oberflächen
Der Server kann GitLab in drei Formen präsentieren, gesteuert über TOOL_SURFACE. Die Standardeinstellung erfordert keine Konfiguration.
Oberfläche | Sichtbare Tools | Am besten geeignet für |
Dynamisch (Standard) | 2 ( | Geringste Token-Kosten; erreicht den vollständigen Katalog über find/execute. |
Meta-Tools ( | 32 Basis / 49 Ultimate / 50 GitLab.com Ultimate | Nach Domänen gruppierte Dispatcher mit einem |
Einzeln ( | ~847 Free/CE · ~999 Premium · 1065–1071 Ultimate | Ein MCP-Tool pro GitLab-Operation; benötigt ein großes Kontextfenster. |
Die Tool-Anzahl skaliert mit deiner GitLab-Edition (GITLAB_TIER); höhere Stufen legen mehr Aktionen offen. Siehe Dynamic Toolset und Meta-Tools-Referenz für das Ranking-Modell, die Sicherheitsvorkehrungen und die vollständigen Kataloge. Für dynamische Läufe, bei denen Ressourcen den Kontext dominieren, setze CAPABILITY_SURFACE=minimal.
Token-Verbrauch
Gemessen mit go run ./cmd/audit_tokens/ -footprint gegen den aktuellen Katalog. Die Summen schätzen den Startkontext, der für einen MCP-Client sichtbar ist: sichtbare Tool-Schemas plus gemeinsame Ressourcen und Prompts, unter Verwendung des cl100k_base-Tokenizers (GPT-4/GPT-3.5-Codierung). Für die vollständige Matrix (Meta- und Einzel-Oberflächen, alle META_PARAM_SCHEMA-Modi) siehe Token-Footprint-Referenz.
Standardkonfiguration: Mit nicht gesetztem TOOL_SURFACE bzw. TOOL_SURFACE=dynamic, CAPABILITY_SURFACE=full, nicht gesetztem META_TOOLS, META_PARAM_SCHEMA=opaque und nicht gesetztem GITLAB_TIER (wird erkannt, Fallback free) verwendet der Server die dynamische find/execute-Oberfläche. Verwende TOOL_SURFACE=meta nur, wenn du explizit Domain-Meta-Tools möchtest; verwende TOOL_SURFACE=individual nur, wenn dein Client den vollständigen Tool-Katalog verarbeiten kann.
Konfiguration ( | Stufe | Sichtbare Tools | Erreichbare Aktionen |
| Tool-Schema-Tokens | Gemeinsame Tokens | Gesamt-Tokens |
| Free/CE | 2 | 851 | n/a | 1,499 | 8,720 | 10,219 |
| Free/CE | 2 | 851 | n/a | 1,499 | 170 | 1,669 |
| Premium | 2 | 1,003 | n/a | 1,499 | 8,720 | 10,219 |
| Premium | 2 | 1,003 | n/a | 1,499 | 170 | 1,669 |
| Ultimate | 2 | 1,069 | n/a | 1,499 | 8,720 | 10,219 |
| Ultimate | 2 | 1,069 | n/a | 1,499 | 170 | 1,669 |
Die Zeilen verwenden den Community-Edition-Basiskatalog, sofern die Spalte „Stufe“ nichts anderes angibt. GITLAB_TIER steuert, welche Aktionen verfügbar sind; höhere Stufen legen mehr Tools und damit mehr erreichbare Aktionen offen.
Kompatibilität
MCP-Fähigkeit | Unterstützung |
Tools | Bis zu 1071 einzeln / 32–50 Meta |
Ressourcen | 45 (statisch + Vorlagen) |
Prompts | 37 Vorlagen |
Completions | 17 Argumenttypen: Projekte, Gruppen, Benutzer, Branches, Tags, MRs, Issues, Pipelines, Jobs, Labels, Meilensteine, SHAs |
Server-Logs | Strukturiert (Text/JSON) nach stderr — nicht die MCP- |
Fortschritt | Fortschrittsmeldungen bei der Tool-Ausführung |
Elicitation | 4 interaktive Erstellungsassistenten |
Abonnements |
|
Getestet mit: VS Code + GitHub Copilot, Claude Desktop, Claude Code, Cursor, Windsurf, JetBrains-IDEs, Zed, Kiro, Cline. Siehe die vollständige Kompatibilitätsmatrix.
Bewertung der Tool-Nutzung von KI-Modellen
Das Projekt enthält einen automatisierten Evaluator für die modellseitige MCP-Qualität. Er führt reine Schema-Prüfungen gegen den Tool-Katalog aus oder führt validierte Modell-Tool-Aufrufe über MCP gegen Docker-GitLab-CE- oder lizenzierte Enterprise-Instanzen aus, die mit Fixtures bestückt sind. Er misst, ob jedes Modell die richtige Aktion wählt, gültige Parameter sendet, sich von behebbaren GitLab-Fehlern erholt und die Sicherheitsvorkehrungen für destruktive Aktionen respektiert – über Anthropic, Google, OpenAI und Qwen hinweg.
Aktuell veröffentlichtes Ergebnis: Docker CE dynamic 20260627-232303.
Anbieter | Modell | Kompatibilität | Tool-Genauigkeit | Wiederherstellung | Docker-Live-Status |
Anthropic |
| OK | 100,0 % | 100,0 % (2/2) | 100,0 % final über 555 Operationen |
| OK | 100,0 % | 100,0 % (4/4) | 100,0 % final über 555 Operationen | |
OpenAI |
| Review | 99,3 % | 84,6 % (11/13) | 98,0 % final über 555 Operationen |
Qwen |
| OK | 100,0 % | 100,0 % (5/5) | 100,0 % final über 555 Operationen |
Der veröffentlichte Modell-Evaluationssatz umfasst 596 Aufgabenversuche und 2220 erwartete MCP-Operationen. Über die ausgewählten Berichte hinweg erzeugten Modelle 2265 Tool-Aufrufe bei 2265 Modellanfragen, mit 99,5 % aggregiertem End-Erfolg. Siehe KI-Modell-Evaluationsergebnisse für die detaillierte aktuelle Matrix.
Aktuell veröffentlichtes Ergebnis: Docker Enterprise meta 20260527.
Anbieter | Modell | Kompatibilität | Tool-Genauigkeit | Wiederherstellung | Docker-Live-Status |
Anthropic |
| OK | 100,0 % | 100,0 % (1/1) | 100,0 % final über 84 Operationen |
| Review | 78,2 % | 100,0 % (7/7) | 100,0 % final über 84 Operation |
Dokumentation
Die vollständige Dokumentation findest du unter jmrp.io/docs/gitlab-mcp-server. Nutze diese Übersicht als maßgebliche Referenz für einen bestimmten Bereich:
Dokument | Beschreibung |
Download, Setup-Assistent, Konfiguration pro Client | |
Beispiele für stdio, HTTP-Legacy und HTTP-OAuth pro Client | |
Umgebungsvariablen, Transportmodi, TLS | |
Vollständige Tabelle der Umgebungsvariablen mit Standardwerten und Beispielen | |
Alle Befehlszeilenoptionen, Exit-Codes und Laufzeitbeispiele | |
Gemeinsame HTTP-Bereitstellungen, Authentifizierung, Serverpool-Isolation | |
GitLab-OAuth-Anwendung, Scopes, Redirect-URIs und welche Clients einen Flow abschließen können | |
Ausführen des Servers in GitLab-CI- und GitHub-Actions-Pipelines | |
Der Antwortvertrag, dem jedes Tool folgt: Inhaltsblöcke, Paginierung, nächste Schritte | |
Fehlerklassifizierung, Extraktion von GitLab-Meldungen und die von den Tools zurückgegebenen Hinweise | |
Alle einzelnen Tools mit Eingabe-/Ausgabeschemata, einschließlich des nur für GitLab.com verfügbaren Orbit | |
32/49/50 Domain-Meta-Tools mit Aktionsverteilung | |
2-Tool-Modus mit geringem Tokenverbrauch, kanonischem Aktionskatalog, Sicherheitsmodell und Beispielen | |
Alle 45 Ressourcen mit URI-Vorlagen | |
Alle 37 Prompts mit Argumenten und Ausgabeformat | |
Selbstaktualisierungsmechanismus, Modi und Release-Format | |
Unit-, E2E-, Schema-Modell-Evaluierung, Docker-Modell-Evaluierung und kuratierte Modellergebnisse | |
Sicherheitsmodell, Token-Scopes, Eingabevalidierung | |
Systemarchitektur, Komponentendesign, Datenfluss | |
Erstellen, Testen, CI/CD, Mitwirken | |
Häufige Probleme bei Start, Token, TLS, Transport und Tool-Erkennung |
FAQ
Ja. Setze GITLAB_URL auf die URL deiner Instanz. Wenn GITLAB_URL weggelassen wird, verwendet der stdio-Modus https://gitlab.com. Selbstsignierte TLS-Zertifikate werden über GITLAB_SKIP_TLS_VERIFY=true unterstützt.
Wenn du den Server selbst ausführst – lokal über stdio oder in deiner eigenen Infrastruktur über HTTP – gehen alle API-Aufrufe direkt an deine GitLab-Instanz. Die einzige Anfrage, die an einen anderen Ort geht, ist die Update-Prüfung gegen GitHub Releases, die standardmäßig aktiviert und mit AUTO_UPDATE=false deaktiviert werden kann.
Die Ausnahme ist der gehostete Endpunkt: Die Verwendung von https://mcp.jmrp.io/gitlab bedeutet, dass dein Token und jede Anfrage über diese Maschine laufen. Dort wird nichts gespeichert, aber es ist ein fremder Server – genau deshalb sagt der Abschnitt zum gehosteten Dienst, dass du ihn weiterhin lokal verwenden sollst.
Siehe PRIVACY.md für genau das, was die Update-Prüfung sendet, und SECURITY.md für das Sicherheitsmodell.
Ja. Setze GITLAB_READ_ONLY=true, um alle ändernden Tools (create, update, delete) zu deaktivieren. Es sind dann nur noch Leseoperationen verfügbar.
Alternativ kannst du GITLAB_SAFE_MODE=true für einen Trockenlauf-Modus setzen: Ändernde Tools bleiben sichtbar, geben aber eine strukturierte JSON-Vorschau zurück, anstatt ausgeführt zu werden. Das ist nützlich für Audits, Schulungen oder um zu prüfen, was ein KI-Assistent tun würde.
Sowohl Community Edition (CE) als auch Enterprise Edition (EE). Setze GITLAB_TIER=premium oder GITLAB_TIER=ultimate im stdio-Modus, um zusätzliche Tools für Premium-/Ultimate-Funktionen zu aktivieren (DORA-Metriken, Schwachstellen, Compliance usw.); lasse es ungesetzt, um die Stufe anhand der Instanzlizenz zu erkennen (Fallback free). Im HTTP-Modus kann --tier die Stufe erzwingen, andernfalls wird sie pro Token+URL-Pooleintrag aus der Lizenz erkannt.
Der Server enthält eine Wiederholungslogik mit Backoff für Rate-Limits der GitLab-API. Fehler werden als vorübergehend (wiederholbar) oder dauerhaft klassifiziert, mit umsetzbaren Hinweisen in den Fehlermeldungen.
Jeder MCP-kompatible Client: VS Code + GitHub Copilot, Claude Desktop, Cursor, Claude Code, Windsurf, JetBrains-IDEs, Zed, Kiro und andere. Der integrierte Setup-Assistent kann die meisten Clients automatisch konfigurieren.
Aus dem Quellcode erstellen
git clone https://github.com/jmrplens/gitlab-mcp-server.git
cd gitlab-mcp-server
make buildDas veröffentlichte Container-Image ist ghcr.io/jmrplens/gitlab-mcp-server:latest. Weitere Informationen zu Cross-Kompilierung, Docker Compose und Mitwirkungsrichtlinien findest du im Development Guide.
Komponente | Technologie |
Sprache | Go 1.27+ |
MCP SDK |
|
GitLab-Client |
|
Transport | stdio (Standard), HTTP (Streamable HTTP) |
Datenschutzerklärung
Der Server läuft vollständig auf deiner Maschine und hat keine Telemetrie, kein Analytics und kein eigenes Backend – Daten fließen nur zwischen deinem MCP-Client und der von dir konfigurierten GitLab-Instanz (plus einer optionalen Update-Prüfung signierter Binärdateien gegen GitHub Releases). Dein Token wird ausschließlich zur Authentifizierung von GitLab-Anfragen verwendet und niemals protokolliert. Vollständige Details: PRIVACY.md.
Mitwirken & Sicherheit
Mitwirken: Siehe CONTRIBUTING.md für Entwicklungsrichtlinien, Branch-Namenskonventionen, Commit-Konventionen und den PR-Prozess.
Sicherheit: Siehe SECURITY.md für die Sicherheitsrichtlinie und die Meldung von Schwachstellen.
Verhaltenskodex: Siehe CODE_OF_CONDUCT.md (Contributor Covenant v2.1).
Repository-Spiegel: GitHub ist das kanonische Repository. Ein schreibgeschützter Spiegel ist auf GitLab.com für die Auffindbarkeit verfügbar; bitte reiche Beiträge über GitHub ein.
Dateianzahl
Kategorie | Dateien | Zeilen |
Quellcode ( | 992 | 202.107 |
Unit-Tests ( | 553 | 314.659 |
End-to-End-Tests | 182 | 47.508 |
Gesamt | 1.727 | 564.274 |
Funktionen
Kategorie | Anzahl |
Quellcode-Funktionen | 7.693 |
– exportiert (öffentlich) | 2.675 |
– nicht exportiert (privat) | 5.018 |
Unit-Test-Funktionen ( | 11.985 |
Subtests ( | 2.986 |
End-to-End-Testfunktionen | 439 |
Bemerkenswerte Verhältnisse
Beobachtung | Wert |
Testzeilen vs. Quellcodezeilen | 1,56× mehr Tests als Code |
Durchschnittliche Quelldateilänge | ~203 Zeilen |
Durchschnittliche Testdateilänge | ~569 Zeilen |
Kommentarzeilen im Quellcode | 23.569 (~11,7 % des Codes) |
Testfunktionen pro Quellcodefunktion | 1,6× |
Codemuster
Muster | Anzahl |
| 6.715 |
| 934 |
Definierte | 2.743 |
| 263 |
| 2 |
Projekt
Metrik | Wert |
Go-Pakete | 237 |
Direkte Abhängigkeiten ( | 17 |
Indirekte Abhängigkeiten | 47 |
Ruhmeshalle
Rekord | Datei |
Längste Quelldatei |
|
Längste Testdatei |
|
Weil wir es können
Fakt | Wert |
Quellcode gedruckt mit 55 Zeilen/Seite | ~3.674 Seiten A4 |
Quellcodezeilen mit | 12.629 (unvermeidbar) |
Längster Funktionsname im Quellcode |
|
Längster Testfunktionsname |
|
Gepflegt von José M. Requena Plens · Projektseite · Gehostete Instanz: 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds an important behavioral requirement: destructive actions require top-level confirm=true. It also signals that the tool is general-purpose by saying 'one GitLab catalog action,' which helps set expectations versus a specialized tool.
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?
Three short sentences: the first states the core function, the second gives a required parameter convention, and the third gives the key safety and routing rule. Every sentence contributes new, actionable information with no filler.
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 generic action-executor with an open-world catalog, the description provides full operational context: how to identify actions, how to pass parameters, how to handle destructive actions, and when to fall back to the sibling discovery tool. The output schema covers return-value expectations, so 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 coverage is 100%, so the schema already documents action, params, and confirm with clear descriptions. The description mostly restates these constraints ('Always pass params as an object', confirm requirement) rather than adding new parameter semantics, but it does reinforce the canonical-vs-alias action concept.
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 opens with a specific verb and resource: 'Execute one GitLab catalog action by canonical ID or alias.' It also names the sibling relationship indirectly by saying to use find first when actions are unclear, which distinguishes this execution tool from gitlab_find_action.
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 rules: pass params as an object, set top-level confirm=true for destructive actions, and use find first only when action or params are unclear. This gives an agent clear decision criteria for when to call this tool versus gitlab_find_action.
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. At most 256 characters: a longer query is refused, not truncated. | |
| 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, openWorldHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral detail beyond that: it states 'no GitLab API call' (a specific limitation not in the annotations) and describes what the tool returns ('schemas, hints, destructive flags, and execute examples'). This gives the agent a concrete understanding of the tool's behavior and output without contradicting any annotation.
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 compact—three sentences, each serving a distinct purpose: the first states the core function and read-only nature, the second gives the use case trigger, and the third lists return content. It is front-loaded with the most important information and contains no filler or redundant details.
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 the tool's simplicity (read-only, no API call, no side effects) and the presence of an output schema that covers return structure, the description fully equips an agent: it knows what the tool does, when to invoke it, and what to expect back. Nothing essential is missing for correct invocation.
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% and each parameter is already well-documented in the input schema, including examples for query. The description does not add any additional meaning beyond the schema; it just restates the query pattern. Per the rubric, baseline 3 is appropriate when the schema carries the full parameter documentation burden.
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 clearly states the tool's action (search) and resource (local GitLab action catalog), and explicitly notes it is read-only and makes no API call. It distinguishes itself from the sibling gitlab_execute_action by implying this tool is for lookup when the action ID or params are unclear, so an agent can easily tell them apart.
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 an explicit trigger: 'Use when the action ID or params are unclear.' This clearly indicates when to use the tool, and implicitly that if you have the action ID you would use the execute sibling instead. It stops short of naming the sibling or giving an explicit 'when not to use' rule, but the guidance is clear enough for most cases.
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.
2 tool updates
v3.0.0- Changed
gitlab_execute_action1 field changed- changed
Input schema / properties / confirm / descriptionPrevious value: -"Set top-level confirm=true to explicitly approve destructive actions; do not put confirm inside params for gitlab_execute_action."New value: +"Set top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action."
- Changed
gitlab_find_action2 fields changed- changed
Input schema / properties / query / descriptionPrevious 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."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. At most 256 characters: a longer query is refused, not truncated." - added
Input schema / properties / query / maxLengthAdded value: +256
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."
TDQS
Scored across 2 tools
gitlab_execute_action and gitlab_find_action have clearly distinct roles: one executes catalog actions, the other searches the local catalog without making API calls. There is no meaningful overlap or ambiguity between them.
Both tools follow the same gitlab_<verb>_action pattern, creating a predictable and consistent naming convention. The verb prefixes accurately indicate the operation type.
Two tools is a minimal surface and feels thin for a GitLab server, even though the find/execute split is functional. The generic executor and catalog search reduce the impact, but the count is still borderline.
The two tools form a complete discovery-and-execution loop: find_action provides schemas, hints, and examples, while execute_action runs the selected action. Assuming the underlying catalog covers the needed GitLab operations, there are no obvious 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 together11870,206 npm1,987MIT
- -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.5 npm2-
- 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.326 npm11MIT
- 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,922 npm6Apache 2.0