Skip to main content
Glama

GitLab MCP Server

GitHub Release License: MIT Platform

CI Quality Gate Coverage Go Reference

Glama MCP Score

MCP Badge MCP Toplist Cursor Directory Hosted endpoint

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 in llms.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=false

Oder 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-server

Self-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 --setup

Er 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.json

  • Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

  • Windows: %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 (gitlab_find_action, gitlab_execute_action)

Geringste Token-Kosten; erreicht den vollständigen Katalog über find/execute.

Meta-Tools (meta)

32 Basis / 49 Ultimate / 50 GitLab.com Ultimate

Nach Domänen gruppierte Dispatcher mit einem action-Parameter.

Einzeln (individual)

~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 (TOOL_SURFACE / CAPABILITY_SURFACE)

Stufe

Sichtbare Tools

Erreichbare Aktionen

META_PARAM_SCHEMA

Tool-Schema-Tokens

Gemeinsame Tokens

Gesamt-Tokens

dynamic / full (Standard)

Free/CE

2

851

n/a

1,499

8,720

10,219

dynamic / minimal

Free/CE

2

851

n/a

1,499

170

1,669

dynamic / full (Standard)

Premium

2

1,003

n/a

1,499

8,720

10,219

dynamic / minimal

Premium

2

1,003

n/a

1,499

170

1,669

dynamic / full (Standard)

Ultimate

2

1,069

n/a

1,499

8,720

10,219

dynamic / minimal

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-logging-Fähigkeit, die veraltet ist (SEP-2577) und bewusst nicht beworben wird

Fortschritt

Fortschrittsmeldungen bei der Tool-Ausführung

Elicitation

4 interaktive Erstellungsassistenten

Abonnements

resources/updated per Polling, 26 Ressourcenarten

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

claude-haiku-4-5-20251001

OK

100,0 %

100,0 % (2/2)

100,0 % final über 555 Operationen

Google

gemini-flash-latest

OK

100,0 %

100,0 % (4/4)

100,0 % final über 555 Operationen

OpenAI

gpt-5.4-nano

Review

99,3 %

84,6 % (11/13)

98,0 % final über 555 Operationen

Qwen

qwen3.6-flash

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

claude-haiku-4-5-20251001

OK

100,0 %

100,0 % (1/1)

100,0 % final über 84 Operationen

Google

gemini-flash-latest

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

Getting Started

Download, Setup-Assistent, Konfiguration pro Client

IDE Configuration

Beispiele für stdio, HTTP-Legacy und HTTP-OAuth pro Client

Configuration

Umgebungsvariablen, Transportmodi, TLS

Environment Variables

Vollständige Tabelle der Umgebungsvariablen mit Standardwerten und Beispielen

CLI Reference

Alle Befehlszeilenoptionen, Exit-Codes und Laufzeitbeispiele

HTTP Server Mode

Gemeinsame HTTP-Bereitstellungen, Authentifizierung, Serverpool-Isolation

OAuth App Setup

GitLab-OAuth-Anwendung, Scopes, Redirect-URIs und welche Clients einen Flow abschließen können

CI/CD

Ausführen des Servers in GitLab-CI- und GitHub-Actions-Pipelines

Output Format

Der Antwortvertrag, dem jedes Tool folgt: Inhaltsblöcke, Paginierung, nächste Schritte

Error Handling

Fehlerklassifizierung, Extraktion von GitLab-Meldungen und die von den Tools zurückgegebenen Hinweise

Tools Reference

Alle einzelnen Tools mit Eingabe-/Ausgabeschemata, einschließlich des nur für GitLab.com verfügbaren Orbit

Meta-Tools

32/49/50 Domain-Meta-Tools mit Aktionsverteilung

Dynamic Toolset

2-Tool-Modus mit geringem Tokenverbrauch, kanonischem Aktionskatalog, Sicherheitsmodell und Beispielen

Resources

Alle 45 Ressourcen mit URI-Vorlagen

Prompts

Alle 37 Prompts mit Argumenten und Ausgabeformat

Auto-Update

Selbstaktualisierungsmechanismus, Modi und Release-Format

Testing

Unit-, E2E-, Schema-Modell-Evaluierung, Docker-Modell-Evaluierung und kuratierte Modellergebnisse

Security

Sicherheitsmodell, Token-Scopes, Eingabevalidierung

Architecture

Systemarchitektur, Komponentendesign, Datenfluss

Development Guide

Erstellen, Testen, CI/CD, Mitwirken

Troubleshooting

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 build

Das 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

github.com/modelcontextprotocol/go-sdk v1.7.0

GitLab-Client

gitlab.com/gitlab-org/api/client-go/v2 v2.59.0

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

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 (.go, ohne Tests)

992

202.107

Unit-Tests (_test.go)

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 (TestXxx)

11.985

Subtests (t.Run(...))

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

if err != nil-Prüfungen

6.715

defer-Anweisungen

934

Definierte struct-Typen

2.743

//nolint-Unterdrückungen

263

TODO- / FIXME- / HACK-Kommentare

2

Projekt

Metrik

Wert

Go-Pakete

237

Direkte Abhängigkeiten (go.mod)

17

Indirekte Abhängigkeiten

47

Ruhmeshalle

Rekord

Datei

Längste Quelldatei

internal/tools/projects/projects.go — 3.846 Zeilen

Längste Testdatei

internal/tools/projects/projects_test.go — 8.183 Zeilen

Weil wir es können

Fakt

Wert

Quellcode gedruckt mit 55 Zeilen/Seite

~3.674 Seiten A4

Quellcodezeilen mit "gitlab"

12.629 (unvermeidbar)

Längster Funktionsname im Quellcode

assertDynamicCompatibilityPolicyOwnedByActionCompat (51 Zeichen)

Längster Testfunktionsname

TestRequiredMissingAndUnknownParamNames_SchemaValidation_ReturnsSortedMissingAndUnknown (87 Zeichen)


Gepflegt von José M. Requena Plens · Projektseite · Gehostete Instanz: mcp.jmrp.io/gitlab

Available Tools

2 tools
gitlab_execute_actionGitLab Execute ActionA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesCanonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close.
paramsYesRequired action-specific parameters object validated by the selected action schema. Use an empty object for actions with no parameters.
confirmNoSet top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action.

Output Schema

ParametersJSON Schema
NameRequiredDescription
next_stepsNoOptional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
paginationNoPresent on list actions. Use `has_more` and `next_page` to paginate through results.

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 ActionA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of matches to return. Defaults to 20 and is capped at 50.
queryYesSearch 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.
explainNoWhen true, include deterministic scoring reasons for each returned action. Defaults to false to keep responses compact.

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesNumber of returned matches.
queryYesOriginal search query.
resultsYesMatching GitLab catalog actions with schemas and execute examples.

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv3.0.0
    • Changedgitlab_execute_action1 field changed
      • changedInput schema / properties / confirm / description
        Previous 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."
    • Changedgitlab_find_action2 fields changed
      • changedInput schema / properties / query / description
        Previous 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."
      • addedInput schema / properties / query / maxLength
        Added value: +256
  2. 1 tool updatev2.7.5
    • Changedgitlab_execute_action1 field changed
      • changedInput schema / properties / action / x-mcp-header
        Previous value: -"Mcp-Param-Action"New value: +"Action"
  3. 1 tool updatev2.6.0
    • Addedgitlab_execute_action
  4. 1 tool updatev2.5.2
    • Removedgitlab_execute_action
  5. 3 tool updatesv2.1.3
    • Addedgitlab_execute_action
    • Removedgitlab_execute_tool
    • Changedgitlab_find_action4 fields changed
      • changedOutput schema / properties / results / items / properties / example / description
        Previous value: -"Example gitlab_execute_tool call."New value: +"Example gitlab_execute_action call."
      • changedOutput schema / properties / results / items / properties / example / properties / arguments / description
        Previous value: -"Example arguments for gitlab_execute_tool."New value: +"Example arguments for gitlab_execute_action."
      • changedOutput schema / properties / results / items / properties / id / description
        Previous value: -"Canonical action ID to pass to gitlab_execute_tool."New value: +"Canonical action ID to pass to gitlab_execute_action."
      • changedOutput schema / properties / results / items / properties / required_params / description
        Previous value: -"Required parameter names captured from the input schema."New value: +"Required action-specific parameter names to place inside gitlab_execute_action params."
  6. 2 tool updatesv2.0.2
    • Changedgitlab_execute_tool3 fields changed
      • changedInput schema / properties / action / description
        Previous 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."
      • changedInput schema / properties / confirm / description
        Previous 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."
      • changedOutput 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"
        +}
    • Changedgitlab_find_action1 field changed
      • changedInput schema / properties / query / description
        Previous 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

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow the same gitlab_<verb>_action pattern, creating a predictable and consistent naming convention. The verb prefixes accurately indicate the operation type.

Tool Count3/5

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.

Completeness5/5

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

ActivityActive
ResponsivenessResponsive

Related MCP Connectors

Related MCP Servers

  • -
    license
    Not graded
    quality
    Not graded
    maintenance
    A 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 npm
    2
    -
  • A
    license
    B
    quality
    C
    maintenance
    A 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.
    32
    6 npm
    11
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Full-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 npm
    6
    Apache 2.0