Buildkite MCP Server

Der Buildkite MCP Server verbindet KI-Assistenten mit Ihrer CI/CD-Plattform Buildkite. Buildkite baut, testet und liefert Software über Pipelines aus, die auf eigenen oder gehosteten Agenten laufen. MCP, das Model Context Protocol, ist ein offener Standard, über den ein Assistent wie Claude Code oder Cursor externe Werkzeuge aufruft. Laut Dokumentation stellt der Server Produktdaten wie Pipelines, Builds, Jobs und Daten der Test Engine bereit; er baut auf der Buildkite-REST-API auf und ist als Open-Source-Projekt unter der MIT-Lizenz veröffentlicht. Statt bei einem roten Build zwischen Browser-Tabs und Log-Ausgaben zu wechseln, kann der Assistent die Ursache selbst heraussuchen.

Gehostet oder lokal

Es gibt zwei Betriebsarten. Der gehostete Server wird von Buildkite betrieben und automatisch aktualisiert; er eignet sich laut Dokumentation für Werkzeuge, mit denen Sie direkt per Prompt arbeiten, ist aber nicht für automatisierte Abläufe gedacht, die kein interaktives OAuth abschließen können, und lässt sich nicht auf eine Version festlegen. Der lokale Server läuft auf Ihrem Rechner oder in einem Container, ist selbst zu pflegen und passt zu automatisierten Workflows, die eine feste Serverversion brauchen. Für stabiles Verhalten empfiehlt die Dokumentation einen versionierten Docker-Tag oder eine Release-Datei.

Drei Endpunkte für den gehosteten Server

Unter https://mcp.buildkite.com/mcp erreichen Sie den OAuth-Server mit Lese- und Schreibzugriff. https://mcp.buildkite.com/mcp/readonly ist die schreibgeschützte Variante: Sie lässt nur Werkzeuge zu, deren benötigter Scope mit read_ beginnt, plus solche ohne Scope. https://mcp.buildkite.com/direct ist für Agenten ohne Oberfläche gedacht und nimmt ein API-Token im Header Authorization entgegen; dieser Endpunkt ist laut Dokumentation auf 50 Anfragen pro Minute und Nutzer begrenzt. Über den Header X-Buildkite-Toolsets lässt sich zusätzlich die Menge der Werkzeuge auf Gruppen wie user, pipelines oder builds einschränken.

Was kann der Buildkite MCP Server?

Lesend gibt es Werkzeuge für den Benutzer und die Organisation, für Cluster, Queues, Agenten und Pipelines samt Zeitplänen, für Builds, Jobs und deren Umgebungsvariablen sowie für Artefakte und Annotationen. Für Logs stehen search_logs, tail_logs und read_logs bereit; die Test Engine liefert Tests, Testläufe und fehlgeschlagene Ausführungen. Geheimnisse in Clustern werden laut Dokumentation nur beschrieben, ihre Werte werden nie zurückgegeben. Besonders praktisch ist get_build_failure_summary: Das Werkzeug sammelt problematische Jobs, Log-Ausschnitte, Fehler-Annotationen und fehlgeschlagene Tests in einem Aufruf, wobei das Ergebnis auch unvollständig sein kann. Die README beschreibt außerdem compare_builds, das einen fehlgeschlagenen Build mit dem letzten erfolgreichen auf demselben Branch vergleicht.

Schreibend nennt die Dokumentation 21 Werkzeuge, etwa create_build, rebuild_build, cancel_build, retry_job, unblock_job sowie das Anlegen und Ändern von Pipelines, Zeitplänen, Clustern und Queues. Weil damit Pipeline-Befehle bis hin zu Deployments ausgelöst werden können, rät die Dokumentation, Schreibaktionen nur nach Freigabe zuzulassen. Für Wiederholungen mit eingeschränkten Rechten gibt es laut README ein Toolset retries, das ohne den Scope write_builds auskommt.

Anmeldung und Rechte

Beim gehosteten Server melden Sie sich mit Ihrem Buildkite-Konto per OAuth an; ausgestellt wird ein kurzlebiges Token mit vorgegebenen Lese- und Schreib-Scopes, das bis zu eine Stunde gültig ist, Refresh-Tokens gelten bis zu 30 Tage. Beim lokalen Server und beim Endpunkt /direct entscheidet der Scope Ihres API-Tokens, welche Aufrufe gelingen. Die Dokumentation weist darauf hin, dass der schreibgeschützte Modus nur diese eine Verbindung beschränkt: Ein Agent mit Shell-Zugriff und einem anderweitig angemeldeten bk-CLI kann weiterhin Änderungen vornehmen.

Kosten

Der Server selbst ist Open Source. Nutzen können Sie ihn mit einem Buildkite-Konto; laut Preisseite gibt es einen kostenlosen Plan für einzelne Entwickler und kleine Teams sowie kostenpflichtige Pro- und Enterprise-Pläne. Für gehostete Agenten und manche Kontingente fallen nutzungsabhängige Kosten an. Aktuelle Konditionen finden Sie auf der Preisseite von Buildkite.

Für wen lohnt sich der Buildkite MCP Server?

Er lohnt sich für Teams, die ihre Builds ohnehin in Buildkite betreiben und Fehlersuche beschleunigen wollen: Der Assistent liest Logs, vergleicht Builds und nennt wahrscheinliche Ursachen, ohne dass jemand Ausgaben kopiert. Starten Sie mit dem schreibgeschützten Endpunkt, und erlauben Sie Schreibzugriff erst, wenn Sie dem Ablauf vertrauen. Die Dokumentation merkt an, dass sich Werkzeuge im laufenden Projekt ändern oder entfallen können.

Ein Buildkite-Konto (für OAuth) oder ein API-Token (für /direct und den lokalen Server) sowie ein MCP-Client mit HTTP-Transport, zum Beispiel Claude Code oder Cursor.

Mit dem Buildkite MCP Server liest ein KI-Assistent Pipelines, Builds und Logs aus Buildkite. Dieser Ratgeber führt von der Wahl des Endpunkts bis zur ersten Fehleranalyse.

Schritt 1: Voraussetzungen

Sie brauchen ein Buildkite-Konto mit Zugriff auf die gewünschte Organisation und einen MCP-Client mit HTTP-Transport, etwa Claude Code oder Cursor. Hat Ihre Organisation eine IP-Freigabeliste für die API, tragen Sie laut Dokumentation die Egress-Adressen von Buildkite ein.

Den passenden Endpunkt wählen

Der gehostete Server bietet drei Endpunkte: /mcp mit Lese- und Schreibzugriff, /mcp/readonly nur zum Lesen und /direct für Agenten ohne Oberfläche mit API-Token. Für den Einstieg ist /mcp/readonly die sichere Wahl. Mit dem Header X-Buildkite-Toolsets, etwa mit dem Wert user,pipelines,builds, begrenzen Sie die Werkzeuge zusätzlich.

Schritt 2: In Claude Code einbinden

Der Befehl lautet claude mcp add --transport http buildkite https://mcp.buildkite.com/mcp. Möchten Sie eine Organisation vorauswählen, hängen Sie ?organization=ihre-organisation an die Adresse. Für die schreibgeschützte Variante tragen Sie stattdessen die Adresse https://mcp.buildkite.com/mcp/readonly ein. Beim ersten Aufruf öffnet sich die OAuth-Anmeldung; wählen Sie dort die Organisation und bestätigen Sie mit Authorize. Prüfen Sie danach mit /mcp, ob die Werkzeuge erscheinen.

claude mcp add --transport http buildkite https://mcp.buildkite.com/mcp

Erste Fehleranalyse

Bitten Sie den Assistenten, einen fehlgeschlagenen Build zu untersuchen. Das Werkzeug get_build_failure_summary sammelt problematische Jobs, Log-Ausschnitte, Annotationen und fehlgeschlagene Tests; die Ergebnisse können unvollständig sein. Für Details nutzt er tail_logs oder search_logs.

Schreibzugriff mit Bedacht

Werkzeuge wie retry_job, rebuild_build oder create_build können Pipeline-Befehle bis hin zu Deployments auslösen. Aktivieren Sie sie erst, wenn Sie dem Ablauf vertrauen, und lassen Sie Schreibaktionen im Client freigeben. Beachten Sie, dass der Lesemodus nur diese Verbindung beschränkt: Ein separat angemeldetes bk-CLI mit Schreibrechten bleibt unberührt.

Lokal statt gehostet

Für automatisierte Abläufe, die eine feste Version brauchen, läuft der Server lokal oder im Container mit einem API-Token. Nutzen Sie dafür laut Dokumentation einen versionierten Docker-Tag oder eine Release-Datei und ein Token mit möglichst wenigen Scopes.

OAuth mit dem Buildkite-Konto (gehosteter Server) oder ein Buildkite-API-Token (lokaler Server und Endpunkt /direct).

Lesend: Pipelines, Builds, Jobs, Logs, Artefakte, Annotationen, Cluster und Test Engine. Schreibend (nur auf dem Endpunkt /mcp oder mit passendem Token): Builds starten, wiederholen, abbrechen sowie Pipelines, Zeitpläne und Cluster ändern.

Gelesene Build-Daten, Logs und Umgebungsvariablen gelangen in den Kontext des KI-Clients und damit zum Modellanbieter. Der gehostete Server wird von Buildkite betrieben.

Schreibwerkzeuge können Pipeline-Befehle und Deployments auslösen, Logs und Job-Umgebungen können Geheimnisse enthalten, API-Tokens liegen in Konfigurationsdateien im Klartext, und Log-Inhalte können Prompt Injection enthalten.