What can you do with this server?

The MCP-Jenkins server enables comprehensive management and monitoring of Jenkins CI/CD pipelines from compatible clients, without needing to access the Jenkins UI. Job Management * List jobs at the root level, within folders, or for multibranch projects * Retrieve job details and config.xml configuration * Create pipeline jobs from XML, or update, enable, disable, and delete existing jobs * List Git branches for multibranch or legacy jobs Build Execution & Monitoring * Start new builds (with optional parameters), stop running builds, rebuild, or replay builds * List recent builds and retrieve detailed info for a specific build * View console logs and list/access archived build artifacts * Wait/block until a build completes, times out, or requires manual input (optionally returning pipeline stages) Pipeline Specifics * Inspect pipeline stages and steps for a build * Get detailed status for individual pipeline nodes/stages * Query pending manual input actions blocking a pipeline * Submit approval or rejection decisions for pending inputs Code Coverage * Retrieve summary coverage reports for a build * Fetch line-by-line coverage details for specific files * List all file paths with available coverage data

Which integrations are available for this server?

Provides access to Git repository information, specifically for listing available branches that can be used for Jenkins builds. Enables interaction with Jenkins CI/CD, providing tools for managing jobs, monitoring builds, handling input actions, viewing code coverage reports, and accessing Git branches for builds.

How do I use MCP-Jenkins?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP-Jenkins show me the status of the 'backend-api' job" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP-Jenkins

by gcorroto

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

@grec0/mcp-jenkins

MCP server para operar Jenkins desde clientes compatibles con Model Context Protocol, como VS Code, Claude Desktop u otros agentes. Permite consultar jobs, lanzar builds, esperar a que terminen, revisar logs, inspeccionar stages de pipelines, gestionar approvals, consultar artifacts/cobertura y administrar jobs sin entrar en la UI de Jenkins.

Que Puedes Hacer

Listar jobs, multibranch projects y ramas.
Consultar estado, configuracion y ultimo build de un job.
Lanzar builds con o sin parametros.
Esperar de forma bloqueante hasta que un build termine.
Ver historial de builds, logs, stages, nodos y acciones pendientes.
Detener builds con confirmacion explicita.
Hacer rebuild/replay si Jenkins tiene los endpoints/plugins necesarios.
Crear, actualizar, habilitar, deshabilitar o borrar jobs usando confirmaciones de seguridad.
Consultar reportes de cobertura cuando el job los publique.

Related MCP server: Jenkins MCP Server

Quick Start

Requisitos

Node.js 18 o superior.
URL de Jenkins accesible desde la maquina donde corre el cliente MCP.
Usuario de Jenkins con permisos suficientes.
API token o password de Jenkins.

Usa API tokens cuando sea posible. No guardes credenciales reales en repositorios ni compartas configuraciones con secretos.

Configuracion Recomendada Con npx

{
  "servers": {
    "jenkins": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "--package", "@grec0/mcp-jenkins@latest", "mcp-jenkins"],
      "env": {
        "JENKINS_URL": "https://tu-jenkins.com/jenkins",
        "JENKINS_USERNAME": "tu-usuario",
        "JENKINS_PASSWORD": "tu-api-token"
      }
    }
  }
}

Para fijar una version concreta, cambia @latest por una version publicada:

"args": ["-y", "--package", "@grec0/mcp-jenkins@0.2.2", "mcp-jenkins"]

Instalacion Global Opcional

npm install -g @grec0/mcp-jenkins

Configuracion usando el binario global:

{
  "servers": {
    "jenkins": {
      "type": "stdio",
      "command": "mcp-jenkins",
      "env": {
        "JENKINS_URL": "https://tu-jenkins.com/jenkins",
        "JENKINS_USERNAME": "tu-usuario",
        "JENKINS_PASSWORD": "tu-api-token"
      }
    }
  }
}

Conceptos Basicos

`fullName`

La mayoria de herramientas nuevas usan fullName, que es la ruta logica del job en Jenkins.

Ejemplos:

Grec0AI_backend_sb
Grec0AI_backend_sb/main
folder/backend/main

En un multibranch project, normalmente el primer nivel es el proyecto y el segundo nivel es la rama. Por ejemplo, si Jenkins muestra:

Grec0AI_backend_sb / main

el fullName suele ser:

Grec0AI_backend_sb/main

`app` y `branch`

Las tools antiguas usan app y branch. Siguen disponibles por compatibilidad, pero para uso nuevo se recomienda usar los managers basados en fullName.

Managers vs Tools Simples

Usa jenkins_job_manager para jobs y pipelines.
Usa jenkins_build_manager para ejecuciones/builds.
Usa jenkins_wait_for_build cuando un agente deba esperar a Jenkins antes de continuar.
Usa jenkins_pipeline_monitor para stages, nodos e inputs pendientes.
Usa las tools jenkins_get_*, jenkins_start_job y jenkins_stop_job si ya tienes prompts antiguos basados en app y branch.

Flujos Recomendados

Descubrir Jobs

{
  "action": "list",
  "limit": 20
}

Tool: jenkins_job_manager

Listar Ramas De Un Multibranch Project

{
  "action": "list",
  "folder": "Grec0AI_backend_sb",
  "limit": 20
}

Tool: jenkins_job_manager

Lanzar Un Build Y Esperar A Que Termine

Inicia el build.

{
  "action": "start",
  "fullName": "Grec0AI_backend_sb/main"
}

Tool: jenkins_build_manager

Lista builds para identificar el numero iniciado.

{
  "action": "list",
  "fullName": "Grec0AI_backend_sb/main",
  "limit": 5
}

Tool: jenkins_build_manager

Espera hasta que Jenkins termine.

{
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298,
  "pollIntervalSeconds": 10,
  "timeoutSeconds": 1800,
  "includeStages": true
}

Tool: jenkins_wait_for_build

Solo despues de recibir completed: true, revisa logs, stages o ejecuta validaciones dependientes del build.

Revisar Un Fallo

{
  "action": "console",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298,
  "limit": 8000
}

Tool: jenkins_build_manager

{
  "action": "steps",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298
}

Tool: jenkins_pipeline_monitor

Aprobar O Rechazar Un Input Pendiente

Consulta inputs pendientes.

{
  "action": "pending_inputs",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298
}

Tool: jenkins_pipeline_monitor

Envia la decision usando la proceedUrl o abortUrl devuelta por Jenkins.

{
  "action": "submit_input",
  "decisionUrl": "https://tu-jenkins.com/jenkins/job/.../proceedEmpty"
}

Tool: jenkins_pipeline_monitor

Tools

`jenkins_job_manager`

Gestiona jobs y pipelines usando rutas fullName.

Acciones:

Accion	Descripcion
`list`	Lista jobs del root o de un folder/multibranch project.
`get`	Obtiene detalle de un job.
`get_config`	Devuelve el `config.xml` de un job.
`create_pipeline`	Crea un job/pipeline desde XML.
`update_config`	Actualiza `config.xml`; requiere `confirmName`.
`delete`	Borra un job; requiere `confirmName`.
`enable`	Habilita un job; requiere `confirmName`.
`disable`	Deshabilita un job; requiere `confirmName`.
`get_branches`	Lista ramas usando el flujo legacy basado en `app`.

Parametros:

Parametro	Uso
`action`	Accion a ejecutar.
`fullName`	Ruta del job, por ejemplo `folder/job/main`.
`folder`	Folder o multibranch project desde el que listar.
`query`	Filtro por texto para `list`.
`limit`	Maximo de resultados para `list`.
`configXml`	XML completo para crear o actualizar jobs.
`confirmName`	Confirmacion exacta para acciones protegidas.
`app`	Nombre de aplicacion para `get_branches`.

Ejemplos:

{
  "action": "list",
  "query": "backend",
  "limit": 20
}

{
  "action": "get",
  "fullName": "Grec0AI_backend_sb/main"
}

{
  "action": "get_config",
  "fullName": "Grec0AI_backend_sb/main"
}

{
  "action": "update_config",
  "fullName": "sandbox/test-pipeline",
  "configXml": "<flow-definition>...</flow-definition>",
  "confirmName": "sandbox/test-pipeline"
}

{
  "action": "delete",
  "fullName": "sandbox/test-pipeline",
  "confirmName": "sandbox/test-pipeline"
}

`jenkins_build_manager`

Gestiona ejecuciones de Jenkins.

Acciones:

Accion	Descripcion
`list`	Lista builds recientes de un job.
`get`	Obtiene detalle de un build.
`start`	Inicia un build, opcionalmente con parametros.
`wait`	Espera hasta que un build termine o alcance timeout.
`stop`	Detiene un build; requiere `confirmBuild`.
`rebuild`	Solicita reconstruccion si Jenkins expone el endpoint.
`replay`	Solicita replay si Jenkins expone el endpoint.
`console`	Devuelve logs de consola.
`artifacts`	Lista artifacts archivados con URLs.

Parametros:

Parametro	Uso
`action`	Accion a ejecutar.
`fullName`	Ruta del job.
`buildNumber`	Numero de build para acciones sobre una ejecucion.
`parameters`	Parametros para `buildWithParameters`.
`pollIntervalSeconds`	Intervalo entre consultas para `wait`.
`timeoutSeconds`	Tiempo maximo de espera para `wait`.
`includeStages`	Incluye stages al terminar el build.
`limit`	Cantidad de builds o caracteres de log.
`start`	Offset para logs progresivos.
`confirmBuild`	Confirmacion exacta para `stop`.

Ejemplos:

{
  "action": "list",
  "fullName": "Grec0AI_backend_sb/main",
  "limit": 10
}

{
  "action": "start",
  "fullName": "Grec0AI_backend_sb/main",
  "parameters": {
    "DEPLOY_ENV": "dev"
  }
}

{
  "action": "wait",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298,
  "pollIntervalSeconds": 10,
  "timeoutSeconds": 1800,
  "includeStages": true
}

{
  "action": "console",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298,
  "limit": 12000
}

{
  "action": "stop",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298,
  "confirmBuild": 298
}

`jenkins_wait_for_build`

Tool dedicada para agentes que necesitan bloquear el flujo hasta que Jenkins termine un build. La llamada responde cuando el build finaliza, cuando se alcanza el timeout o cuando Jenkins entra en una pausa manual (input) que requiere aprobación.

Parametros:

Parametro	Default	Descripcion
`fullName`	Requerido	Ruta del job.
`buildNumber`	Requerido	Numero de build a esperar.
`pollIntervalSeconds`	`10`	Segundos entre consultas. Minimo efectivo: 2. Maximo efectivo: 120.
`timeoutSeconds`	`1800`	Timeout total. Maximo efectivo: 86400.
`includeStages`	`true`	Incluye stages al terminar si el job expone Pipeline REST API.

Ejemplo:

{
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298,
  "pollIntervalSeconds": 10,
  "timeoutSeconds": 1800,
  "includeStages": true
}

Respuesta esperada:

{
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298,
  "completed": true,
  "timedOut": false,
  "waitedSeconds": 120,
  "pollCount": 13,
  "result": "SUCCESS",
  "build": { "number": 298 },
  "stages": []
}

Si Jenkins queda pausado esperando aprobación manual, la tool devuelve waitingForInput: true, el objeto pendingInput con proceedUrl/abortUrl y un nextStep con la llamada exacta a jenkins_submit_input_action.

Si timedOut es true, el build seguía corriendo cuando se alcanzó el timeout.

`jenkins_pipeline_monitor`

Inspecciona detalles especificos de pipelines.

Acciones:

Accion	Descripcion
`steps`	Devuelve stages del build.
`node`	Devuelve detalle de un nodo/stage por `nodeId`.
`pending_inputs`	Devuelve input actions pendientes.
`submit_input`	Envia una decision usando `decisionUrl`.

Ejemplos:

{
  "action": "steps",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 296
}

{
  "action": "node",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 296,
  "nodeId": "20"
}

{
  "action": "pending_inputs",
  "fullName": "Grec0AI_backend_sb/main",
  "buildNumber": 298
}

{
  "action": "submit_input",
  "decisionUrl": "https://tu-jenkins.com/jenkins/job/.../proceedEmpty"
}

Tools Simples Y Compatibilidad

Estas tools siguen disponibles para prompts antiguos o flujos simples basados en app y branch.

Tool	Uso
`jenkins_get_job_status`	Estado de un job por `app` y `branch`.
`jenkins_start_job`	Inicia un job con una rama.
`jenkins_stop_job`	Detiene un build por `app`, `branch` y `buildNumber`.
`jenkins_get_build_steps`	Stages de un build.
`jenkins_get_node_status`	Estado de un nodo de pipeline.
`jenkins_get_pending_actions`	Input actions pendientes.
`jenkins_submit_input_action`	Envia approval/reject usando una URL de Jenkins.
`jenkins_get_coverage_report`	Resumen de cobertura.
`jenkins_get_coverage_lines`	Cobertura de un archivo.
`jenkins_get_coverage_paths`	Paths con cobertura disponible.
`jenkins_get_git_branches`	Ramas Git disponibles para un job legacy.

Ejemplo legacy:

{
  "app": "mi-app",
  "branch": "main"
}

Operaciones Protegidas

Algunas acciones pueden cambiar o destruir configuracion en Jenkins. El MCP exige confirmacion explicita.

Accion	Confirmacion
`jenkins_job_manager.update_config`	`confirmName` debe ser igual a `fullName`.
`jenkins_job_manager.delete`	`confirmName` debe ser igual a `fullName`.
`jenkins_job_manager.enable`	`confirmName` debe ser igual a `fullName`.
`jenkins_job_manager.disable`	`confirmName` debe ser igual a `fullName`.
`jenkins_build_manager.stop`	`confirmBuild` debe ser igual a `buildNumber`.

Recomendacion: prueba primero create_pipeline, update_config y delete en un job temporal.

Requisitos De Jenkins

Funcionalidad disponible con Jenkins core:

Listar jobs.
Consultar job/build.
Iniciar builds.
Detener builds.
Leer logs.
Leer y actualizar config.xml si el usuario tiene permisos.
Listar artifacts archivados.

Plugins recomendados para funcionalidad completa:

Plugin	Para Que Sirve
`pipeline-rest-api`	Stages, nodos e input actions de pipelines.
`git-parameter`	Listado de ramas en tools legacy.
`jacoco`	Cobertura backend Java.
Cobertura frontend/Istanbul	Cobertura frontend si el job publica el ZIP esperado.

Consulta JENKINS_REQUIREMENTS.md para detalle de plugins, endpoints y errores comunes.

Respuestas Y Limites

Las tools devuelven JSON serializado como contenido de texto MCP.
console puede limitar logs con limit para evitar respuestas enormes.
artifacts devuelve metadata y URLs; no descarga binarios por defecto.
coverage depende mucho de como el job publique sus reportes.
jenkins_wait_for_build mantiene la llamada abierta hasta fin de build, timeout o pausa manual con input pendiente; ajusta timeoutSeconds para builds largos.

Troubleshooting

`ERR_MODULE_NOT_FOUND` con `zod-to-json-schema`

Si ves un error parecido a:

Cannot find module '.../zod-to-json-schema/dist/esm/parsers/record.js'

usa una version reciente del paquete y preferiblemente arranca con --package:

"args": ["-y", "--package", "@grec0/mcp-jenkins@latest", "mcp-jenkins"]

Si npx quedo con una instalacion temporal contaminada, borra la carpeta _npx que aparece en el stacktrace o limpia el cache de npm.

`401` O `403`

Revisa JENKINS_USERNAME, JENKINS_PASSWORD, API token y permisos del usuario en Jenkins.

`404` En `/wfapi/describe`

El job puede no ser Pipeline o puede faltar el plugin pipeline-rest-api.

No Encuentro El `fullName`

Primero lista jobs desde el root:

{
  "action": "list",
  "limit": 50
}

Despues lista dentro del multibranch project:

{
  "action": "list",
  "folder": "nombre-del-proyecto",
  "limit": 50
}

`jenkins_wait_for_build` Agota Timeout

El build seguía corriendo. Sube timeoutSeconds, revisa logs con console o consulta el build con jenkins_build_manager get. Si la respuesta incluye waitingForInput: true, aprueba o aborta con jenkins_submit_input_action usando la decisionUrl devuelta.

Desarrollo Local

Esta seccion es solo para quienes quieran modificar el paquete.

npm install
npm run build
npm test
npm run prerelease

No publiques una version nueva sin ejecutar npm run prerelease.

Licencia

MIT

Available Tools

11 tools

jenkins_get_build_stepsC

Obtener el estado de los steps de un build específico

ParametersJSON Schema

Name	Required	Description
`app`	Yes	Nombre de la aplicación
`buildNumber`	Yes	Número del build
`branch`	No	Rama de Git (por defecto: main)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states it retrieves status but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'estado' entails (e.g., success/failure, duration). This is a significant gap for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every word earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'estado' includes (e.g., step names, outcomes, logs) or address complexity like handling multiple builds. For a tool with 3 parameters and no structured output, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents all three parameters (app, buildNumber, branch). The description adds no additional meaning beyond what the schema provides, such as clarifying how 'app' relates to Jenkins jobs or the format of 'estado'. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Obtener el estado de los steps de un build específico' clearly states the action (obtener/retrieve) and resource (steps de un build específico). It distinguishes from siblings like 'jenkins_get_job_status' by focusing on build steps rather than job status, though it doesn't explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or refer to sibling tools like 'jenkins_get_job_status' for broader job information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_get_coverage_linesC

Obtener líneas de cobertura de un archivo específico

ParametersJSON Schema

Name	Required	Description
`app`	Yes	Nombre de la aplicación
`buildNumber`	Yes	Número del build
`path`	Yes	Ruta del archivo
`branch`	No	Rama de Git (por defecto: main)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It lacks details on permissions, rate limits, error handling, or output format, which are critical for a tool with 4 parameters and no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence in Spanish that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what 'coverage lines' means, the format of the output, or behavioral aspects like authentication or errors, leaving significant gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying the 'path' parameter targets a specific file, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Obtener líneas de cobertura de un archivo específico' clearly states the action (obtener/get) and resource (líneas de cobertura/coverage lines) with specificity about targeting a file. It distinguishes from siblings like jenkins_get_coverage_paths (which gets paths) and jenkins_get_coverage_report (which gets a report), but doesn't explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_get_coverage_pathsC

Obtener todos los paths de archivos con cobertura

ParametersJSON Schema

Name	Required	Description
`app`	Yes	Nombre de la aplicación
`buildNumber`	Yes	Número del build
`branch`	No	Rama de Git (por defecto: main)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states it's a read operation ('obtener'), implying it's non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what the output format looks like (e.g., list of paths). This is a significant gap for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a Jenkins coverage tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects, usage context, and output format, which are crucial for an AI agent to invoke it correctly. The description should compensate for the missing structured data but doesn't.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters (app, buildNumber, branch) with descriptions. The description doesn't add any meaning beyond what the schema provides, such as explaining how these parameters interact or affect the results. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('obtener todos los paths de archivos') and the resource ('con cobertura'), which translates to 'get all file paths with coverage'. It specifies the verb and resource, but doesn't differentiate from sibling tools like 'jenkins_get_coverage_lines' or 'jenkins_get_coverage_report', which also deal with coverage data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools or contexts where this specific tool is appropriate, such as distinguishing it from 'jenkins_get_coverage_lines' for line-level details or 'jenkins_get_coverage_report' for summary reports.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_get_coverage_reportC

Obtener reporte de cobertura de código de un build

ParametersJSON Schema

Name	Required	Description
`app`	Yes	Nombre de la aplicación
`buildNumber`	Yes	Número del build
`packageName`	No	Nombre del paquete específico
`className`	No	Nombre de la clase específica
`branch`	No	Rama de Git (por defecto: main)

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a read operation ('obtener'), but doesn't describe what format the coverage report returns, whether it includes summary vs detailed data, if it requires specific permissions, or any rate limits. For a tool with 5 parameters and no output schema, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient Spanish sentence that gets straight to the point. It's appropriately sized for a tool with clear parameters in the schema. While it could be more informative, it doesn't waste words or include unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, no annotations, no output schema, and multiple similar siblings, the description is insufficient. It doesn't explain what type of coverage data is returned, how it differs from other coverage tools, or provide context about the Jenkins coverage reporting system. The agent would struggle to understand when and how to use this tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond implying this tool retrieves coverage reports for builds. It doesn't explain relationships between parameters (e.g., how packageName and className refine the report) or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Obtener reporte de cobertura de código de un build' clearly states the action (obtener/get) and resource (reporte de cobertura de código/coverage report), but it's vague about scope and doesn't differentiate from siblings like jenkins_get_coverage_lines or jenkins_get_coverage_paths. It specifies 'de un build' which helps somewhat, but doesn't clarify what type of coverage report this returns versus other coverage-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple coverage-related siblings (jenkins_get_coverage_lines, jenkins_get_coverage_paths), there's no indication of what distinguishes this general 'reporte' from those more specific tools. No prerequisites, exclusions, or comparison context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_get_git_branchesC

Obtener las ramas de Git disponibles para un job

ParametersJSON Schema

Name	Required	Description	Default
`app`	Yes	Nombre de la aplicación

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves Git branches for a job, implying a read-only operation, but doesn't specify whether it requires authentication, rate limits, error handling, or the format of the returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence in Spanish: 'Obtener las ramas de Git disponibles para un job'. It is front-loaded with the core purpose, has no redundant information, and efficiently communicates the tool's function without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (retrieving Git branches from Jenkins), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned, potential errors, or dependencies on Jenkins job configurations. For a tool interacting with version control in a CI/CD system, more context is needed to ensure proper usage by an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with one parameter 'app' documented as 'Nombre de la aplicación' (Name of the application). The description adds no additional semantic details beyond what the schema provides, such as clarifying what 'app' refers to in the Jenkins context or how it relates to the job. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Obtener las ramas de Git disponibles para un job' (Get the available Git branches for a job). It specifies the verb 'obtener' (get) and the resource 'ramas de Git' (Git branches) with the context 'para un job' (for a job). However, it doesn't explicitly differentiate from sibling tools like 'jenkins_get_job_status' or 'jenkins_get_build_steps', which focus on different aspects of Jenkins jobs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a specific Jenkins job configuration, or compare it to sibling tools like 'jenkins_get_job_status' for job details or 'jenkins_start_job' for job execution. Usage is implied by the purpose but lacks explicit context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_get_job_statusC

Obtener el estado de un job específico de Jenkins

ParametersJSON Schema

Name	Required	Description	Default
`app`	Yes	Nombre de la aplicación
`branch`	No	Rama de Git (por defecto: main)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Obtener' - Get), but provides no information about authentication requirements, rate limits, error conditions, or what the status output might include. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient Spanish sentence that directly states the tool's purpose. There's no wasted language, repetition, or unnecessary elaboration. It's appropriately sized for a simple status-checking tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and a read operation that likely returns structured status information, the description is insufficient. It doesn't explain what 'estado' (status) includes, whether it returns simple status strings or complex job metadata, or any error handling. For a tool that presumably returns job status details, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Obtener el estado' - Get status) and target resource ('un job específico de Jenkins' - a specific Jenkins job). It distinguishes from siblings like jenkins_get_node_status (node vs job) and jenkins_get_build_steps (steps vs status), but doesn't explicitly differentiate from all siblings. The purpose is specific and understandable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate versus jenkins_get_node_status or jenkins_get_build_steps, nor does it provide any context about prerequisites or typical use cases. The agent must infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_get_node_statusC

Obtener el estado de un nodo específico de un build

ParametersJSON Schema

Name	Required	Description
`app`	Yes	Nombre de la aplicación
`buildNumber`	Yes	Número del build
`nodeId`	Yes	ID del nodo
`branch`	No	Rama de Git (por defecto: main)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Obtener el estado' implies a read-only operation, the description doesn't address authentication requirements, rate limits, error conditions, or what the status response might contain. For a tool that presumably interacts with a CI/CD system, this lack of behavioral context is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient Spanish sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward status-checking tool and gets directly to the point with no wasted verbiage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what kind of status information is returned, what format it might be in, or how to interpret the results. Given the complexity of Jenkins build systems and the lack of structured metadata, the description should provide more operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'un nodo específico de un build' which relates to the 'nodeId' and 'buildNumber' parameters, but doesn't add meaningful context beyond what the 100% schema coverage already provides. The schema descriptions clearly explain each parameter's purpose, so the description adds minimal value here. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Obtener el estado' - Get status) and resource ('de un nodo específico de un build' - of a specific node of a build), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'jenkins_get_job_status' or 'jenkins_get_build_steps', which would require more specific language about what distinguishes node status from other status checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus other Jenkins status tools, or what context would require checking node status specifically rather than job or build status. The agent receives no usage context beyond the basic purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_get_pending_actionsC

Obtener las acciones pendientes de input de un build

ParametersJSON Schema

Name	Required	Description
`app`	Yes	Nombre de la aplicación
`buildNumber`	Yes	Número del build
`branch`	No	Rama de Git (por defecto: main)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves pending input actions, implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or what 'pending input actions' entail (e.g., user prompts, approvals). This leaves significant gaps in understanding the tool's behavior and constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly. This conciseness is effective for a straightforward retrieval tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a Jenkins tool with no annotations and no output schema, the description is insufficient. It lacks details on what the tool returns (e.g., format of pending actions), error conditions, or how it integrates with sibling tools. For a tool that likely interacts with build processes, more context is needed to ensure proper usage and understanding of results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with clear parameter definitions: 'app' (application name), 'buildNumber' (build number), and 'branch' (Git branch, defaulting to 'main'). The description doesn't add any semantic details beyond this, such as examples or usage context. Since the schema is comprehensive, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Obtener las acciones pendientes de input de un build' clearly states the purpose: to retrieve pending input actions for a build. It uses a specific verb ('Obtener') and resource ('acciones pendientes de input de un build'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'jenkins_get_build_steps' or 'jenkins_submit_input_action', which could handle related actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as when to choose this over 'jenkins_get_build_steps' or how it relates to 'jenkins_submit_input_action'. Without such information, users must infer usage from the tool name and parameters alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_start_jobC

Iniciar un job de Jenkins con una rama específica

ParametersJSON Schema

Name	Required	Description	Default
`app`	Yes	Nombre de la aplicación
`branch`	Yes	Rama de Git a construir

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. 'Iniciar' implies a write/mutation operation that triggers a Jenkins job, but it doesn't disclose behavioral traits like whether this is asynchronous/synchronous, what permissions are required, potential side effects (e.g., resource consumption), or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence in Spanish that directly states the tool's purpose. It's front-loaded with the core action and includes the key constraint. There's no wasted verbiage or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool (starting a Jenkins job) with no annotations and no output schema, the description is incomplete. It doesn't cover what happens after invocation (e.g., returns a build ID, triggers async execution), error handling, or integration with sibling tools. Given the complexity and lack of structured data, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters ('app' and 'branch') clearly documented in the schema. The description adds minimal value beyond the schema by implying these parameters are used to start a job, but doesn't provide additional context like parameter relationships or examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Iniciar' - start) and resource ('job de Jenkins') with a specific constraint ('con una rama específica' - with a specific branch). It distinguishes from siblings like jenkins_stop_job (stop vs start) and jenkins_get_job_status (get vs start), though it doesn't explicitly mention these distinctions. The purpose is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., job must exist), when not to use it (e.g., if job is already running), or refer to sibling tools like jenkins_get_job_status to check status first. Usage is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_stop_jobC

Detener un job de Jenkins en ejecución

ParametersJSON Schema

Name	Required	Description
`app`	Yes	Nombre de la aplicación
`buildNumber`	Yes	Número del build a detener
`branch`	No	Rama de Git (por defecto: main)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Detener' implies a destructive action, it doesn't specify whether this requires special permissions, if the stop is immediate or graceful, what happens to queued builds, or what the response looks like. For a mutation tool with zero annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a tool with a clear, singular purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after stopping a job, what permissions are required, potential side effects, or what the tool returns. The combination of mutation nature and lack of structured documentation creates significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Detener' - stop) and resource ('un job de Jenkins en ejecución' - a running Jenkins job), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'jenkins_get_job_status' or 'jenkins_start_job' beyond the obvious action difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the job must be running), when not to use it, or how it relates to sibling tools like 'jenkins_start_job' or 'jenkins_get_job_status'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jenkins_submit_input_actionC

Enviar una acción de input a Jenkins (aprobar/rechazar)

ParametersJSON Schema

Name	Required	Description	Default
`decisionUrl`	Yes	URL de la decisión (proceedUrl o abortUrl)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool sends an input action but doesn't describe side effects (e.g., whether this modifies build state, requires authentication, or has rate limits), return values, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, return values, error handling, and integration with sibling tools (e.g., relationship to 'jenkins_get_pending_actions'). For a tool that modifies Jenkins state, more context is needed to ensure safe and correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the single parameter 'decisionUrl' documented as 'URL de la decisión (proceedUrl o abortUrl)'. The description adds no additional parameter semantics beyond what the schema provides, such as how to obtain this URL or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Enviar una acción de input') and the target resource ('a Jenkins'), with specific verbs 'aprobar/rechazar' indicating approval/rejection. It distinguishes from siblings like 'jenkins_start_job' or 'jenkins_stop_job' by focusing on input actions rather than job control or status retrieval. However, it doesn't explicitly mention that this is for pending actions, which could be inferred from sibling 'jenkins_get_pending_actions' but isn't stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for Jenkins input actions but doesn't specify prerequisites (e.g., needing a pending action from 'jenkins_get_pending_actions'), exclusions, or comparisons to other tools. This leaves the agent to infer context without clear direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesAug 15, 2025
- First observedjenkins_get_build_steps
- First observedjenkins_get_coverage_lines
- First observedjenkins_get_coverage_paths
- First observedjenkins_get_coverage_report
- First observedjenkins_get_git_branches
- First observedjenkins_get_job_status
- First observedjenkins_get_node_status
- First observedjenkins_get_pending_actions
- First observedjenkins_start_job
- First observedjenkins_stop_job
- First observedjenkins_submit_input_action

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored 2026-04-18 09:40 across 11 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific Jenkins resources and actions, with no overlapping functionality. For example, jenkins_get_coverage_lines and jenkins_get_coverage_paths serve different coverage-related queries, while jenkins_start_job and jenkins_stop_job handle opposite lifecycle actions.

Naming Consistency5/5

All tools follow a perfectly consistent 'jenkins_verb_noun' naming pattern using snake_case throughout. The structure is predictable with the server prefix, action verb, and resource noun clearly separated, making it easy for agents to parse and understand.

Tool Count5/5

With 11 tools, this server is well-scoped for Jenkins CI/CD operations, covering job management, build monitoring, coverage reporting, and input handling. Each tool earns its place without redundancy, providing a comprehensive yet manageable interface for typical Jenkins automation tasks.

Completeness4/5

The toolset covers core Jenkins workflows including job control (start/stop/status), build monitoring (steps/node/actions), and code coverage reporting. Minor gaps exist, such as missing job configuration management or artifact retrieval tools, but agents can accomplish most essential CI/CD operations with this surface.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2605
PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113399

Related MCP Servers

Jenkins Server MCP
CI/CD & DevOps Agent Orchestration
hekmon8
A
license
B
quality
C
maintenance
A Model Context Protocol server that enables AI assistants to interact with Jenkins CI/CD servers, providing tools to check build statuses, trigger builds, and retrieve build logs.
Updated 5 days ago (2026-09-06 14:08 UTC)
3
15
MIT
Jenkins MCP Server
CI/CD & DevOps Developer Tools App Automation
andreimatveyeu
A
license
Not graded
quality
Not graded
maintenance
A Model Context Protocol (MCP) server that enables AI tools like chatbots to interact with and control Jenkins, allowing users to trigger jobs, check build statuses, and perform other Jenkins operations through natural language.
Updated a year ago (2025-05-25 13:08 UTC)
-
Jenkins MCP Server
CI/CD & DevOps Developer Tools
AshwiniGhuge3012
A
license
Not graded
quality
D
maintenance
An MCP server for interacting with a Jenkins CI/CD server. Allows you to trigger jobs, check build statuses, and manage your Jenkins instance through MCP.
Updated a year ago (2025-08-10 09:28 UTC)
23
14
Apache 2.0
jenkins-mcp-server
CI/CD & DevOps Developer Tools
LokiMCPUniverse
F
license
A
quality
D
maintenance
Exposes a Jenkins controller's REST API to MCP-compatible clients, enabling job management, build triggering, and log retrieval through natural language.
Updated 5 months ago (2026-04-18 15:23 UTC)
11
4
-

@grec0/mcp-jenkins

Que Puedes Hacer

Quick Start

Requisitos

Configuracion Recomendada Con npx

Instalacion Global Opcional

Conceptos Basicos

fullName

app y branch

Managers vs Tools Simples

Flujos Recomendados

Descubrir Jobs

Listar Ramas De Un Multibranch Project

Lanzar Un Build Y Esperar A Que Termine

Revisar Un Fallo

Aprobar O Rechazar Un Input Pendiente

Tools

jenkins_job_manager

jenkins_build_manager

jenkins_wait_for_build

jenkins_pipeline_monitor

Tools Simples Y Compatibilidad

Operaciones Protegidas

Requisitos De Jenkins

Respuestas Y Limites

Troubleshooting

ERR_MODULE_NOT_FOUND con zod-to-json-schema

401 O 403

404 En /wfapi/describe

No Encuentro El fullName

jenkins_wait_for_build Agota Timeout

Desarrollo Local

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

`fullName`

`app` y `branch`

`jenkins_job_manager`

`jenkins_build_manager`

`jenkins_wait_for_build`

`jenkins_pipeline_monitor`

`ERR_MODULE_NOT_FOUND` con `zod-to-json-schema`

`401` O `403`

`404` En `/wfapi/describe`

No Encuentro El `fullName`

`jenkins_wait_for_build` Agota Timeout