Buildkite's MCP Server gains tools to diff a failed build and a tool Buildkite says retries only infrastructure failures

Buildkite says two new tools for its MCP Server are meant to shorten the path from a red build to a green one when an AI agent is doing the work. The company described them in an October 8, 2026 changelog entry, though an earlier weekly summary on the same page already lists build comparison among the MCP server's additions, so that tool may have shipped before October 8.

The first, compare_builds, answers the question engineers usually ask first after a failure: what is different from the last passing run. According to Buildkite, it compares a build with the most recent earlier passing build on the same branch, or with any build the user picks. It reports which steps newly failed, recovered or are still failing, and notes changes in run time and retries. For up to three newly failing steps it also returns the end of the job log, so an agent can start looking for the cause straight away.

The second, retry_failed_jobs, is aimed at noise. Buildkite says it retries jobs that failed for infrastructure reasons, such as an expired job or an agent that was lost or stopped, and leaves real failures alone. It lists every job it retried or skipped along with the reason. A dry run option lets an agent report what it would retry without changing the build.

Both tools are available in the open-source MCP server and in the Remote MCP Server. Buildkite says people using the remote server must sign in again from their MCP client to grant the permissions the new tools need.

What is confirmed is limited to the company's own description. This article rests on a single source, Buildkite's changelog, and we found no independent coverage or testing of the tools. The changelog does not explain how Buildkite decides that a failure is infrastructure-related rather than a genuine test or build failure, so how well that line holds in practice is unverified. It also gives no version numbers for the open-source server.

Our analysis, not drawn from the changelog: the practical interest is in the second tool. Automatically re-running failed jobs is a common agent behavior, and blind retries can hide flaky tests or waste compute. Separating infrastructure faults from real failures, and recording the reason for each decision, makes an agent's actions easier for a person to audit. The comparison tool similarly gives an agent a bounded starting point instead of an entire build history. Whether either saves time will depend on how reliable the classification and comparison prove to be.

The same changelog entry also describes other MCP additions, including tools for finding slow tests and managing cache registries, which are outside the scope of this report.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. The earlier version remains available as revision 1.