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

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 add y los valores predeterminados — está en llms.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=false

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

Detecta 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.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 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://tools consciente 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 (gitlab_find_action, gitlab_execute_action)

Menor coste de tokens; llega al catálogo completo mediante find/execute.

Meta-tools (meta)

32 base / 49 Ultimate / 50 GitLab.com Ultimate

Enrutadores agrupados por dominio con un parámetro action.

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

Nivel

Herramientas visibles

Acciones accesibles

META_PARAM_SCHEMA

Tokens de esquema de herramientas

Tokens compartidos

Total de tokens

dynamic / full (por defecto)

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 (por defecto)

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 (por defecto)

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

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 logging de MCP, que está obsoleta (SEP-2577) y no se anuncia deliberadamente

Progreso

Informe de progreso de la ejecución de herramientas

Elicitación

4 asistentes de creación interactivos

Suscripciones

resources/updated mediante polling, 26 tipos de recursos

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

Primeros pasos

Descarga, asistente de configuración, configuración por cliente

Configuración del IDE

Ejemplos de stdio por cliente, HTTP heredado y HTTP OAuth

Configuración

Variables de entorno, modos de transporte, TLS

Variables de entorno

Tabla exhaustiva de variables de entorno con valores por defecto y ejemplos

Referencia de CLI

Todas las opciones de línea de comandos, códigos de salida y ejemplos de ejecución

Modo de servidor HTTP

Despliegues HTTP compartidos, autenticación, aislamiento del pool de servidores

Configuración de la aplicación OAuth

Aplicación OAuth de GitLab, ámbitos, URI de redirección y qué clientes pueden completar un flujo

CI/CD

Ejecutar el servidor dentro de pipelines de GitLab CI y GitHub Actions

Formato de salida

El contrato de respuesta que sigue toda herramienta: bloques de contenido, paginación, siguientes pasos

Gestión de errores

Clasificación de errores, extracción de mensajes de GitLab y las pistas que devuelven las herramientas

Referencia de herramientas

Todas las herramientas individuales con esquemas de entrada/salida, incluida Orbit, exclusiva de GitLab.com

Meta-herramientas

Meta-herramientas de dominio 32/49/50 con despacho de acciones

Conjunto de herramientas dinámico

Modo de 2 herramientas y bajo consumo de tokens, con catálogo canónico de acciones, modelo de seguridad y ejemplos

Recursos

Los 45 recursos con plantillas de URI

Prompts

Los 37 prompts con argumentos y formato de salida

Actualización automática

Mecanismo de auto-actualización, modos y formato de lanzamiento

Pruebas

Pruebas unitarias, E2E, evaluación de modelos de esquema, evaluación de modelos Docker y resultados de modelos seleccionados

Seguridad

Modelo de seguridad, ámbitos de token, validación de entradas

Arquitectura

Arquitectura del sistema, diseño de componentes, flujo de datos

Guía de desarrollo

Compilación, pruebas, CI/CD, contribución

Solución de problemas

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 build

La 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

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

Cliente de GitLab

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

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

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 (.go, no pruebas)

992

202,107

Pruebas unitarias (_test.go)

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

11,985

Subpruebas (t.Run(...))

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 if err != nil

6,715

Sentencias defer

934

Tipos struct definidos

2,743

Supresiones //nolint

263

Comentarios TODO / FIXME / HACK

2

Proyecto

Métrica

Valor

Paquetes Go

237

Dependencias directas (go.mod)

17

Dependencias indirectas

47

Salón de la fama

Récord

Archivo

Archivo de código fuente más largo

internal/tools/projects/projects.go — 3,846 líneas

Archivo de prueba más largo

internal/tools/projects/projects_test.go — 8,183 líneas

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 "gitlab"

12,629 (imposible de evitar)

Nombre de función más largo en el código fuente

assertDynamicCompatibilityPolicyOwnedByActionCompat (51 caracteres)

Nombre de función de prueba más largo

TestRequiredMissingAndUnknownParamNames_SchemaValidation_ReturnsSortedMissingAndUnknown (87 caracteres)


Mantenido por José M. Requena Plens · Página del proyecto · Instancia alojada: 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