MCP servers that can trigger a CI build

4 verified servers expose a tool that can trigger a CI build or pipeline

A coding agent that just landed a fix often needs the next step too: start the build that proves it. The CI servers expose that as one call, so the agent can kick a job after a merge, rerun a flaky pipeline on demand, or fire the run that gates a deploy.

The four picks below cover Jenkins jobs, CircleCI and Bitbucket pipelines, and Gitea Actions workflows, each with the exact tool that starts the run.

Top pick

Jenkins

kud

Community

A maintained Jenkins MCP server: list jobs, trigger and stop builds, read console logs and test results, and manage nodes from an agent.

devops-ci36
Tool:
  • jenkins_trigger_build

Self-hosted and parameter-aware: jenkins_trigger_build starts a job and accepts build parameters, so the agent can pin a branch or set a flag the job reads rather than running a bare default.

Pick 2

CircleCI

CircleCI

Official

CircleCI's official MCP server: pull build failure logs, find flaky tests, validate config, and run pipelines from an agent.

devops-ci84
Tool:
  • run_pipeline

Built around the pipeline as the unit of work, run_pipeline triggers one to run, the natural entry point when the agent wants to validate a change or rerun after a config edit.

Pick 3

Bitbucket

MatanYemini

Community

A maintained MCP server for Bitbucket Cloud and Server: browse repos, drive pull requests, comments, tasks, and pipelines.

version-control143
Tool:
  • runPipeline

runPipeline starts a new pipeline run inside the same server that opens PRs and adds review tasks, so an agent already working a Bitbucket change can kick CI without switching tools.

Pick 4

Gitea

Gitea

Official

Gitea's official MCP server for repos, branches, issues, pull request reviews, releases, Actions, and wikis on any Gitea instance.

version-control73
Tool:
  • dispatch_repo_action_workflow

For self-hosted Gitea, dispatch_repo_action_workflow fires a repository Actions workflow, the workflow_dispatch trigger a maintainer would otherwise click in the UI.

What to know

Most of these take parameters at trigger time, so the agent isn't limited to a default run. Jenkins accepts build parameters on jenkins_trigger_build, which lets the agent pin a branch or flip a flag the job reads. CircleCI and Bitbucket start a pipeline as configured in the repo; Gitea dispatches a named Actions workflow, the workflow_dispatch event a human would otherwise click. A build trigger is a high-trust action: it consumes runner minutes, and a pipeline that deploys can ship to production. Gate it. Restrict the agent to a non-deploy job, require a confirmation turn before the trigger fires, or scope the credential to a single repo so a wrong call can't reach more than one pipeline.

The trigger itself is fire-and-forget, but the reason behind it rarely is. An agent that recorded which commit it was validating, or that the last run on this branch failed on the same integration test, decides whether a retrigger is worth the runner minutes instead of blindly restarting. That context lives outside the CI server, which only knows the run exists.

Questions

Can the agent pass parameters when it triggers the build?
On Jenkins, yes: jenkins_trigger_build takes optional build parameters, so the agent can set a branch, environment, or feature flag the job reads. CircleCI's run_pipeline and Bitbucket's runPipeline start the pipeline as the repo configures it, and Gitea dispatches a named workflow. When you need per-run inputs, the Jenkins tool is the most explicit about it.
Should an agent be allowed to trigger builds unsupervised?
It depends on what the pipeline does. A test-only job is low-stakes; it burns runner minutes and nothing more. A pipeline that deploys is a different matter, because triggering it can ship to production, so scope the credential to a single repo, point the agent at a non-deploy job, or require a confirmation turn before the trigger call goes through.