Come collegare Buildkite a Microsoft Copilot via MCP

💡 Niente installazione? Vai direttamente su cloud.anythingmcp.com. Accedi, clicca Connectors → Buildkite, inserisci le credenziali, genera una MCP API key e hai finito. Niente Docker, niente git clone, niente server locale.

Buildkite + Microsoft Copilot

Controlla Buildkite dal tuo agente AI: pipeline, build e job, log dei job, artefatti e annotation, agent, cluster e code, e le suite di Test Engine con i test instabili e lenti; dopo la tua conferma avvia, ricostruisci e ripeti build, sblocca step e aggiungi annotation.

Prerequisiti

Le istruzioni di setup complete sono incluse nel connettore stesso (visibili nello store quando lo selezioni). Le variabili d'ambiente richieste sono:

BUILDKITE_API_TOKEN

Step 1 — Ottieni le credenziali

La configurazione richiede circa 3 minuti. Ti serve un account Buildkite con accesso all'organizzazione.

1. In Buildkite apri il tuo avatar, Personal Settings, API Access Tokens (https://buildkite.com/user/api-access-tokens) e fai clic su New API Access Token.
2. Scegli le organizzazioni e questi scope: read_builds, read_build_logs, read_pipelines, read_artifacts, read_agents, read_clusters, read_organizations, read_user e, per Test Engine, read_suites. Per le scritture aggiungi write_builds. Lascia fuori ciò che non vuoi far fare all'AI.
3. Incolla il token (di solito inizia con bkua_) in BUILDKITE_API_TOKEN. Viene inviato come Authorization: Bearer <token> solo ad api.buildkite.com, e l'AI agisce come l'utente a cui appartiene.
4. Installa il connettore ed esegui buildkite_get_access_token: mostra gli scope del token. Poi buildkite_list_organizations elenca gli slug delle organizzazioni.

Slug e numeri: i tool vogliono lo slug dell'organizzazione (org) e quello della pipeline (pipeline) come in buildkite.com/<org>/<pipeline>, e il numero della build (#123), non il suo UUID. Job, artefatti e agent usano UUID. buildkite_list_test_runs filtra per UUID della build (il suo id).

Cosa legge:

• Organizzazioni e pipeline: buildkite_get_current_user, buildkite_list_organizations, buildkite_get_organization, buildkite_list_pipelines (filtro per parte del nome o dell'URL del repository) e buildkite_get_pipeline con repository, branch di default, filtri sui branch, cluster e step YAML.
• Build: buildkite_list_builds per tutta l'organizzazione o buildkite_list_pipeline_builds per una pipeline, dalla più recente, filtrate per branch, stato (failed, running, blocked e altri), commit, autore o date. Di default omettono i job; buildkite_get_build li mostra con stato, exit status, step key e agent.
• Perché una build è fallita: buildkite_list_jobs con state impostato su failed, poi buildkite_get_job e buildkite_get_job_log, che restituisce la fine del log in testo semplice, di default gli ultimi 100.000 byte, dove di solito c'è l'errore (tail_bytes fino a 5.000.000). buildkite_list_annotations contiene spesso il riepilogo dei test o della coverage.
• Artefatti: buildkite_list_build_artifacts, buildkite_list_job_artifacts (filtro per stato o glob del percorso) e buildkite_get_artifact con dimensione, tipo MIME, sha1 e URL di download; il file vero e proprio si apre nell'app Buildkite.
• Agent e capacità: buildkite_list_agents (hostname, versione, coda, tag, stato della connessione, job corrente), buildkite_get_agent, buildkite_list_clusters, buildkite_get_cluster e buildkite_list_cluster_queues (se il dispatch è in pausa).
• Test Engine: buildkite_list_test_suites, buildkite_list_tests con affidabilità, durate, numero di esecuzioni, etichette come flaky e owner (sort_by=reliability con order=asc per i meno affidabili), buildkite_get_test con i punteggi di instabilità, buildkite_list_test_runs, buildkite_get_test_run e buildkite_list_failed_executions con il motivo del fallimento e, su richiesta, il backtrace.

Cosa modifica, dopo la tua conferma: buildkite_create_build (pipeline, commit, branch, messaggio, ambiente), buildkite_rebuild_build, buildkite_retry_failed_jobs, buildkite_retry_job, buildkite_unblock_job e buildkite_create_annotation. Le build eseguono step reali sui tuoi agent, deployment compresi, e consumano risorse di calcolo, quindi l'AI indica pipeline, build e branch e aspetta il tuo sì. buildkite_unblock_job approva un gate manuale, spesso quello prima della produzione: l'AI lo chiama solo quando lo dici esplicitamente.

Disattivato all'installazione: buildkite_cancel_build. Una build annullata ferma i job in corso, può lasciare un deployment a metà e non si può riprendere, solo ricostruire, quindi lo attiva un admin del workspace quando serve al team.

Formati dei dati: gli stati sono in minuscolo (passed, failed, running, blocked, canceled). Gli orari sono ISO 8601 in UTC. web_url apre la build o il job in Buildkite. Le righe di log possono contenere codici colore ANSI. Le durate dei test sono in secondi e l'affidabilità è una frazione (0,95 = 95%).

Paginazione: i tool di elenco accettano page e per_page (default 30, fino a 100). Se ci sono altri risultati la risposta contiene _pagination.nextUrl; l'AI chiede la page successiva (o passa after per buildkite_list_jobs) finché _pagination non manca. Gli elenchi di build molto profondi rispondono 400; l'AI li restringe allora con branch o created_from.

Limiti: Buildkite limita le chiamate REST per organizzazione e per utente al minuto e risponde 429 quando uno dei due è esaurito; aspetta i secondi indicati in RateLimit-Reset e riprova.

Errori comuni: 401 indica un token errato, scaduto o revocato. 403 indica che al token manca lo scope per la chiamata (verifica con buildkite_get_access_token) o che non ha accesso a quell'organizzazione. 404 indica uno slug, un numero o un id errato. 422 spiega perché una build o un job non può essere creato, ripetuto o sbloccato.

Il connettore non legge le variabili d'ambiente dei job (contengono segreti), non elimina log, artefatti, annotation o pipeline, non crea né modifica pipeline, cluster, code o token degli agent, non ferma né mette in pausa gli agent e non gestisce team, membri, eventi di audit, package registry né i cambi di stato dei test come mute e skip.

Step 2 — Installa l'adapter

curl -fsSL https://raw.githubusercontent.com/HelpCode-ai/anythingmcp/main/docker-compose.quickstart.yml -o docker-compose.yml
printf 'JWT_SECRET=%s\nENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env
docker compose up -d

Step 3 — Aggiungi il connettore in Microsoft Copilot

L'URL del tuo server: in AnythingMCP apri MCP Servers → il server su cui si trova questo connettore e copia il suo URL (https://cloud.anythingmcp.com/mcp/…). Usalo ovunque questa guida mostra YOUR_SERVER_ID.

Microsoft Copilot usa i server MCP tramite gli agenti creati in Copilot Studio: aggiungi AnythingMCP a un agente come strumento, poi pubblichi l'agente in Microsoft 365 Copilot e in Teams. Copilot Studio si collega dal cloud di Microsoft via Streamable HTTP, che AnythingMCP supporta.

1. In Copilot Studio apri il tuo agente (o creane uno), vai su Tools e scegli Add a tool → New tool → Model Context Protocol.
2. Inserisci un Server name (per esempio AnythingMCP), una Server description che dica cosa fa il connettore e il Server URL https://cloud.anythingmcp.com/mcp/YOUR_SERVER_ID. Copilot Studio usa la descrizione per decidere quando chiamare il server.
3. Come autenticazione scegli API key, imposta Type su Header e come nome dell'header X-API-Key, poi seleziona Create.
4. In Add tool scegli Create a new connection, incolla una chiave API MCP di AnythingMCP (MCP Servers → il tuo server → API keys) e seleziona Add to agent.
5. Provalo nel riquadro Test dell'agente: chiedi qualcosa che richiede i tool di Buildkite.
6. Seleziona Publish, poi Channels → Microsoft 365 and Microsoft Teams, lascia selezionato Make agent available in Microsoft Copilot e scegli Add channel. See agent in Teams lo installa per te; in Microsoft 365 Copilot scrivi @ e scegli l'agente.

Preferisci un accesso per ogni utente? Al posto della chiave API scegli OAuth 2.0 → Dynamic discovery: ogni persona accede ad AnythingMCP la prima volta che l'agente lo chiama.

Usi il self-hosting? Usa l'indirizzo HTTPS pubblico della tua istanza al posto di https://cloud.anythingmcp.com. Copilot Studio si collega dal cloud di Microsoft, quindi localhost non funziona.

Tool disponibili

Esempi di prompt

• "Perché è fallita l'ultima build della pipeline api su main? Mostrami l'errore dal log del job fallito."
• "Quali build sono bloccate in questo momento in attesa di un'approvazione?"
• "Elenca i 10 test meno affidabili della nostra suite di Test Engine negli ultimi 7 giorni."
• "Ripeti i job falliti della build #4821 nella pipeline web."
• "Quanti agent sono connessi nella coda default, e quali di questi sono occupati?"

FAQ

Per quale Copilot vale? Per Microsoft 365 Copilot in azienda, tramite gli agenti di Copilot Studio. L'app Microsoft Copilot per account personali non permette di aggiungere un proprio server MCP.

Cosa mi serve? Un account di lavoro con accesso a Copilot Studio (licenza o prova) per creare l'agente. Chi lo usa in Microsoft 365 Copilot o in Teams deve avere accesso all'agente: condividilo, oppure chiedi a un amministratore di pubblicarlo per l'organizzazione. Se la tua organizzazione applica criteri sui dati ai connettori di Power Platform, valgono anche per i server MCP.

L'agente non chiama i tool. Controlla che il nome dell'header sia esattamente X-API-Key e che la chiave appartenga allo stesso server MCP dell'URL, e scrivi una Server description precisa: Copilot Studio la usa per decidere quando chiamare il server. Dopo ogni modifica pubblica di nuovo l'agente; in una chat già aperta scrivi "start over" per passare alla nuova versione.

Prossimi passi

• Landing del connettore
• Collegare a Claude
• Collegare a ChatGPT
• Collegare a Cursor
• Collegare a Gemini
• Collegare a Meta Muse