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.

Go Reference Go Report Card CI Release License: MIT


¿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 por JENKINS_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_path devuelve la ruta en disco del registro de un build finalizado para que el agente pueda Read/Grep/Bash de 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/json y el bloque Summarizing N Failure de 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

HerramientaPropósito
health_checkValida 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_versionsLista 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_canSondea 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_jobsEnumera 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_branchesEnumera 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_logMuestra el final del /consoleText del build. Por defecto las últimas 500 líneas; pasa tail_lines: -1 para el registro completo.
get_console_log_pathFuerza 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_logBúsqueda de regex RE2 sobre el registro de consola con ventanas de contexto conscientes del número de línea.
tail_running_buildCola 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_infoResumen del build con formato bonito: resultado, duración, parámetros, conjunto de cambios.
get_build_environmentTres 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_contextHistorial 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_buildInforma 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_greenUne 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_buildsCompara 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_stagesLista las etapas de Pipeline Declarativo/Scriptado vía /wfapi/describe con estado y duración.
get_stage_logObtiene el registro de una sola etapa de pipeline vía /execution/node/<id>/wfapi/log.
get_pipeline_scriptDevuelve 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_reportResultados JUnit estructurados de /testReport/api/json, con casos fallidos y cabeza+cola de los stack traces.
get_flaky_candidatesClasifica 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_historyTendencia 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_nameLocaliza 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_failuresExamina 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_buildsLista 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_summaryAnaliza el bloque Summarizing N Failure de Ginkgo y muestra el primer [ERROR] etiquetado con cada nombre de especificación.
list_nodesLista agentes/nodos de Jenkins con estado, conteos de ejecutores, etiquetas y resúmenes de monitores.
get_nodeDetalle por nodo: estado, estado inactivo por ejecutor, etiquetas, datos completos del monitor.
list_queueLista elementos pendientes de la cola de Jenkins con la razón de bloqueo de cada uno.
cancel_queue_itemElimina un elemento pendiente de la cola por id. Mutante; suprimido cuando JENKINS_MCP_READONLY está establecido.
trigger_buildPone en cola un build, opcionalmente con parámetros; puede bloquear hasta que el build reciba un número. Mutante.
stop_buildAborta 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 pull resuelve 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.

VariableRequeridaPredeterminadoDescripción
JENKINS_URLURL base de la instancia de Jenkins, p. ej. https://jenkins.example.com.
JENKINS_USERNombre de usuario para autenticación HTTP Basic.
JENKINS_API_TOKENToken de API (no la contraseña). Genera uno en /me/configure en tu interfaz de Jenkins.
JENKINS_MCP_CACHE_DIRno$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_MAXno1073741824 (1 GiB)Límite suave del tamaño de la caché en bytes. Desaloja primero los archivos con mtime más antiguo.
JENKINS_MCP_TIMEOUTno90sTiempo de espera HTTP (duración Go: 30s, 2m, etc.).
JENKINS_MCP_DEBUGnosin establecerCuando 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_READONLYnosin establecerCuando 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.

NotaJENKINS_API_TOKEN debe ser un token de API de Jenkins, no la contraseña de tu cuenta. En Jenkins, navega a tu menú de usuario → ConfigurarToken de APIAgregar 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 a list_jobs con folder_path: "Builds/team", recursive: true, name_filter: "integration".
  • "¿Cuál fue el resultado de la compilación 86 de Builds/team/integration-tests?" → llama a get_build_info.
  • "Muéstrame las últimas 200 líneas de la ejecución más reciente de nightly." → llama a get_console_log con tail_lines: 200.
  • "Encuentra cada línea que coincida con panic|fatal en la compilación 4521 con cinco líneas de contexto." → llama a search_console_log con pattern: "panic|fatal", context_lines: 5.
  • "La compilación 91 pasó pero la 92 falló — ¿qué cambió?" → llama a compare_builds con build_a: 91, build_b: 92.
  • "¿Qué pruebas en Builds/team/integration-tests han estado alternando entre pasar y fallar recientemente?" → llama a get_flaky_candidates.
  • "¿Qué commits en la compilación 86 tocaron algo bajo internal/auth/?" → llama a get_scm_context con path_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 herramientas Read/Grep/Bash en 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-sdk v1.6+.

Alternativas

Cómo se compara jenkins-mcp-go con otras formas de exponer Jenkins a un LLM:

OpciónTiempo de ejecuciónModo de solo lecturaCaché de registro de consolaHerramientas de Pipeline / JUnit / Ginkgo
jenkins-mcp-go (este repositorio)Binario Go estático únicoSí, controlado por JENKINS_MCP_READONLYCaché LRU en disco para compilaciones finalizadasRespuestas de primera clase, pre-digeridas
Servidores MCP de Jenkins basados en PythonIntérprete de Python + dependenciasVaría según el proyectoTípicamente ninguna — vuelve a buscar en cada llamadaGeneralmente paso directo de /api/json sin procesar
Puertas de enlace genéricas HTTP a MCPTiempo de ejecución de Node / PythonLo que la puerta de enlace impongaNingunaNinguna — el agente tiene que analizar JSON sin procesar
Herramientas directas de curl / shell desde el agenteShellManualNingunaNinguna — 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