Come collegare Buildkite a Cursor 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 + Cursor

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 Cursor

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.

Cursor legge i server MCP da ~/.cursor/mcp.json. Aggiungi questa voce:

{
  "mcpServers": {
    "anythingmcp": {
      "url": "https://cloud.anythingmcp.com/mcp/YOUR_SERVER_ID",
      "headers": { "X-API-Key": "YOUR_MCP_API_KEY" }
    }
  }
}

1. Crea una chiave API MCP in AnythingMCP da MCP Servers → il tuo server → API keys e incollala al posto di YOUR_MCP_API_KEY.
2. Salva il file e riavvia Cursor.
3. Apri Cursor → Settings → MCP e verifica che anythingmcp sia elencato e connesso.
4. Inizia a chattare: l'agente ora può usare i tool di Buildkite.

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

Cursor supporta server MCP personalizzati nel piano gratuito? Sì, MCP è disponibile nei piani Hobby, Pro e Business.

Prossimi passi

• Landing del connettore
• Collegare a Claude
• Collegare a ChatGPT
• Collegare a Gemini
• Collegare a Meta Muse
• Collegare a Microsoft Copilot