# gitlab

> 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.
> Esta página en markdown. Índice: https://mcp.jmrp.io/llms.txt

Canonical: https://mcp.jmrp.io/es/servers/gitlab/
Language: es
Alternate: https://mcp.jmrp.io/servers/gitlab/index.md
Updated: 2026-09-11T09:56:41+02:00
License: https://mcp.jmrp.io/es/license/


## Resumen

- Endpoint: `https://mcp.jmrp.io/gitlab` (solo POST; un GET responde 401)
- Transporte: HTTP streamable, JSON-RPC 2.0 sin estado
- Versión: 3.0.0
- Autenticación: `Authorization`
- Salud: `https://mcp.jmrp.io/gitlab/health`
- Repositorio: https://github.com/jmrplens/gitlab-mcp-server
- Documentación: https://jmrp.io/docs/gitlab-mcp-server

## 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**

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

**Cursor — ~/.cursor/mcp.json**

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

**VS Code — .vscode/mcp.json**

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

### O pegar un token

**Claude Code**

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

**Cursor — ~/.cursor/mcp.json**

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

**VS Code — .vscode/mcp.json**

```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}"
      }
    }
  }
}
```

## 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.

No añade cuota propia más allá de la general del sitio: 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: https://mcp.jmrp.io/es/internals/

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: https://mcp.jmrp.io/es/policies/

## 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 tools
- 37 prompts
- 8 resources
- 37 resource templates

## Catálogo de acciones

Las tools de arriba dan la cara por un catálogo de 766 acciones en 29 dominios: se encuentran y se llaman a través de ellas, no se exponen una a una. Contado con un token Free — el tier y los permisos del token mueven la cifra. Índice: https://mcp.jmrp.io/servers/gitlab/actions.json. Una página de referencia por dominio en https://mcp.jmrp.io/es/servers/gitlab/actions/.

## Catálogo completo

Todas las herramientas, prompts, recursos y plantillas de este servidor —con lo que cada una recibe y devuelve— están listadas en https://mcp.jmrp.io/llms-full.txt, y el propio servidor las sirve en vivo en `https://mcp.jmrp.io/gitlab/.well-known/mcp/server-card.json`.