Capacidades MCP
GitLab MCP Server implementa 4 capacidades del protocolo MCP —progreso, elicitación, autocompletado y suscripciones a recursos— que van más allá de la llamada básica a herramientas para que los asistentes de IA sean más precisos e interactivos al trabajar con GitLab. Además adjunta metadatos de iconos a cada herramienta, recurso y prompt. En conjunto, estas funciones permiten a los asistentes informar del progreso, pedir información al usuario mediante formularios estructurados, autocompletar valores de argumentos, vigilar recursos de GitLab en busca de cambios y mostrar iconos reconocibles por dominio.
Las 4 capacidades se negocian durante el handshake de inicialización MCP, mientras que los iconos son metadatos de presentación que los clientes renderizan o ignoran. Ninguno es obligatorio para que funcionen las llamadas básicas a herramientas: cuando un cliente carece de soporte, el servidor degrada de forma elegante y la operación de GitLab subyacente se completa igualmente.
¿Qué capacidades proporciona GitLab MCP Server?
Sección titulada «¿Qué capacidades proporciona GitLab MCP Server?»GitLab MCP Server proporciona cinco funciones diferenciadas, resumidas a continuación. El progreso y la elicitación envían información del servidor al cliente, el autocompletado obtiene sugerencias del servidor bajo demanda, las suscripciones notifican al cliente cuando un recurso vigilado cambia y los iconos son metadatos estáticos adjuntos a cada superficie.
| Capacidad | Dirección | Qué Habilita |
|---|---|---|
| Progress | Servidor → Cliente | Actualizaciones de progreso en tiempo real para operaciones de larga duración |
| Elicitation | Servidor → Cliente | Asistentes interactivos — formularios paso a paso para crear recursos complejos |
| Completions | Cliente → Servidor | Autocompletado de argumentos para nombres de proyectos, ramas, usuarios y más |
| Subscriptions | Cliente → Servidor (actualizaciones Servidor → Cliente) | Notificaciones de cambio en vivo para 26 tipos de recurso de GitLab, atendidas mediante sondeo (solo GITLAB_MCP_CAPABILITY_SURFACE=full) |
| Icons (metadatos) | Servidor → Cliente | Iconos para cada herramienta, recurso y prompt — SVG más variantes WebP clara/oscura |
¿Cómo se negocian las capacidades MCP?
Sección titulada «¿Cómo se negocian las capacidades MCP?»Las capacidades se negocian una vez, durante el handshake de inicialización MCP entre el cliente y el servidor. Cada parte anuncia lo que admite, de modo que ninguna intenta usar una función que la otra no puede manejar. Tras el handshake, el servidor puede enviar notificaciones de progreso y solicitudes de elicitación, y el cliente puede pedir autocompletado.
Las capacidades declaradas por el servidor (autocompletado) están siempre disponibles porque GitLab MCP Server las anuncia de forma incondicional. Las capacidades dependientes del cliente (elicitación) requieren que el cliente MCP declare soporte — el servidor lo comprueba antes de usar la capacidad y degrada de forma elegante cuando no está disponible, recurriendo a las herramientas parametrizadas estándar para no perder funcionalidad.
¿Qué clientes MCP admiten cada capacidad?
Sección titulada «¿Qué clientes MCP admiten cada capacidad?»El soporte de capacidades varía según el cliente MCP, y GitLab MCP Server se adapta automáticamente a lo que anuncie el cliente conectado. La tabla siguiente refleja clientes habituales en el momento de redactar esta página; como el soporte de los clientes evoluciona rápidamente, confirma el estado actual en la documentación de cada cliente.
| Capacidad | Claude Desktop | VS Code Copilot | Cursor | Claude Code |
|---|---|---|---|---|
| Progreso | ✅ | ✅ | ✅ | ✅ |
| Autocompletado | ✅ | ✅ | ❓ | ✅ |
| Elicitación | ✅ | ❌ | ❌ | ✅ |
| Suscripciones² | ❓ | ✅ | ❓ | ❓ |
| Iconos¹ | ❌ | ✅ | ❓ | ❌ |
² VS Code se suscribe automáticamente a cada recurso que lee y encamina
resources/updated a su pipeline de cambios de archivo. Cursor envía
peticiones resources/subscribe (incluso a servidores que no anuncian la
capacidad), pero no está verificado si muestra las notificaciones
resultantes — como tampoco lo está el manejo de suscripciones en Claude
Desktop y Claude Code. Los clientes que nunca se suscriben no pierden nada:
los recursos siguen siendo legibles bajo demanda.
¹ Los iconos no son una capacidad negociada: el servidor los adjunta siempre y
un cliente que no puede renderizar ninguno de ellos simplemente los ignora,
sin perder nada funcional. La columna registra si un cliente renderiza al
menos una de las tres entradas que gitlab-mcp-server adjunta a cada icono
—un SVG escalable más variantes WebP clara/oscura—, no si admite todos los
formatos. VS Code Copilot, por ejemplo, rechaza la entrada SVG
(image/svg+xml no está en su lista de MIME permitidos) pero renderiza la
variante WebP que coincide con su tema. Consulta
Iconos para la matriz completa.
Preguntas frecuentes
¿Qué capacidades MCP implementa GitLab MCP Server?
GitLab MCP Server implementa cuatro capacidades del protocolo MCP —progreso, elicitación, autocompletado y suscripciones a recursos— más metadatos de iconos en cada herramienta, recurso y prompt. El progreso envía actualizaciones en tiempo real durante operaciones de larga duración, la elicitación permite al servidor pedir información al usuario mediante formularios estructurados, el autocompletado completa valores de argumentos como nombres de proyectos, ramas, usuarios y etiquetas, y las suscripciones a recursos entregan notificaciones de cambio en vivo para 26 tipos de recurso de GitLab, atendidas mediante sondeo. Los iconos son metadatos de presentación, no una capacidad de protocolo negociada. Las cuatro capacidades se negocian durante el handshake de inicialización MCP.
¿Cuál es la diferencia entre capacidades declaradas por el servidor y dependientes del cliente?
Las capacidades declaradas por el servidor, como el autocompletado, GitLab MCP Server las anuncia de forma incondicional y están disponibles para cualquier cliente que las invoque. Las capacidades dependientes del cliente, como la elicitación, requieren que el cliente MCP declare soporte durante la inicialización. El servidor comprueba ese soporte antes de usar la capacidad y degrada de forma elegante cuando falta — en el caso de la elicitación, recurre a las herramientas parametrizadas estándar, por lo que se preserva la funcionalidad y solo se reduce la experiencia interactiva.
¿Qué ocurre si mi cliente MCP no admite una capacidad?
GitLab MCP Server se adapta automáticamente. Las notificaciones de progreso son de mejor esfuerzo y se ignoran silenciosamente cuando no se admiten, así que las herramientas se completan igualmente. La elicitación recurre a las herramientas parametrizadas estándar, donde el asistente proporciona todos los parámetros en una sola llamada. El autocompletado simplemente no se ofrece, y los valores siguen siendo descubribles mediante la acción de listado del dominio (project.list, branch.list, etc. mediante gitlab_execute_action en la superficie predeterminada, o la acción list de la meta-herramienta correspondiente con GITLAB_MCP_TOOL_SURFACE=meta). Los iconos son metadatos opcionales que los clientes sin renderizado ignoran. Ninguna capacidad es obligatoria para la funcionalidad básica de las herramientas.
¿Qué clientes MCP admiten la elicitación?
La elicitación la admiten Claude Desktop y Claude Code. VS Code Copilot y Cursor aún no la admiten, por lo que en esos clientes GitLab MCP Server recurre a las herramientas de creación parametrizadas estándar. Como el soporte de capacidades de los clientes cambia con frecuencia, confirma el estado actual en la documentación del cliente específico.