buildkite/buildkite-mcp-server

> **Model Context Protocol (MCP) server exposing Buildkite data (pipelines, builds, jobs, tests) to AI tooling and editors.**
Full documentation is available at buildkite.com/docs/apis/mcp-server.
---
Retrying builds with limited permissions
The retries toolset supports investigating failures and retrying jobs without
broader build-write access. It includes list_builds, get_build,
wait_for_build, list_jobs, get_job, search_logs, tail_logs, read_logs,
retry_job, and retry_failed_jobs. It requires read_builds,
read_build_logs, and retry_builds scopes, not write_builds.
retry_failed_jobs retries only infrastructure failures; use its dry_run
option to inspect the proposed retries without executing them. retry_job
retries a specific job. Both are mutating tools and are excluded by
--read-only. The toolset does not expose create, rebuild, cancel, or unblock
operations. Existing retry tools remain available in builds; selecting
builds or all still requires write_builds for the other mutations.
The Buildkite API must have the RetryBuildsScope feature enabled for the token
owner to accept retry_builds; existing write_builds tokens remain accepted.
Hosted MCP OAuth can select this toolset using /mcp/x/retries once the hosted
server adopts a release containing it. Selecting toolsets through request
headers does not change an existing token's OAuth scopes.
For library consumers, WithDisabledToolsets and the HTTP factory's disabled
toolsets exclude all members of those toolsets, even through overlapping
groups. For example, disabling logs also removes log tools from retries;
disabling retries removes its inspection and retry tools from other groups.
---
Comparing builds
The read-only compare_builds tool in the investigations toolset answers questions such as “What changed since this build last worked on main?” Supply org_slug, pipeline_slug, and the target build_number. It selects the most recently created earlier build that is currently passed on the same pipeline and exact branch. It does not require that the baseline had already passed when the target started. Supply baseline_build_number to compare against a specific build in that pipeline instead, including a failed build or one on another branch.
The response identifies the baseline and selection rule, counts outcomes across all jobs, and returns up to 100 job comparisons, prioritizing newly failing, recovered, and still-failing steps. Matching uses step keys, job type, matrix values, and parallel index/total. When both jobs lack keys, it falls back to the exact nonblank name plus type, group key, matrix values, and parallel index/total, only when that combination is unique in each build. Matched pairs expose match_method: "step_key" or "name_fallback"; fallback matches carry a warning that they are heuristic. Unnamed unkeyed jobs and duplicate identities remain unmatched. Explicit keys never fall back to names, even when a key was added, removed, or changed between builds. Added/removed means a job identity is present in only one build, so renaming unkeyed jobs or changing matrix values or parallelism can also produce added/removed entries. Retried attempts are excluded; final-attempt states and retry counts remain visible.
Execution times and deltas cover final attempts only. Scheduling time is scheduled_at to started_at, not dependency or manual waiting. These are not build wall-clock comparisons or total retry costs. Missing or inconsistent timestamps omit the corresponding timing. Unfinished builds are explicitly identified as changing snapshots.