Cómo conectar Buildkite a Cursor vía MCP

💡 ¿Sin instalación? Usa cloud.anythingmcp.com directamente. Inicia sesión, pulsa Connectors → Buildkite, pega tus credenciales, genera una MCP API key y listo. Sin Docker, sin git clone, sin servidor local.

Buildkite + Cursor

Revisa Buildkite desde tu agente de IA: pipelines, builds y jobs, logs de jobs, artefactos y anotaciones, agentes, clústeres y colas, y suites de Test Engine con tests inestables y lentos; tras tu confirmación, lanza, reconstruye y reintenta builds, desbloquea pasos y añade anotaciones.

Requisitos previos

Las instrucciones de configuración completas están incluidas en el conector (visibles en el store al seleccionarlo). Las variables de entorno requeridas:

BUILDKITE_API_TOKEN

Paso 1 — Obtener credenciales

La configuración lleva unos 3 minutos. Necesitas una cuenta de Buildkite con acceso a la organización.

1. En Buildkite abre tu avatar, Personal Settings, API Access Tokens (https://buildkite.com/user/api-access-tokens) y haz clic en New API Access Token.
2. Elige las organizaciones y estos scopes: read_builds, read_build_logs, read_pipelines, read_artifacts, read_agents, read_clusters, read_organizations, read_user y, para Test Engine, read_suites. Para las escrituras añade write_builds. Deja fuera lo que no quieras que haga la IA.
3. Pega el token (suele empezar por bkua_) en BUILDKITE_API_TOKEN. Se envía como Authorization: Bearer <token> solo a api.buildkite.com, y la IA actúa como el usuario propietario.
4. Instala el conector y ejecuta buildkite_get_access_token: muestra los scopes del token. Después buildkite_list_organizations lista los slugs de las organizaciones.

Slugs y números: las herramientas usan el slug de la organización (org) y el de la pipeline (pipeline) como en buildkite.com/<org>/<pipeline>, y el número del build (#123), no su UUID. Jobs, artefactos y agentes usan UUID. buildkite_list_test_runs filtra por el UUID del build (su id).

Qué lee:

• Organizaciones y pipelines: buildkite_get_current_user, buildkite_list_organizations, buildkite_get_organization, buildkite_list_pipelines (filtro por parte del nombre o de la URL del repositorio) y buildkite_get_pipeline con repositorio, rama por defecto, filtros de ramas, clúster y los pasos en YAML.
• Builds: buildkite_list_builds para toda la organización o buildkite_list_pipeline_builds para una pipeline, de más reciente a más antiguo, filtrados por rama, estado (failed, running, blocked y otros), commit, autor o fechas. Por defecto no incluyen los jobs; buildkite_get_build los muestra con estado, código de salida, step key y agente.
• Por qué falló un build: buildkite_list_jobs con state en failed, luego buildkite_get_job y buildkite_get_job_log, que devuelve el final del log en texto plano, por defecto los últimos 100.000 bytes, donde suele estar el error (tail_bytes hasta 5.000.000). buildkite_list_annotations suele contener el resumen de tests o de cobertura.
• Artefactos: buildkite_list_build_artifacts, buildkite_list_job_artifacts (filtro por estado o glob de ruta) y buildkite_get_artifact con tamaño, tipo MIME, sha1 y URL de descarga; el archivo en sí se abre en la app de Buildkite.
• Agentes y capacidad: buildkite_list_agents (hostname, versión, cola, etiquetas, estado de conexión, job actual), buildkite_get_agent, buildkite_list_clusters, buildkite_get_cluster y buildkite_list_cluster_queues (si el reparto de trabajo está en pausa).
• Test Engine: buildkite_list_test_suites, buildkite_list_tests con fiabilidad, duraciones, número de ejecuciones, etiquetas como flaky y responsables (sort_by=reliability con order=asc para los menos fiables), buildkite_get_test con puntuaciones de inestabilidad, buildkite_list_test_runs, buildkite_get_test_run y buildkite_list_failed_executions con el motivo del fallo y, si se pide, el backtrace.

Qué cambia, tras tu confirmación: buildkite_create_build (pipeline, commit, rama, mensaje, entorno), buildkite_rebuild_build, buildkite_retry_failed_jobs, buildkite_retry_job, buildkite_unblock_job y buildkite_create_annotation. Los builds ejecutan pasos reales en tus agentes, despliegues incluidos, y consumen cómputo, así que la IA indica pipeline, build y rama y espera tu sí. buildkite_unblock_job aprueba una puerta manual, a menudo la previa a producción: la IA solo la llama cuando lo dices expresamente.

Desactivado al instalar: buildkite_cancel_build. Un build cancelado detiene sus jobs en marcha, puede dejar un despliegue a medias y no se puede reanudar, solo reconstruir, así que un admin del workspace lo activa cuando el equipo lo necesita.

Formatos de datos: los estados van en minúsculas (passed, failed, running, blocked, canceled). Las horas son ISO 8601 en UTC. web_url abre el build o el job en Buildkite. Las líneas de log pueden llevar códigos de color ANSI. Las duraciones de los tests van en segundos y la fiabilidad es una fracción (0,95 = 95 %).

Paginación: las herramientas de listado aceptan page y per_page (30 por defecto, hasta 100). Si hay más resultados, la respuesta incluye _pagination.nextUrl; la IA pide la siguiente page (o pasa after en buildkite_list_jobs) hasta que _pagination desaparece. Los listados de builds muy profundos responden 400; entonces la IA los acota con branch o created_from.

Límites: Buildkite limita las llamadas REST por organización y por usuario y minuto, y responde 429 cuando se agota cualquiera de los dos; espera los segundos de RateLimit-Reset y vuelve a intentarlo.

Errores comunes: 401 indica que el token es incorrecto, ha caducado o se ha revocado. 403 indica que al token le falta el scope para la llamada (compruébalo con buildkite_get_access_token) o que no tiene acceso a esa organización. 404 indica un slug, número o id incorrecto. 422 explica por qué un build o un job no se puede crear, reintentar o desbloquear.

El conector no lee las variables de entorno de los jobs (contienen secretos), no borra logs, artefactos, anotaciones ni pipelines, no crea ni modifica pipelines, clústeres, colas ni tokens de agente, no detiene ni pausa agentes y no cubre equipos, miembros, eventos de auditoría, registros de paquetes ni cambios de estado de tests como mute y skip.

Paso 2 — Instalar el 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

Paso 3 — Añadir el conector en Cursor

La URL de tu servidor: en AnythingMCP abre MCP Servers → el servidor donde está este conector y copia su URL (https://cloud.anythingmcp.com/mcp/…). Úsala donde esta guía muestra YOUR_SERVER_ID.

Cursor lee los servidores MCP de ~/.cursor/mcp.json. Añade esta entrada:

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

1. Crea una clave de API MCP en AnythingMCP en MCP Servers → tu servidor → API keys y pégala en lugar de YOUR_MCP_API_KEY.
2. Guarda el archivo y reinicia Cursor.
3. Abre Cursor → Settings → MCP y comprueba que anythingmcp aparece en la lista y está conectado.
4. Empieza a chatear: el agente ya puede usar las herramientas de Buildkite.

Herramientas disponibles

Ejemplos de prompts

• "¿Por qué falló el último build de la pipeline api en main? Muéstrame el error del log del job fallido."
• "¿Qué builds están bloqueados ahora mismo esperando una aprobación?"
• "Lista los 10 tests menos fiables de nuestra suite de Test Engine en los últimos 7 días."
• "Reintenta los jobs fallidos del build #4821 en la pipeline web."
• "¿Cuántos agentes hay conectados en la cola default y cuáles están ocupados?"

FAQ

¿Cursor admite servidores MCP personalizados en el plan gratuito? Sí, MCP está disponible en los planes Hobby, Pro y Business.

Siguientes pasos

• Página del conector
• Conectar a Claude
• Conectar a ChatGPT
• Conectar a Gemini
• Conectar a Meta Muse
• Conectar a Microsoft Copilot