Buildkite

officiel

Gérer les pipelines et les builds de Buildkite.

Que pouvez-vous faire avec Buildkite MCP ?

  • Lister les pipelines — Demandez à l'assistant de parcourir les pipelines de votre organisation Buildkite en utilisant list_pipelines.
  • Inspecter les builds — Récupérez les builds récents d'un pipeline avec list_builds et explorez les détails d'un build spécifique via get_build.
  • Examiner les jobs et les logs — Listez les jobs d'un build avec list_jobs et récupérez le contenu brut des logs d'un job avec get_job_log.
  • Consulter les résultats des tests — Accédez aux résumés des tests et aux détails individuels des tests pour un build via list_tests et get_test.

Documentation

buildkite-mcp-server

Build status

Serveur Model Context Protocol (MCP) exposant les données Buildkite (pipelines, builds, jobs, tests) aux outils d'IA et aux éditeurs.

La documentation complète est disponible sur buildkite.com/docs/apis/mcp-server.


Utilisation de la bibliothèque

L'API Go exportée par ce module doit être considérée comme instable et sujette à des modifications incompatibles au fur et à mesure de l'évolution de ce projet.


Sécurité

Pour garantir que le serveur MCP s'exécute dans un environnement sécurisé, nous recommandons de l'exécuter dans un conteneur.

Cette image est construite à partir de cgr.dev/chainguard/static et s'exécute en tant qu'utilisateur non privilégié.

Transmission des en-têtes d'identité via le mode HTTP

Les déploiements HTTP auto-hébergés peuvent transférer des en-têtes sélectionnés de chaque requête MCP entrante vers l'API Buildkite :

BUILDKITE_API_TOKEN=bkua_xxx \
  buildkite-mcp-server http \
  --passthrough-http-header X-User-Identity

Répétez --passthrough-http-header pour autoriser plus d'un en-tête, ou définissez une valeur BUILDKITE_PASSTHROUGH_HTTP_HEADERS séparée par des virgules. Seuls les en-têtes explicitement autorisés sont transmis, et uniquement vers l'origine configurée par BUILDKITE_BASE_URL. Ils sont supprimés des requêtes redirigées ailleurs.

Pour authentifier chaque requête MCP avec son propre jeton d'API Buildkite, autorisez Authorization et omettez le jeton global du processus :

BUILDKITE_PASSTHROUGH_HTTP_HEADERS=Authorization \
  buildkite-mcp-server http

Dans ce mode, chaque requête /mcp doit contenir exactement un en-tête Authorization non vide. Les informations d'identification manquantes renvoient une erreur HTTP 401 ; le serveur ne revient jamais à un jeton d'API partagé. Le proxy inverse devant le serveur MCP est responsable de l'authentification des appelants et de la définition ou de la validation de tout en-tête d'identité transmis.

La transmission d'en-têtes n'est pas disponible en mode stdio. Avant de servir les journaux de job, le serveur vérifie que l'appelant actuel peut accéder au journal du job. Cette vérification est effectuée pour chaque requête d'outil de journal, y compris lorsque les données du journal sont déjà en cache.


Contribuer

Les directives de développement se trouvent dans DEVELOPMENT.md.


Licence

MIT © Buildkite

SPDX-License-Identifier: MIT