Jenkins MCP server
Servidor MCP de Jenkins de lectura prioritaria en Go para depuración de compilaciones impulsada por agentes. 20 herramientas que incluyen compare_builds, detección de pruebas inestables, análisis de fallos JUnit/Ginkgo y registros de consola almacenados en caché en disco con transferencia de ruta en disco. Las herramientas de escritura (activar/detener/cancelar) están controladas por la variable de entorno JENKINS_MCP_READONLY.
Documentación
jenkins-mcp-go
Un servidor Model Context Protocol (MCP) rápido y enfocado para Jenkins, escrito en Go.
Conecta Jenkins a Claude Desktop, Claude Code, Cursor o cualquier agente de IA compatible con MCP: obtén registros de consola, inspecciona etapas de pipelines, analiza informes de pruebas JUnit y Ginkgo, compara dos builds, clasifica pruebas flaky, dispara y aborta builds, y gestiona la cola de builds — todo a través de un único transporte MCP stdio, desde un único binario estático de Go.
¿Por qué jenkins-mcp-go?
La mayoría de las integraciones con Jenkins esperan a un humano frente al teclado. Los agentes LLM necesitan algo diferente: respuestas pequeñas y estructuradas; un camino claro desde "build fallido" hasta "aquí está la línea que falla"; y la capacidad de buscar en un registro de consola de varios gigabytes sin volver a descargarlo en cada pregunta.
jenkins-mcp-go está construido para ese flujo de trabajo:
- Lectura primero, escrituras opt-out. Las herramientas de lectura están siempre activas. Las herramientas de escritura (
trigger_build,stop_build,cancel_queue_item) están controladas porJENKINS_MCP_READONLY: establece la variable de entorno y el servidor registra solo la superficie de lectura. - Un solo host, una sola credencial. Habla con una única URL de Jenkins con un único token de API, configurado mediante variables de entorno. Sin superficie multi-tenant, sin bóveda de credenciales que pueda usarse mal.
- Con forma de triaje, no de API. Las herramientas responden a las preguntas que los agentes realmente hacen — "¿qué cambió entre el build A y el B?" (
compare_builds), "¿qué pruebas en este job son flaky?" (get_flaky_candidates), "¿qué commits y archivos tocaron este build?" (get_scm_context) — en lugar de reflejar los endpoints de Jenkins uno a uno. - Construido para ventanas de contexto. Cada herramienta de listado acepta un filtro RE2 y un límite.
get_console_log_pathdevuelve la ruta en disco del registro de un build finalizado para que el agente puedaRead/Grep/Bashde forma nativa en lugar de transmitir gigabytes a través de MCP. - Registros de consola con caché en disco. Los builds finalizados se guardan una vez y se reutilizan. La caché se clave por ruta de job + número de build, está limitada por tamaño total y se desaloja por mtime LRU.
- Consciente de Pipeline y Ginkgo. Más allá de la consola cruda, herramientas dedicadas analizan
/wfapi/describe,/testReport/api/jsony el bloqueSummarizing N Failurede Ginkgo para que el agente obtenga información de fallos pre-digerida. - Un único binario estático. Go puro. Sin runtime de Python, sin Docker requerido.
Herramientas
| Herramienta | Propósito |
|---|---|
health_check | Valida la configuración del servidor: alcance y versión de Jenkins, usuario autenticado, emisor de crumb CSRF, presencia de plugins Pipeline/JUnit, conteos de nodos en línea/fuera de línea, desviación de reloj y la configuración efectiva con la que se ejecuta el proceso. |
get_plugin_versions | Lista los plugins instalados de Jenkins con versiones, indicador de fijado e indicador de actualización pendiente. Opcional name_filter (RE2) y include_inactive. El 403 se degrada a una pista clara. |
whoami_can | Sondea un job para ver los permisos efectivos de Lectura / Build / Cancelación / Configuración del token configurado mediante solicitudes GET de solo lectura. Útil de antemano para evitar un 403 en un disparo o cancelación. Permanece de solo lectura incluso cuando JENKINS_MCP_READONLY=false. |
list_jobs | Enumera jobs y carpetas bajo una ruta (o raíz). Recursión opcional y filtro de nombre RE2 insensible a mayúsculas; limitado a 500 entradas. |
list_branches | Enumera las ramas de un WorkflowMultiBranchProject con número de último build por rama, resultado, duración y marca de tiempo. Opcional name_filter (RE2) y healthy_only. |
get_console_log | Muestra el final del /consoleText del build. Por defecto las últimas 500 líneas; pasa tail_lines: -1 para el registro completo. |
get_console_log_path | Fuerza la caché del registro completo de un build finalizado y devuelve su ruta en disco para que el agente pueda Read/Grep/Bash de forma nativa. |
search_console_log | Búsqueda de regex RE2 sobre el registro de consola con ventanas de contexto conscientes del número de línea. |
tail_running_build | Cola limitada y con seguimiento de desplazamiento del registro de consola de un build en curso a través del progressiveText de Jenkins. Devuelve Next since_byte para paginar. Nunca escribe en la caché en disco. |
get_build_info | Resumen del build con formato bonito: resultado, duración, parámetros, conjunto de cambios. |
get_build_environment | Tres secciones para un build: Causa (razón del disparo verbatim), Parámetros (secretos enmascarados mostrados como (masked)) y Variables de Entorno Inyectadas vía EnvInject. El RE2 opcional name_filter reduce la sección de variables de entorno. Se degrada en EnvInject 404. |
get_scm_context | Historial por commit para un build: id de commit, autor, marca de tiempo, asunto del mensaje y las rutas tocadas de cada commit con códigos de edición A/M/D. Los conjuntos de cambios de Pipeline se aplanan con encabezados por conjunto. RE2 opcional path_filter. |
last_green_build | Informa del build exitoso más reciente de un job. Devuelve número, hora de finalización (UTC) y URL — el punto de partida para la bisección desde verde. |
changes_since_last_green | Une los commits de todos los builds finalizados desde el último verde del job. Recorre previousCompletedBuild, deduplica por commitId, soporta path_filter y max_commits. Muestra pies de página de 'todo verde' y de ventana amplia. |
compare_builds | Compara dos builds del mismo job en resultado, duración, parámetros, commits SCM, etapas de pipeline y pruebas JUnit. El agente responde "¿qué cambió entre A y B?" en una sola llamada. |
get_pipeline_stages | Lista las etapas de Pipeline Declarativo/Scriptado vía /wfapi/describe con estado y duración. |
get_stage_log | Obtiene el registro de una sola etapa de pipeline vía /execution/node/<id>/wfapi/log. |
get_pipeline_script | Devuelve el Jenkinsfile que un build específico realmente ejecutó. Prueba primero el plugin Replay (fijado al build), cae a config.xml (a nivel de job — procedencia mostrada). Devuelve coordenadas SCM como pista para jobs de Pipeline-desde-SCM. |
get_test_report | Resultados JUnit estructurados de /testReport/api/json, con casos fallidos y cabeza+cola de los stack traces. |
get_flaky_candidates | Clasifica pruebas flaky en los últimos N builds finalizados de un job contando los cambios pass↔fail. Devuelve una tabla ordenada de nombre de prueba, número de cambios, totales de pass/fail y último build visto. |
get_test_history | Tendencia por build de una sola prueba en los últimos N builds finalizados — el seguimiento de get_flaky_candidates una vez que se conoce un sospechoso. Línea de tiempo (número de build, resultado, estado, duración, cabeza de error) más un resumen de conteos y cambios. |
find_test_by_name | Localiza qué job ejecuta una prueba cuyo nombre completo contiene una subcadena. Recorre list_jobs(recursive) bajo folder_path, distribuye sondeos por job contra lastCompletedBuild/testReport con un tiempo de espera de 5s por job, renderiza una tabla ordenada de coincidencias. |
find_recent_failures | Examina builds fallidos en los jobs bajo folder_path dentro de una ventana de retroceso. Sondeo por job de los últimos 5 builds; filtra por since (24h por defecto; soporta Nd) y result_filter (FAILURE/UNSTABLE/ABORTED/ANY_NON_SUCCESS). |
list_pr_builds | Lista todos los builds de un PR en un WorkflowMultiBranchProject. Sondea las convenciones comunes de nombres de ramas de PR en paralelo (PR-N, pull/N/head, change-N, pr/N) y renderiza el historial de builds para la primera coincidencia. |
get_ginkgo_failure_summary | Analiza el bloque Summarizing N Failure de Ginkgo y muestra el primer [ERROR] etiquetado con cada nombre de especificación. |
list_nodes | Lista agentes/nodos de Jenkins con estado, conteos de ejecutores, etiquetas y resúmenes de monitores. |
get_node | Detalle por nodo: estado, estado inactivo por ejecutor, etiquetas, datos completos del monitor. |
list_queue | Lista elementos pendientes de la cola de Jenkins con la razón de bloqueo de cada uno. |
cancel_queue_item | Elimina un elemento pendiente de la cola por id. Mutante; suprimido cuando JENKINS_MCP_READONLY está establecido. |
trigger_build | Pone en cola un build, opcionalmente con parámetros; puede bloquear hasta que el build reciba un número. Mutante. |
stop_build | Aborta un build en ejecución. Mutante. |
Las herramientas dirigidas a builds toman un job_path (separado por barras, p. ej. Builds/team/job-name) y un build_number opcional (0 u omitido = lastBuild). Una URL como https://jenkins.example.com/job/Builds/job/team/job/job-name/86/ se convierte en job_path="Builds/team/job-name", build_number=86. list_jobs toma un folder_path en la misma forma separada por barras (vacío = raíz).
Consulta docs/TOOLS.md para la referencia completa de parámetros.
Instalación
Binarios precompilados
Toma el archivo para tu sistema operativo y arquitectura desde la página de Releases y coloca el binario jenkins-mcp en tu PATH.
Vía go install
go install github.com/2001adarsh/jenkins-mcp-go@latest
El binario se coloca en $(go env GOBIN) (o $(go env GOPATH)/bin).
Vía Docker
Imágenes multi-arquitectura precompiladas se publican en GitHub Container Registry:
docker pull ghcr.io/2001adarsh/jenkins-mcp-go:latest
Etiquetas:
:latest— la versión más reciente:vX.Y.Z— fijada a una versión específica:vX.Y.Z-amd64/:vX.Y.Z-arm64— por arquitectura (las etiquetas sin sufijo anteriores son manifiestos multi-arquitectura;docker pullresuelve la correcta automáticamente)
La imagen está construida sobre gcr.io/distroless/static:nonroot — se ejecuta como un usuario no root, incluye raíces de CA para que HTTPS a Jenkins funcione de inmediato, y pesa menos de 20 MB comprimida. Consulta la sección de configuración del cliente MCP Docker para una configuración de Claude Desktop basada en docker run.
Desde el código fuente
git clone https://github.com/2001adarsh/jenkins-mcp-go.git
cd jenkins-mcp-go
make build
./bin/jenkins-mcp -h 2>/dev/null || true # the server speaks MCP over stdio; -h prints nothing
Configuración
La configuración se lee del entorno al inicio. No hay archivo de configuración ni banderas de línea de comandos — mantén las credenciales fuera de los argumentos del proceso.
| Variable | Requerida | Predeterminado | Descripción |
|---|---|---|---|
JENKINS_URL | sí | — | URL base de la instancia de Jenkins, p. ej. https://jenkins.example.com. |
JENKINS_USER | sí | — | Nombre de usuario para autenticación HTTP Basic. |
JENKINS_API_TOKEN | sí | — | Token de API (no la contraseña). Genera uno en /me/configure en tu interfaz de Jenkins. |
JENKINS_MCP_CACHE_DIR | no | $XDG_CACHE_HOME/jenkins-mcp (o ~/.cache/jenkins-mcp) | Dónde se almacenan en caché en disco los registros de builds finalizados. |
JENKINS_MCP_CACHE_MAX | no | 1073741824 (1 GiB) | Límite suave del tamaño de la caché en bytes. Desaloja primero los archivos con mtime más antiguo. |
JENKINS_MCP_TIMEOUT | no | 90s | Tiempo de espera HTTP (duración Go: 30s, 2m, etc.). |
JENKINS_MCP_DEBUG | no | sin establecer | Cuando se establece a cualquier valor no vacío, emite una línea de stderr por cada solicitud saliente a Jenkins y evento de caché. Consulta docs/DEBUGGING.md. |
JENKINS_MCP_READONLY | no | sin establecer | Cuando es verdadero (1/true/yes, insensible a mayúsculas), suprime el registro de cualquier herramienta que mute el estado de Jenkins. El modo activo se registra al inicio. |
Nota —
JENKINS_API_TOKENdebe ser un token de API de Jenkins, no la contraseña de tu cuenta. En Jenkins, navega a tu menú de usuario → Configurar → Token de API → Agregar nuevo token.
Configuración del cliente MCP
El servidor habla MCP sobre stdio. Conéctalo agregando una entrada a la configuración del servidor MCP de tu cliente.
Claude Desktop — ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) o %APPDATA%\Claude\claude_desktop_config.json (Windows)
{
"mcpServers": {
"jenkins": {
"command": "/usr/local/bin/jenkins-mcp",
"env": {
"JENKINS_URL": "https://jenkins.example.com",
"JENKINS_USER": "your-username",
"JENKINS_API_TOKEN": "your-api-token"
}
}
}
}
Claude Desktop vía Docker — mismo archivo de configuración, sin binario en PATH requerido
{
"mcpServers": {
"jenkins": {
"command": "docker",
"args": [
"run", "--rm", "-i",
"-e", "JENKINS_URL",
"-e", "JENKINS_USER",
"-e", "JENKINS_API_TOKEN",
"ghcr.io/2001adarsh/jenkins-mcp-go:latest"
],
"env": {
"JENKINS_URL": "https://jenkins.example.com",
"JENKINS_USER": "your-username",
"JENKINS_API_TOKEN": "your-api-token"
}
}
}
}
-i mantiene stdin abierto (MCP habla stdio); --rm limpia el contenedor después de que Claude Desktop se desconecte. La caché de registros de consola vive dentro del contenedor por defecto, por lo que se pierde al reiniciar — agrega -v "$HOME/.cache/jenkins-mcp:/home/nonroot/.cache/jenkins-mcp" y -e XDG_CACHE_HOME=/home/nonroot/.cache al arreglo args si quieres que la caché sobreviva entre sesiones.
Claude Code (CLI)
claude mcp add jenkins /usr/local/bin/jenkins-mcp \
--env JENKINS_URL=https://jenkins.example.com \
--env JENKINS_USER=your-username \
--env JENKINS_API_TOKEN=your-api-token
Cursor / Continue / cualquier otro cliente MCP
Cualquier cliente que admita servidores MCP stdio aceptará una configuración de la forma:
{
"command": "jenkins-mcp",
"args": [],
"env": {
"JENKINS_URL": "https://jenkins.example.com",
"JENKINS_USER": "your-username",
"JENKINS_API_TOKEN": "your-api-token"
}
}
Sesión de ejemplo
Una vez que el servidor esté registrado, pregúntale a tu agente cosas como:
- "¿Qué trabajos de pruebas de integración tenemos bajo
Builds/team?" → llama alist_jobsconfolder_path: "Builds/team",recursive: true,name_filter: "integration". - "¿Cuál fue el resultado de la compilación 86 de
Builds/team/integration-tests?" → llama aget_build_info. - "Muéstrame las últimas 200 líneas de la ejecución más reciente de
nightly." → llama aget_console_logcontail_lines: 200. - "Encuentra cada línea que coincida con
panic|fatalen la compilación 4521 con cinco líneas de contexto." → llama asearch_console_logconpattern: "panic|fatal",context_lines: 5. - "La compilación 91 pasó pero la 92 falló — ¿qué cambió?"
→ llama a
compare_buildsconbuild_a: 91,build_b: 92. - "¿Qué pruebas en
Builds/team/integration-testshan estado alternando entre pasar y fallar recientemente?" → llama aget_flaky_candidates. - "¿Qué commits en la compilación 86 tocaron algo bajo
internal/auth/?" → llama aget_scm_contextconpath_filter: "^internal/auth/". - "¿Qué especificaciones de Ginkgo fallaron en la compilación 92 y cuál fue el primer error que emitió cada una?"
→ llama a
get_ginkgo_failure_summary. - "Almacena en caché el registro completo de la compilación 4521 para poder buscar en él localmente."
→ llama a
get_console_log_path; el agente luego usa sus propias herramientasRead/Grep/Bashen la ruta devuelta.
Almacenamiento en caché
Solo las compilaciones finalizadas se almacenan en caché (el escritor requiere el marcador Finished:
de Jenkins), y la caché se desaloja por LRU mtime una vez que supera
JENKINS_MCP_CACHE_MAX. Los archivos viven en JENKINS_MCP_CACHE_DIR.
Notas de seguridad
- Sin eco de credenciales. El servidor nunca incluye credenciales en la salida de herramientas, mensajes de error o archivos en caché.
- Límite del sistema de archivos. Los nombres de archivo de la caché se sanean; el directorio de caché es la única ruta a la que el servidor escribe.
Si encuentras un problema de seguridad, sigue SECURITY.md en lugar de abrir un problema público.
Desarrollo
make build / test / lint / fmt. Consulta CONTRIBUTING.md para la
guía completa de contribución y docs/DEBUGGING.md para saber cómo
ejercitar el servidor localmente con MCP Inspector.
Compatibilidad
- Go: 1.23+
- Jenkins: cualquier versión que exponga los endpoints estándar
/api/json,/consoleText,/wfapi/describe,/testReport/api/json. Las herramientas específicas de Pipeline requieren el complemento Pipeline. - MCP: usa
github.com/modelcontextprotocol/go-sdkv1.6+.
Alternativas
Cómo se compara jenkins-mcp-go con otras formas de exponer Jenkins a un LLM:
| Opción | Tiempo de ejecución | Modo de solo lectura | Caché de registro de consola | Herramientas de Pipeline / JUnit / Ginkgo |
|---|---|---|---|---|
jenkins-mcp-go (este repositorio) | Binario Go estático único | Sí, controlado por JENKINS_MCP_READONLY | Caché LRU en disco para compilaciones finalizadas | Respuestas de primera clase, pre-digeridas |
| Servidores MCP de Jenkins basados en Python | Intérprete de Python + dependencias | Varía según el proyecto | Típicamente ninguna — vuelve a buscar en cada llamada | Generalmente paso directo de /api/json sin procesar |
| Puertas de enlace genéricas HTTP a MCP | Tiempo de ejecución de Node / Python | Lo que la puerta de enlace imponga | Ninguna | Ninguna — el agente tiene que analizar JSON sin procesar |
Herramientas directas de curl / shell desde el agente | Shell | Manual | Ninguna | Ninguna — el agente razona sobre texto sin procesar |
Si quieres una superficie pequeña y predecible adaptada a "el agente está depurando una compilación de Jenkins", este proyecto es para ti. Si necesitas un proxy JSON genérico o enrutamiento de credenciales multiinquilino, una puerta de enlace HTTP-MCP genérica es una mejor opción.
Preguntas frecuentes
¿Cómo conecto Jenkins a Claude?
Instala el binario jenkins-mcp, luego agrégalo a tu configuración MCP de Claude Desktop o
Claude Code con tu JENKINS_URL, JENKINS_USER y
JENKINS_API_TOKEN. Consulta Configuración del cliente MCP arriba para
los fragmentos exactos de JSON / CLI.
¿Funciona esto con Cursor, Continue o Windsurf?
Sí. Cualquier cliente MCP que admita servidores stdio aceptará la misma
configuración de command + env que se muestra en la sección Configuración del cliente MCP.
¿El servidor es de solo lectura?
Las lecturas siempre están activadas. Las herramientas de escritura (trigger_build, stop_build,
cancel_queue_item) están registradas por defecto pero se pueden suprimir por completo
estableciendo JENKINS_MCP_READONLY=1 — el servidor entonces nunca registra una
herramienta mutadora, por lo que un agente literalmente no puede llamar a una.
¿Necesito un complemento de Jenkins para usar esto?
No se requiere ningún complemento adicional para las herramientas de lectura principales — acceden a
endpoints estándar de Jenkins. Las herramientas específicas de Pipeline (get_pipeline_stages,
get_stage_log) requieren el complemento Pipeline, que la mayoría de las instalaciones de Jenkins
ya tienen.
¿Puede el agente LLM buscar en un registro de consola de varios gigabytes?
Sí. Usa get_console_log_path para forzar el almacenamiento en caché del registro completo de una
compilación finalizada en disco; la herramienta devuelve una ruta local que el agente puede luego Read,
Grep o Bash de forma nativa. La caché se desaloja por LRU y está limitada por
JENKINS_MCP_CACHE_MAX.
¿Maneja específicamente fallos de pruebas de Ginkgo?
Sí. get_ginkgo_failure_summary analiza el bloque Summarizing N Failure de Ginkgo y
superficie la primera línea [ERROR] etiquetada con el nombre de cada especificación más el contexto
circundante — mucho más rápido que pedirle al agente que escanee todo el registro.
¿Es seguro darle a un LLM acceso al token de API de Jenkins?
El servidor usa el token de API de un solo usuario de Jenkins (no una contraseña), confinado
a un JENKINS_URL. Combínalo con JENKINS_MCP_READONLY=1 y un usuario de Jenkins con
privilegios mínimos para el valor predeterminado más seguro. Consulta SECURITY.md para el
modelo de amenazas completo.
Licencia
MIT © Adarsh Singh