# gitlab-mcp-server: la API de GitLab ante un GitLab real > Una página de jmrp.io, publicada como markdown. Índice: https://jmrp.io/llms.txt Canonical: https://jmrp.io/es/blog/series/gitlab-mcp-server/ Language: es Alternate: https://jmrp.io/blog/series/gitlab-mcp-server/index.md Updated: 2026-10-10 License: https://jmrp.io/es/license/ Dos análisis de gitlab-mcp-server: contrastar la API de GitLab con un GitLab arrancado y deducir qué necesita un token de grano fino para cada acción. Build-Date: 2026-10-10 Dos artículos sobre gitlab-mcp-server, el servidor Model Context Protocol (MCP) que mantengo y que expone las API REST y GraphQL de GitLab operación por operación. El primero convierte un GitLab arrancado en el árbitro de lo que la API acepta y devuelve; el segundo pregunta a esa misma instantánea qué necesita un token de acceso personal de grano fino para cada acción. 2 artículos ## Por qué estos dos van juntos Los dos parten de una misma decisión: cuando la documentación, el SDK y una instancia en marcha no coinciden sobre la API de GitLab, gana la instancia. El servidor arranca una imagen publicada de GitLab, pregunta a la aplicación cargada cuáles son sus rutas, entidades, tipos GraphQL y permisos, y guarda la respuesta en el repositorio. Las auditorías de lo que devuelve la API REST de GitLab, y la tabla de permisos por acción, leen esa instantánea en lugar de la documentación o el código fuente. El primer artículo explica por qué arrancar GitLab es mejor que analizar su código; el segundo usa la misma instantánea para responder lo que dejan abierto las páginas de referencia de permisos de GitLab, que enumeran una ruta o un tipo GraphQL cada vez: qué necesita de un token de grano fino cada acción del servidor en su conjunto, y qué acciones no alcanza ninguna concesión. Comparten también un punto de vista que pocos proyectos tienen. Un servidor que expone mil operaciones de GitLab una a una tiene que enviar en cada una de ellas una petición que GitLab acepte y publicar lo que GitLab devuelve, así que las distancias entre lo que GitLab dice y lo que GitLab hace no dejan de llegarle: un 401 que en realidad es un 403, una escritura respondida como éxito sin haber guardado nada, una ruta documentada con la entidad equivocada, un tipo GraphQL que responde null a un token de grano fino sin ningún error. Cada artículo trata de lo que ese punto de vista dejó al descubierto y de cómo se las arregla el servidor hasta que GitLab cambia. El último hilo es qué pasa después con cada hallazgo. Lo que no le toca arreglar al servidor, sea de GitLab, de client-go (el SDK de Go de GitLab) o de otro proyecto upstream, entra en un registro público con su evidencia y lo que le cuesta a un cliente, y de ahí, por norma, en un merge request upstream. El primer artículo describe ese ciclo para la API en su conjunto; el segundo aplica la misma costumbre a la API de tokens de GitLab, donde dio lugar a los merge requests que permiten a un token de grano fino leer su propia concesión desde el endpoint self y hacen que crear o rotar tu propio token devuelva la concesión nueva. Leídos juntos, muestran un mismo método aplicado dos veces, con los arreglos upstream como subproducto. ## Léelos en este orden El primer artículo presenta la instantánea y las comprobaciones construidas a su alrededor; el segundo solo necesita la instantánea, que resume en una frase, profundiza en una única pregunta y puede leerse por separado si solo te interesa la respuesta sobre los tokens. Cada entrada de abajo dice qué deja resuelto. ### Parte 1: Lo que construir un servidor MCP me enseñó sobre la API de GitLab URL: https://jmrp.io/es/blog/013-gitlab-mcp-server-api-lessons/ Markdown: https://jmrp.io/es/blog/013-gitlab-mcp-server-api-lessons/index.md Publicado: 2026-10-10 Empieza aquí, porque construye lo que necesita el segundo artículo: cinco comprobaciones que someten el servidor a un GitLab en marcha, la primera de ellas una instantánea tomada de un GitLab arrancado, y la regla de que una declaración que responde a un hallazgo hace fallar el build en cuanto deja de coincidir con nada. Las tres primeras comprobaciones vienen con el punto ciego que cada una no puede ver, y en esos puntos ciegos estaban los hallazgos más instructivos. Deja resuelto a cuál de las tres descripciones de la API de GitLab creer cuando no coinciden, y termina con el registro que convirtió los hallazgos en merge requests upstream. ### Parte 2: Tokens de grano fino de GitLab, acción por acción URL: https://jmrp.io/es/blog/014-gitlab-fine-grained-tokens-per-action/ Markdown: https://jmrp.io/es/blog/014-gitlab-fine-grained-tokens-per-action/index.md Publicado: 2026-10-10 Después, la misma instantánea aplicada a una sola pregunta: qué necesita un token de acceso personal de grano fino para cada acción. Léelo si creas estos tokens o escribes un cliente que recibe uno. Una concesión no se puede cambiar una vez creado el token, y GraphQL puede responder fuera de ella con null y sin error donde REST nombra el permiso que falta, así que la prueba y error cuesta un token nuevo por cada fallo. Deduce lo que necesita cada acción a partir de lo que declara GitLab 19.4.1, muestra cómo el servidor se lo dice al cliente antes de que nada llegue a GitLab y termina con el token que hay que crear. ## Hacia dónde sigue esto La instantánea está fijada a una release de GitLab, así que lo que viene después es mecánico: cada vez que se vuelve a tomar de una release más reciente, las declaraciones que respondían a defectos corregidos en esa release dejan de coincidir con nada, el build falla por ellas y se borran junto con los workarounds que explicaban. La tabla de permisos se mueve del mismo modo, a medida que GitLab declara los tipos GraphQL que siguen en su propia lista de pendientes. El estado actual de todo lo que estos artículos fechan vive fuera de ellos. La documentación del servidor, también en español, incluye una referencia generada de lo que cada acción necesita de un token de grano fino, y el registro upstream de defectos, público en el repositorio de GitHub del servidor, anota el estado de cada merge request y el workaround que exige hasta que llega el arreglo. ## Qué no cubre esta serie Más allá de crear un token para él, esto no es una guía para instalar o configurar el servidor; de eso se encarga su documentación. Tampoco trata del propio Model Context Protocol ni de los clientes que llaman al servidor: el tema es la API de GitLab y lo que reveló contrastarla con GitLab. Y no cubre GitLab CI/CD, los runners ni la interfaz de GitLab, salvo donde se crea un token. ## El software La serie documenta un único programa, gitlab-mcp-server. Su código, su documentación y su ficha: - Repositorio: https://github.com/jmrplens/gitlab-mcp-server - Documentación: https://jmrp.io/docs/gitlab-mcp-server/ - En la página de proyectos: https://jmrp.io/es/projects/ Preguntas que responde: **¿De qué trata la serie «gitlab-mcp-server: la API de GitLab ante un GitLab real»?** Dos artículos sobre gitlab-mcp-server, el servidor Model Context Protocol (MCP) que mantengo y que expone las API REST y GraphQL de GitLab operación por operación. El primero convierte un GitLab arrancado en el árbitro de lo que la API acepta y devuelve; el segundo pregunta a esa misma instantánea qué necesita un token de acceso personal de grano fino para cada acción. ## Otras series - [Endurecer Nginx, desde el borde hacia dentro](https://jmrp.io/es/blog/series/nginx-hardening/): Cinco guías de Nginx en orden de lectura: mTLS, CSP, HTTP/3, ficheros virtuales y un tarpit, un borde endurecido decisión a decisión. ([markdown](https://jmrp.io/es/blog/series/nginx-hardening/index.md)) - [MikroTik dual-stack, del ISP al cortafuegos](https://jmrp.io/es/blog/series/mikrotik-dual-stack/): Tres guías de RouterOS: una VPN WireGuard dual-stack, PPPoE con delegación de prefijo DHCPv6 y un honeypot que bloquea escáneres solo. ([markdown](https://jmrp.io/es/blog/series/mikrotik-dual-stack/index.md)) - [Firmware de Kleidos: tres decisiones bajo restricciones duras](https://jmrp.io/es/blog/series/kleidos-firmware/): Tres análisis de un gestor de contraseñas hardware sobre ESP32-S3: cadenas i18n empaquetadas, bóveda encrypt-then-MAC y claves ligadas al dispositivo. ([markdown](https://jmrp.io/es/blog/series/kleidos-firmware/index.md))