Ficha de servidor MCP

gitlab

GitLab MCP Server

Endpoint MCP de GitLab alojado y gratuito, sin más cuenta que tu propio token de gitlab.com, que nunca se escribe en disco. Más de 700 operaciones.

Conectarlo a tu cliente

Entrar con OAuth (recomendado)

Tu cliente abre gitlab.com en el navegador, autorizas ahí y él guarda el token: no pegas ninguno. El client ID hay que configurarlo sí o sí — sin él estos clientes caen al registro dinámico, que GitLab responde con un alcance que este servidor no puede usar.

Claude Code

claude mcp add gitlab --transport http \
  --client-id c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941 \
  --callback-port 8090 \
  https://mcp.jmrp.io/gitlab

Cursor — ~/.cursor/mcp.json

{
  "mcpServers": {
    "gitlab": {
      "type": "http",
      "url": "https://mcp.jmrp.io/gitlab",
      "oauth": {
        "clientId": "c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941",
        "scopes": [
          "api"
        ]
      }
    }
  }
}

VS Code — .vscode/mcp.json

{
  "servers": {
    "gitlab": {
      "type": "http",
      "url": "https://mcp.jmrp.io/gitlab",
      "oauth": {
        "clientId": "c9431f281376dab9390349f60bed0503285786e19577df14a9c291c588b85941",
        "scopes": [
          "api"
        ]
      }
    }
  }
}

O pegar un token

Para lo que no puede abrir un navegador —headless, CI—, un personal access token de gitlab.com enviado como Bearer se verifica exactamente igual que uno de OAuth.

Claude Code

claude mcp add --transport http gitlab \
  https://mcp.jmrp.io/gitlab \
  --header "Authorization: Bearer <your token>"

Cursor — ~/.cursor/mcp.json

{
  "mcpServers": {
    "gitlab": {
      "url": "https://mcp.jmrp.io/gitlab",
      "headers": {
        "Authorization": "Bearer ${env:GITLAB_TOKEN}"
      }
    }
  }
}

VS Code — .vscode/mcp.json

{
  "inputs": [
    {
      "type": "promptString",
      "id": "gitlab-token",
      "description": "Tu credencial de gitlab.com, enviada como Bearer: un token de acceso OAuth, o un personal access token usado igual. Nunca se escribe en disco ni se registra en el servidor.",
      "password": true
    }
  ],
  "servers": {
    "gitlab": {
      "type": "http",
      "url": "https://mcp.jmrp.io/gitlab",
      "headers": {
        "Authorization": "Bearer ${input:gitlab-token}"
      }
    }
  }
}

En los ficheros JSON, los marcadores ${…} mantienen la credencial fuera del fichero: Cursor lo lee de tu entorno y VS Code lo pide una vez y lo guarda él mismo. En el comando, sustituye <your token> a mano.

Antes de apoyarte en esto

Este endpoint es un servicio personal, operado por una sola persona y ofrecido tal cual: sin SLA, sin canal de soporte y sin promesa de que siga en pie —o igual— la semana que viene. Los dos servidores son open source y son un único binario estático, así que lo que no puedas permitirte perder es mejor levantarlo en tu propia instancia.

Cada credencial tiene 60 llamadas por segundo a GitLab por instancia, en ráfagas de hasta 40, y los accesos fallidos repetidos bloquean la dirección durante un tiempo. Por encima de eso, cada llamada se descuenta de los límites de gitlab.com, con tu propio token.

Detrás del endpoint hay tres instancias de este servidor. Un hash consistente hace que el mismo cliente vuelva siempre a la misma, y cada instancia sale hacia fuera por su propio nodo de salida, en España o en Reino Unido: Cómo se enruta una petición, salto a salto

Qué se registra y durante cuánto tiempo, de dónde parece venir una petición y la base legal de todo ello están escritos enteros en: Privacidad, logs y postura legal

¿gitlab cuesta algo, y hace falta cuenta?

El endpoint es gratuito y aquí no hay nada a lo que darse de alta. Lo que necesita es una cuenta de gitlab.com que ya tengas, porque el servidor actúa en tu nombre: no tiene cuenta propia ni emite credencial alguna, así que no hay clave que pedir ni plan que elegir.

La cuota que gastes es la tuya en gitlab.com, y lo que alcances es lo que alcance ese token: este servidor no añade ningún tier propio.

¿A dónde va tu token de GitLab?

Tu token se queda solo en la memoria de tu navegador. No se guarda en localStorage ni en cookies, no viaja en la URL y desaparece al recargar. Se envía únicamente como cabecera Authorization: Bearer a mcp.jmrp.io/gitlab, que nunca lo escribe en disco ni lo registra: el servidor lo conserva en memoria solo mientras lo sigas usando —hasta una hora después de tu última llamada— y después lo descarta.

El destino no es cuestión de confianza: la Content-Security-Policy de esta página declara connect-src 'self' https://gitlab.com y form-action 'self', así que es el propio navegador el que impide enviar el token a ningún sitio que no sea este dominio y el que lo emite. gitlab.com está en esa lista por una única razón —el botón de acceso, que canjea un código de autorización por un token emitido a la aplicación OAuth propia del inspector, con alcance read_api y nada más— y por ninguna otra. Lo que el servidor haga después con él —conservarlo en memoria mientras lo uses, volver a comprobarlo con gitlab.com cada quince minutos y descartarlo—, puedes comprobarlo en su código fuente, que es público.

Aun así, desconfía por norma de cualquier web que te pida un token, incluida esta. Lo razonable es:

Comprobarlo tú mismo: el código de esta página es público, y el del servidor también.
Usar la credencial más estrecha que te sirva. Un token con alcance read_api se admite y recibe exactamente las acciones que GitLab acepta de ese alcance, que son lecturas: no puede romper nada, y es el adecuado para probar el servidor. api sólo hace falta para llegar a las acciones que escriben. Más estrecho todavía es un token fine-grained de GitLab, limitado a los proyectos y permisos que elijas: el servidor le sirve sólo lo que alcanza su concesión, y lo rechaza en la puerta si la concesión no incluye User: Read. El servidor decide acción por acción, no una vez en la puerta, así que pedir menos te sirve menos en lugar de rechazarte.
Revocarlo cuando termines de probar.
No reutilizar nunca un token que uses en producción.

Cómo se deriva ese hash, con el código a la vista

¿Qué límites de peticiones y disponibilidad tiene gitlab?

El endpoint gitlab de mcp.jmrp.io es igualmente personal, sin SLA ni garantía de continuidad. Para algo crítico, levanta tu propia instancia — el servidor es open source y un único binario estático.

Cada credencial tiene su propio presupuesto en cada una de las tres instancias: 60 llamadas por segundo que lleguen a GitLab, en ráfagas de hasta 40, y el listado del catálogo en un cubo aparte que se rellena diez veces más despacio. Por encima de eso, lo que gastas es la cuota de gitlab.com, con tu propio token.

Los accesos fallidos se cuentan por dirección. Diez en un minuto bloquean esa dirección hasta que pasa el minuto; cincuenta tokens rechazados distintos en diez minutos la bloquean un minuto, luego diez, y después una hora cada vez. Un cliente que reintenta con un token caducado se recupera solo; uno que prueba token tras token, no.

Resumen

Nombre del servidor: gitlab-mcp-server
Versión: 3.2.0
Endpoint: https://mcp.jmrp.io/gitlab
Autenticación: Requiere credenciales (oauth2)

En palabras del propio servidor (en inglés): Model Context Protocol server for GitLab: projects, issues, merge requests, pipelines, repositories, releases, groups, and admin workflows over the GitLab REST and GraphQL APIs.

Probar en el inspector Repositorio Documentación Sitio web oficial

Instrucciones de uso

Lo que el propio servidor le dice a cada cliente al conectar (server/discover), citado tal cual (en inglés).

gitlab-mcp-server exposes GitLab projects, merge requests, issues, branches, tags, releases, repositories, commits, files, groups, members, and uploads.

FINDING TOOLS. This server exposes two tools that reach the whole GitLab API:
1. Call gitlab_find_action with a natural-language description of the task to get matching action IDs and their input schemas.
2. Call gitlab_execute_action with that action ID, its parameters under 'params'.
3. Every action="..." named below is a canonical action ID: pass it to gitlab_execute_action directly, no find step needed.

PROJECT DISCOVERY. To find the project_id needed for most operations:
1. Read the .git/config file from the workspace to find [remote "origin"] url = ...
2. Call action="discover_project.resolve" with that URL to get the project_id.
3. Alternatively, use action="project.list" (owned=true) or action="search.projects" to find projects by name.

DEFAULT BRANCH. When generating URLs to repository files or branches:
1. Call action="project.get" to retrieve the project metadata, which includes the default_branch field.
2. ALWAYS use the returned default_branch value (e.g. develop, master) instead of assuming 'main'.
3. Projects can use any branch as default, so NEVER hardcode 'main' in URLs.

PACKAGE + RELEASE WORKFLOW. When uploading packages and linking them to releases:
1. Preferred: Use action="package.publish_and_link" to upload a file and create the release link in one step.
2. Alternative: Use action="package.publish" first, then use the 'url' field from its response as the URL for action="release.link_create".
3. NEVER construct package download URLs manually. Always use the actual URL returned by the publish tool.
4. RELEASE LINK NAMING: The link_name MUST be the exact filename (e.g. 'checksums.txt.asc'), NEVER add descriptive suffixes like '(GPG signature)'. go-selfupdate and other tools match asset names exactly.

RELEASE CREATION. When creating releases:
1. You do NOT need to create the tag first. Provide 'ref' (branch or SHA) in action="release.create" and GitLab auto-creates the tag.
2. The response includes 'assets_sources' with auto-generated tar.gz/zip archive URLs. Use those, never construct source archive URLs.
3. Use 'tag_message' to create an annotated tag instead of a lightweight one.

ID vs IID. GitLab uses two identifiers for issues and merge requests:
1. IID is the project-scoped number shown in URLs and UI (e.g. issue #3, MR !5). Most operations expect IID.
2. ID is the global numeric identifier. Only use action="issue.get_by_id" when you have a global ID from another API response.

WATCHING RESOURCES. Instead of re-reading a resource in a loop to detect change:
1. Single-object resources (a pipeline, an issue, a merge request, a file, a wiki page, ...) can be watched for change notifications via MCP subscriptions/listen, which protocol revision 2026-07-28 introduced (a client speaking an earlier revision cannot watch resources on this transport: the legacy resources/subscribe is refused here, because each request's session ends with its response); collections (issue lists, branch lists) cannot.
2. Example: subscribe to gitlab://project/{project_id}/pipelines/latest to be notified when a pipeline's state changes, instead of polling it yourself. The server watches GitLab and sends notifications/resources/updated only when the content actually changed.

Tools(2)

GitLab Execute Action

gitlab_execute_action

destructiva
mundo abierto

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. Example: {"action":"issue.list","params":{"project_id":"group/project"}}

Argumentos (3 campos)

action string · obligatorio: Canonical action ID returned by gitlab_find_action, or a supported compatibility alias, such as project.list, issue.update, or issue.close.
params object · obligatorio: Required action-specific parameters object validated by the selected action schema. Use an empty object for actions with no parameters.
confirm boolean: Set top-level confirm=true to explicitly approve destructive actions. Do not put confirm inside params for gitlab_execute_action.

Qué devuelve (2 campos)

next_steps string[]: Optional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
pagination object: Present on list actions. A REST list carries the fields below: while `has_more` is true, call again with `page` set to `next_page`. A GraphQL list carries cursor fields instead: while `has_next_page` is true, pass `end_cursor` as `after`.

Dominio	Acciones	Destructivas	Solo lectura
`project`	124	25	51
`user`	76	14	37
`group`	75	12	33
`issue`	66	8	33
`access`	48	9	19
`merge_request`	46	7	23
`repository`	41	2	27
`snippet`	34	6	17
`pipeline`	33	4	15
`package`	30	8	12
`job`	25	5	13
`mr_review`	23	3	10
`runner`	19	4	8
`environment`	18	4	7
`ci_variable`	15	3	6
`achievement`	12	3	4
`release`	12	2	5
`template`	12	0	12
`branch`	11	3	5
`feature_flags`	10	2	4
`search`	10	0	10
`tag`	9	2	5
`wiki`	6	1	2
`interactive`	4	0	0
`custom_emoji`	3	1	1
`ci_catalog`	2	0	2
`server`	2	0	2
`discover_project`	1	0	1
`model_registry`	1	0	1

Conectarlo a tu cliente

Entrar con OAuth (recomendado)

O pegar un token

Antes de apoyarte en esto

¿gitlab cuesta algo, y hace falta cuenta?

¿A dónde va tu token de GitLab?

¿Qué límites de peticiones y disponibilidad tiene gitlab?

Resumen

Instrucciones de uso

Tools(2)

GitLab Execute Action

GitLab Find Action

Catálogo de acciones (768)

Prompts (37)

Audit Commit Hygiene

Audit Project Full

Audit Project Workflow

Branch MR Summary

Compare Branches

Daily Standup

Generate Release Notes

Group Milestone Progress

Group MR Dashboard

Label Distribution

Merge Velocity

Milestone Progress

MR Description Quality

MR Discussion Health

MR Risk Assessment

My Activity Summary

My Issues

My Open MRs

My Pending Reviews

Project Activity Report

Project Contributors

Project Health Check

Release Cadence

Release Readiness

Review MR

Reviewer Workload

Stale Items Report

Suggest MR Reviewers

Summarize MR Changes

Summarize Open MRs

Summarize Pipeline Status

Team Member Workload

Team Overview

Unassigned Items

User Activity Report

User Stats

Weekly Team Recap

Resources (8)

All Groups

Code Review Guide

Conventional Commits Guide

Git Workflow Guide

Merge Request Hygiene Guide

Pipeline Troubleshooting Guide

Tool Manifest

Current User Profile

Resource templates (37)

Group Details

Group Label Details

Group Members

Group Milestone Details

Group Projects

Project Metadata

Board Details

Branch Details

Project Branches

Commit Details

Deploy Key Details

Deployment Details

Environment Details

Feature Flag Details

Repository File

Issue Details

Project Issues

Job Details

Label Details