Gitlab MCP Server
GitLab MCP Server
Conecta tu asistente de IA a GitLab para que pueda revisar merge requests, clasificar pipelines, gestionar issues y redactar releases — en lenguaje natural. Un único binario estático (o un contenedor), más de 1000 herramientas de GitLab sobre toda la API REST + GraphQL, compatible con Claude, Cursor, VS Code y cualquier cliente MCP.
Tú hablas con tu asistente de IA; él hace el trabajo en GitLab. No hay que recordar IDs de proyecto, endpoints de API ni JSON.
«Revisa la merge request !15: ¿es seguro fusionarla?» · «¿Por qué falló el último pipeline?» · «Lista los issues abiertos asignados a mí» · «Genera notas de versión de v1.0 a v2.0»
🤖 ¿Usas un asistente de IA? Dale la URL de este repositorio y pídele que instale el servidor para tu cliente. Todo lo que un modelo necesita para hacerlo sin intervención — la configuración declarativa por cliente, los comandos de una sola línea de
claude mcp addy los valores predeterminados — está enllms.txt(no se necesita asistente interactivo).
Instalación en 60 segundos
Elige una opción. Cada vía termina con que escribas un prompt a tu asistente.
Instalación con un clic
Cada botón registra el servidor basado en Docker (descarga la imagen automáticamente en la primera ejecución; necesitas Docker instalado). La fila de Claude Desktop en cambio descarga una extensión de escritorio .mcpb nativa (macOS universal + Windows, sin Docker): ábrela con Claude Desktop y rellena los ajustes. ¿Necesitas un token? Crea un token de acceso personal con el ámbito api. ¿GitLab autogestionado? Añade la variable de entorno GITLAB_URL en la configuración MCP de tu cliente después de la instalación.
Claude Code (claude mcp add)
Docker (sin instalación: descarga la imagen en la primera ejecución):
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=falseO instala primero el binario nativo y luego regístralo:
# 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¿GitLab autogestionado? Añade --env GITLAB_URL=https://gitlab.example.com (y --env GITLAB_SKIP_TLS_VERIFY=true para certificados autofirmados).
Configuración guiada (cualquier cliente, sin flags que recordar)
El binario incluye un asistente de configuración que recoge tu token de GitLab y configura tu cliente MCP por ti — ideal si prefieres no editar JSON:
gitlab-mcp-server --setupDetecta automáticamente VS Code, Claude Desktop, Claude Code, Cursor y Windsurf, y escribe la configuración adecuada. En Windows, haz doble clic en el .exe para iniciarlo.
JSON manual (Claude Desktop, Cursor, VS Code, …)
Binario nativo (mcpServers de Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"gitlab": {
"command": "/path/to/gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}VS Code (.vscode/mcp.json, ten en cuenta servers + type):
{
"servers": {
"gitlab": {
"type": "stdio",
"command": "/path/to/gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}Variante Docker: sustituye "command"/"args" por:
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITLAB_TOKEN", "ghcr.io/jmrplens/gitlab-mcp-server:latest", "--http=false"]Cline (VS Code): abre la barra lateral de Cline → icono de servidores MCP → Editar MCP global, o edita directamente el archivo de configuración:
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 usa la estructura mcpServers mostrada arriba para el binario nativo.
Para un despliegue HTTP compartido y de larga duración en lugar del stdio por usuario, consulta Modo servidor HTTP.
Pruébalo sin instalar nada (endpoint alojado)
Una instancia pública está disponible en https://mcp.jmrp.io/gitlab: no hay nada que instalar, ni más cuenta que tu propio token de GitLab. Apunta hacia ella cualquier cliente MCP compatible con HTTP:
{
"mcpServers": {
"gitlab": {
"type": "http",
"url": "https://mcp.jmrp.io/gitlab",
"headers": { "PRIVATE-TOKEN": "glpat-xxxxxxxxxxxx" }
}
}
}PRIVATE-TOKEN es obligatorio y viaja en cada petición: nunca se almacena en el servidor. GITLAB-URL es opcional y su valor predeterminado es https://gitlab.com; establécelo para llegar a otra instancia (debe ser accesible desde Internet público).
Es la forma más rápida de probar el servidor, y la forma correcta de seguir usándolo sigue siendo en local (cualquier opción anterior), por una razón concreta, no como descargo de responsabilidad: tu token y cada petición pasan por la máquina de otra persona. Ejecutarlo en local significa que tus credenciales y tu tráfico de GitLab nunca salen de tu ordenador, lo que también lo convierte en la única opción sensata para una instancia privada autogestionada.
El endpoint es HTTP streamable sin estado en la superficie dynamic predeterminada: POST es el transporte, GET sobre él responde 405 por diseño, y https://mcp.jmrp.io/gitlab/health responde 200 con {"status":"ok",…}. Un despliegue HTTP autoalojado también puede ejecutarse con --auth-mode=oauth --gitlab-url=https://gitlab.com --public-url=https://mcp.example.com (ambos son obligatorios: OAuth necesita una instancia fija y el origen accesible externamente por el que RFC 9728 identifica el recurso), donde los clientes descubren GitLab como servidor de autorización a través de esos metadatos y autorizan en el navegador en lugar de copiar tokens — consulta Configuración de la app OAuth. Es uno de los servidores listados en mcp.jmrp.io, un directorio de los servidores MCP que mantengo, cada uno accesible en su propio endpoint; https://mcp.jmrp.io/servers.json es la misma lista para clientes automatizados.
Entonces solo pregunta: abre tu cliente de IA y prueba «Lista mis proyectos de GitLab». Consulta la guía de inicio para obtener detalles por cliente y más prompts de ejemplo.
Related MCP server: GitLab MCP Server
Por qué este servidor
GitLab en lenguaje natural. La IA traduce «¿es seguro fusionar el MR !15?» a las llamadas de API correctas. No tocas endpoints, IDs ni JSON.
Toda la plataforma: más de 1000 herramientas. Amplia cobertura de GitLab REST v4 + GraphQL: proyectos, ramas, tags, releases, merge requests, issues, pipelines, jobs, grupos, usuarios, wikis, entornos, despliegues, paquetes, registro de contenedores, runners, feature flags, variables de CI/CD, seguridad, administración, tokens y más.
Bajo consumo de tokens por defecto. La superficie dynamic por defecto expone solo 2 herramientas (
find+execute) mientras llega al catálogo completo, por lo que cabe en la ventana de contexto de cualquier cliente. (Huella de tokens →)Probado con modelos reales. Un evaluador automatizado ejecuta Anthropic, Google, OpenAI y Qwen contra instancias de GitLab en vivo: 99.5% de éxito agregado en miles de operaciones. (Resultados →)
Seguro por diseño. Modo de solo lectura, modo seguro (vista previa dry-run de cada mutación), opciones TLS para GitLab autoalojado y controles continuos de calidad/seguridad de SonarCloud.
Se ejecuta en cualquier lugar. Un único binario estático o contenedor; Windows, Linux y macOS; amd64 y arm64; stdio (escritorio) y HTTP (remoto).
45 recursos MCP (datos de solo lectura: proyectos, issues, pipelines, MRs, ramas, miembros, el manifiesto
gitlab://toolsconsciente de la superficie y guías de mejores prácticas de flujo de trabajo). 26 tipos de objeto único también son suscribibles.37 prompts MCP (revisión de código, estado del pipeline, evaluación de riesgos, notas de release, standup, análisis, auditoría y más).
4 asistentes de elicitación (creación interactiva de issues/MR/releases/proyectos).
4 capacidades MCP (completions, progress, elicitation y suscripciones a recursos: notificaciones en vivo de
resources/updated, atendidas mediante polling) y 51 iconos de herramientas (50 iconos de dominio más el logotipo del proyecto) para la identificación visual en clientes MCP.Paginación en cada endpoint de listado con metadatos completos.
Superficies de herramientas
El servidor puede exponer GitLab de tres formas, controladas por TOOL_SURFACE. La opción por defecto no requiere configuración.
Superficie | Herramientas visibles | Ideal para |
Dynamic (por defecto) | 2 ( | Menor coste de tokens; llega al catálogo completo mediante find/execute. |
Meta-tools ( | 32 base / 49 Ultimate / 50 GitLab.com Ultimate | Enrutadores agrupados por dominio con un parámetro |
Individual ( | ~847 Free/CE · ~999 Premium · 1065–1071 Ultimate | Una herramienta MCP por operación de GitLab; requiere una ventana de contexto grande. |
El número de herramientas escala con tu edición de GitLab (GITLAB_TIER); los niveles superiores exponen más acciones. Consulta Dynamic Toolset y Meta-Tools Reference para ver el modelo de clasificación, las salvaguardas de seguridad y los catálogos completos. Para ejecuciones dynamic en las que los recursos dominan el contexto, establece CAPABILITY_SURFACE=minimal.
Huella de tokens
Medido con go run ./cmd/audit_tokens/ -footprint contra el catálogo actual. Los totales estiman el contexto de inicio visible para un cliente MCP: esquemas de herramientas visibles más recursos y prompts compartidos, usando el tokenizador cl100k_base (codificación GPT-4/GPT-3.5). Para la matriz completa (superficies meta e individual, todos los modos META_PARAM_SCHEMA), consulta Token Footprint Reference.
Configuración por defecto: con TOOL_SURFACE sin definir o TOOL_SURFACE=dynamic, CAPABILITY_SURFACE=full, META_TOOLS sin definir, META_PARAM_SCHEMA=opaque y GITLAB_TIER sin definir (detectado, fallback free), el servidor usa la superficie dynamic find/execute. Usa TOOL_SURFACE=meta solo cuando quieras explícitamente meta-tools de dominio; usa TOOL_SURFACE=individual solo cuando tu cliente pueda manejar el catálogo de herramientas completo.
Configuración ( | Nivel | Herramientas visibles | Acciones accesibles |
| Tokens de esquema de herramientas | Tokens compartidos | Total de 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 |
Las filas usan el catálogo base de Community Edition salvo que la columna Nivel indique lo contrario. GITLAB_TIER controla qué acciones están disponibles; los niveles superiores exponen más herramientas y, por tanto, más acciones accesibles.
Compatibilidad
Capacidad MCP | Soporte |
Herramientas | Hasta 1071 individuales / 32–50 meta |
Recursos | 45 (estáticos + plantillas) |
Prompts | 37 plantillas |
Completions | 17 tipos de argumento: proyectos, grupos, usuarios, ramas, tags, MRs, issues, pipelines, jobs, etiquetas, hitos, SHAs |
Registros del servidor | Estructurados (texto/JSON) a stderr — no la capacidad |
Progreso | Informe de progreso de la ejecución de herramientas |
Elicitación | 4 asistentes de creación interactivos |
Suscripciones |
|
Probado con: VS Code + GitHub Copilot, Claude Desktop, Claude Code, Cursor, Windsurf, JetBrains IDEs, Zed, Kiro, Cline. Consulta la matriz de compatibilidad completa.
Evaluación del uso de herramientas por modelos de IA
El proyecto incluye un evaluador automatizado de la
Documentación
La documentación completa está en jmrp.io/docs/gitlab-mcp-server. Usa este mapa como referencia de fuente de verdad para un área específica:
Documento | Descripción |
Descarga, asistente de configuración, configuración por cliente | |
Ejemplos de stdio por cliente, HTTP heredado y HTTP OAuth | |
Variables de entorno, modos de transporte, TLS | |
Tabla exhaustiva de variables de entorno con valores por defecto y ejemplos | |
Todas las opciones de línea de comandos, códigos de salida y ejemplos de ejecución | |
Despliegues HTTP compartidos, autenticación, aislamiento del pool de servidores | |
Aplicación OAuth de GitLab, ámbitos, URI de redirección y qué clientes pueden completar un flujo | |
Ejecutar el servidor dentro de pipelines de GitLab CI y GitHub Actions | |
El contrato de respuesta que sigue toda herramienta: bloques de contenido, paginación, siguientes pasos | |
Clasificación de errores, extracción de mensajes de GitLab y las pistas que devuelven las herramientas | |
Todas las herramientas individuales con esquemas de entrada/salida, incluida Orbit, exclusiva de GitLab.com | |
Meta-herramientas de dominio 32/49/50 con despacho de acciones | |
Modo de 2 herramientas y bajo consumo de tokens, con catálogo canónico de acciones, modelo de seguridad y ejemplos | |
Los 45 recursos con plantillas de URI | |
Los 37 prompts con argumentos y formato de salida | |
Mecanismo de auto-actualización, modos y formato de lanzamiento | |
Pruebas unitarias, E2E, evaluación de modelos de esquema, evaluación de modelos Docker y resultados de modelos seleccionados | |
Modelo de seguridad, ámbitos de token, validación de entradas | |
Arquitectura del sistema, diseño de componentes, flujo de datos | |
Compilación, pruebas, CI/CD, contribución | |
Problemas comunes de inicio, token, TLS, transporte y descubrimiento de herramientas |
Preguntas frecuentes
Sí. Establece GITLAB_URL en la URL de tu instancia. Cuando se omite GITLAB_URL, el modo stdio usa https://gitlab.com. Los certificados TLS autofirmados son compatibles mediante GITLAB_SKIP_TLS_VERIFY=true.
Cuando lo ejecutas tú mismo — localmente mediante stdio, o en tu propia infraestructura mediante HTTP — todas las llamadas a la API van directamente a tu instancia de GitLab. La única solicitud que sale a cualquier otro lugar es la comprobación de actualizaciones contra GitHub Releases, que está activada por defecto y se desactiva con AUTO_UPDATE=false.
La excepción es el endpoint alojado: usar https://mcp.jmrp.io/gitlab significa que tu token y cada solicitud pasan por esa máquina. Allí no se almacena nada, pero es un servidor de otra persona, por eso la sección del endpoint alojado recomienda seguir usándolo localmente.
Consulta PRIVACY.md para saber exactamente qué envía la comprobación de actualizaciones, y SECURITY.md para conocer el modelo de seguridad.
Sí. Establece GITLAB_READ_ONLY=true para deshabilitar todas las herramientas de modificación (crear, actualizar, eliminar). Solo estarán disponibles las operaciones de lectura.
Alternativamente, establece GITLAB_SAFE_MODE=true para un modo de simulación (dry-run): las herramientas de modificación permanecen visibles pero devuelven una vista previa JSON estructurada en lugar de ejecutarse. Útil para auditar, entrenar o revisar lo que haría un asistente de IA.
Tanto la Community Edition (CE) como la Enterprise Edition (EE). Establece GITLAB_TIER=premium o GITLAB_TIER=ultimate en modo stdio para habilitar herramientas adicionales para las funciones Premium/Ultimate (métricas DORA, vulnerabilidades, cumplimiento, etc.); déjalo sin establecer para detectar el nivel desde la licencia de la instancia (valor por defecto free). En modo HTTP, --tier puede forzar el nivel; de lo contrario, se detecta por cada entrada del pool de token+URL a partir de la licencia.
El servidor incluye lógica de reintento con retroceso (backoff) para los límites de tasa de la API de GitLab. Los errores se clasifican como transitorios (reintentables) o permanentes, con pistas accionables en los mensajes de error.
Cualquier cliente compatible con MCP: VS Code + GitHub Copilot, Claude Desktop, Cursor, Claude Code, Windsurf, JetBrains IDEs, Zed, Kiro y otros. El asistente de configuración integrado puede configurar automáticamente la mayoría de los clientes.
Compilación desde el código fuente
git clone https://github.com/jmrplens/gitlab-mcp-server.git
cd gitlab-mcp-server
make buildLa imagen de contenedor publicada es ghcr.io/jmrplens/gitlab-mcp-server:latest. Consulta la Guía de desarrollo para conocer las pautas de compilación cruzada, Docker Compose y contribución.
Componente | Tecnología |
Lenguaje | Go 1.27+ |
MCP SDK |
|
Cliente de GitLab |
|
Transporte | stdio (por defecto), HTTP (Streamable HTTP) |
Política de privacidad
El servidor se ejecuta por completo en tu máquina y no tiene telemetría, análisis ni backend propios — los datos fluyen solo entre tu cliente MCP y la instancia de GitLab que configures (además de una comprobación opcional de actualización de binario firmado contra GitHub Releases). Tu token se usa únicamente para autenticar las solicitudes de GitLab y nunca se registra. Detalles completos: PRIVACY.md.
Contribución y seguridad
Contribución: consulta CONTRIBUTING.md para conocer las pautas de desarrollo, la nomenclatura de ramas, las convenciones de commits y el proceso de PR.
Seguridad: consulta SECURITY.md para conocer la política de seguridad y la notificación de vulnerabilidades.
Código de conducta: consulta CODE_OF_CONDUCT.md (Contributor Covenant v2.1).
Espejo del repositorio: GitHub es el repositorio canónico. Hay un espejo de solo lectura disponible en GitLab.com para facilitar su descubrimiento; por favor, abre las contribuciones en GitHub.
Recuento de archivos
Categoría | Archivos | Líneas |
Código fuente ( | 992 | 202,107 |
Pruebas unitarias ( | 553 | 314,659 |
Pruebas de extremo a extremo | 182 | 47,508 |
Total | 1,727 | 564,274 |
Funciones
Categoría | Cantidad |
Funciones de código fuente | 7,693 |
— exportadas (públicas) | 2,675 |
— no exportadas (privadas) | 5,018 |
Funciones de prueba unitaria ( | 11,985 |
Subpruebas ( | 2,986 |
Funciones de prueba de extremo a extremo | 439 |
Proporciones que vale la pena señalar
Observación | Valor |
Líneas de prueba frente a líneas de código fuente | 1.56× más pruebas que código |
Longitud media de los archivos de código fuente | ~203 líneas |
Longitud media de los archivos de prueba | ~569 líneas |
Líneas de comentarios en el código fuente | 23,569 (~11.7% del código fuente) |
Funciones de prueba por función de código fuente | 1.6× |
Patrones de código
Patrón | Cantidad |
Comprobaciones | 6,715 |
Sentencias | 934 |
Tipos | 2,743 |
Supresiones | 263 |
Comentarios | 2 |
Proyecto
Métrica | Valor |
Paquetes Go | 237 |
Dependencias directas ( | 17 |
Dependencias indirectas | 47 |
Salón de la fama
Récord | Archivo |
Archivo de código fuente más largo |
|
Archivo de prueba más largo |
|
Porque sí
Dato | Valor |
Código fuente impreso a 55 líneas por página | ~3,674 páginas de A4 |
Líneas de código fuente que mencionan | 12,629 (imposible de evitar) |
Nombre de función más largo en el código fuente |
|
Nombre de función de prueba más largo |
|
Mantenido por José M. Requena Plens · Página del proyecto · Instancia alojada: 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