Everything here is scoped to one job path at a time, so it fits the moment a build breaks: ask what happened, read the console output, fix, and trigger again with the same parameters. It does not browse Jenkins for you — you need to know the job path — and it does not manage jobs, credentials or nodes.
A small MCP server over a Jenkins CI/CD server. It covers the three things you actually do when a build is in question: find out whether it passed, kick off a new one with the parameters you want, and read the log when it did not.
- The status of a build, by job path and build number, defaulting to the latest build — `get_build_status`
- A new build triggered on a job, with build parameters passed as key-value pairs such as a branch and a build type — `trigger_build`
- The console output of a build, so a failure can be read and explained rather than opened in a browser — `get_build_log`
A Jenkins server and an API token for a user on it: `JENKINS_URL`, `JENKINS_USER` and `JENKINS_TOKEN`. The npm package name is `jenkins-server` (0.1.0) and it is marked private, so build from a clone with `npm install` and `npm run build`, then point your client at the built `index.js`. The token can start builds, so give it an account with the job permissions you intend and no more.
One command plus a key — npx -y github:hekmon8/Jenkins-server-mcp, then supply credentials