Buildkite connector for AI agents

Tools your delivery agent reaches for on Buildkite, scoped per user.

CALL ANY TOOL

List and inspect pipelines and builds, read job logs, trigger new builds, and pull artifacts, each call scoped to the authenticated developer's organization access.

buildkitemcp_list_jobs

List jobs

List jobs for a Buildkite build, returning an actionable summary by default. For CI failure diagnosis, use state='failed,broken' to avoid returning successful jobs. Use detail_level='detailed' for execution metadata or 'full' for the existing full MCP job response. Returns 'items' and cursor pagination 'links'

Parameters

Name

Type

Required

Description

build_number

string

Required

No description.

org_slug

string

Required

No description.

pipeline_slug

string

Required

No description.

after

string

Optional

Cursor for the next page. Take this from the 'links.next' URL of a previous response. Mutually exclusive with 'before'

before

string

Optional

Cursor for the previous page. Take this from a previous response. Mutually exclusive with 'after'

detail_level

string

Optional

Response detail level: 'summary' (default), 'detailed', or 'full'

group_key

string

Optional

Filter jobs by group key. Includes all jobs in the group

include_agent

boolean

Optional

Include full agent details at the detailed and full levels. When false (default), detailed and full responses include only agent.id

include_retried_jobs

boolean

Optional

Include retried jobs in the response. Defaults to true on the server when omitted

per_page

integer

Optional

Results per page for cursor pagination (min 1, max 100, default 30)

state

string

Optional

Filter jobs by state. Comma-separated for multiple states (e.g., 'passed,failed,running')

step_key

string

Optional

Filter jobs by step key. Includes all parallel jobs for the step

buildkitemcp_search_logs

Search logs

buildkitemcp_list_tests

List tests

List tests in a Buildkite Test Engine suite with execution metrics aggregated over a selected time window. Supports filtering, metric sorting, and pagination.

Parameters

Name

Type

Required

Description

org_slug

string

Required

No description.

test_suite_slug

string

Required

No description.

branch

string

Optional

Filter executions included in the metrics by branch. Prefix with '!' to exclude an exact branch or suffix with '*' to match by prefix, for example '!main' or 'feature*'. Use at most one operator.

labels

string

Optional

Filter by comma-separated test labels. Prefix a label with '!' to exclude it, for example 'flaky,!slow'.

max_timestamp

string

Optional

End of the aggregation window in RFC3339 format. Defaults to the current time when omitted.

min_timestamp

string

Optional

Start of the aggregation window in RFC3339 format. When omitted, defaults to the organization's default Test Engine period before the current time.

order

string

Optional

Sort direction: 'asc' or 'desc'. Defaults to 'desc'.

owners

string

Optional

Filter by comma-separated test owner slugs. Prefix an owner with '!' to exclude it, for example 'payments,!platform'.

page

integer

Optional

Page number for pagination (min 1)

per_page

integer

Optional

Results per page for pagination (min 1, max 100)

period

string

Optional

Relative aggregation window, such as '7days' or '28days'. Whether selected by period or timestamps, the aggregation window cannot exceed the organization's maximum Test Engine window. Cannot be combined with min_timestamp or max_timestamp.

sort_by

string

Optional

Metric used to sort results: 'duration_avg', 'duration_sum', 'duration_min', 'duration_max', or 'reliability'. Defaults to 'duration_avg'. Metrics cover only executions in the selected window.

state

string

Optional

Filter by test state: 'enabled', 'muted', or 'skipped'.

tags

string

Optional

Filter by comma-separated execution tags in key:value form. Values support '!' for exclusion and '*' for prefix matching. Result values additionally support '~' for any matching execution and '^' for every execution matching, for example 'framework:!rspec,scm.branch:feature*,result:^passed'.

buildkitemcp_get_job

Get job

buildkitemcp_list_agents

List agents

buildkitemcp_get_test

Get test

buildkitemcp_list_builds

List builds

buildkitemcp_get_agent

Get agent

buildkitemcp_list_skills

List skills

buildkitemcp_get_build

Get build

buildkitemcp_list_clusters

List clusters

buildkitemcp_get_cluster

Get cluster

buildkitemcp_list_pipelines

List pipelines

buildkitemcp_get_artifact

Get artifact

buildkitemcp_list_annotations

List annotations

buildkitemcp_get_pipeline

Get pipeline

buildkitemcp_list_test_runs

List test runs

buildkitemcp_get_job_env

Get job env

buildkitemcp_list_cluster_queues

List cluster queues

buildkitemcp_get_test_run

Get test run

buildkitemcp_list_pipeline_schedules

List pipeline schedules

buildkitemcp_get_cluster_queue

Get cluster queue

buildkitemcp_list_artifacts_for_job

List artifacts for job

buildkitemcp_get_failed_executions

Get failed executions

buildkitemcp_list_artifacts_for_build

List artifacts for build

buildkitemcp_get_pipeline_schedule

Get pipeline schedule

buildkitemcp_create_build

Create build

buildkitemcp_get_build_failure_summary

Get build failure summary

buildkitemcp_create_cluster

Create cluster

buildkitemcp_get_build_test_engine_runs

Get build test engine runs

Build your Agent

The same per-user auth pattern wires into every agent framework.

import { ScalekitClient } from "@scalekit-sdk/node";
import { ChatOpenAI } from "@langchain/openai";
import { createReactAgent } from "@langchain/langgraph/prebuilt";

const sk = new ScalekitClient(process.env.SCALEKIT_ENV_URL, process.env.SCALEKIT_CLIENT_ID, process.env.SCALEKIT_CLIENT_SECRET);

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["buildkitemcp"], toolNames: ["buildkite_pipelines_list", "buildkite_builds_list", "buildkite_build_create"] },
  pageSize: 100,
});

const agent = createReactAgent({ llm: new ChatOpenAI({ model: "gpt-4o" }), tools });
await agent.invoke({ messages: [{ role: "user", content: "Trigger a build on the api pipeline" }] });

import OpenAI from "openai";
import { ScalekitClient } from "@scalekit-sdk/node";

const openai = new OpenAI();
const sk = new ScalekitClient(process.env.SCALEKIT_ENV_URL, process.env.SCALEKIT_CLIENT_ID, process.env.SCALEKIT_CLIENT_SECRET);

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["buildkitemcp"], toolNames: ["buildkite_pipelines_list", "buildkite_builds_list", "buildkite_build_create"] },
  pageSize: 100,
});

const res = await openai.responses.create({
  model: "gpt-4o",
  input: "List recent failed builds on the api pipeline",
  tools,
});

import Anthropic from "@anthropic-ai/sdk";
import { ScalekitClient } from "@scalekit-sdk/node";

const anthropic = new Anthropic();
const sk = new ScalekitClient(process.env.SCALEKIT_ENV_URL, process.env.SCALEKIT_CLIENT_ID, process.env.SCALEKIT_CLIENT_SECRET);

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["buildkitemcp"], toolNames: ["buildkite_pipelines_list", "buildkite_builds_list", "buildkite_build_create"] },
  pageSize: 100,
});

const msg = await anthropic.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 1024,
  tools,
  messages: [{ role: "user", content: "Why did the last api build fail?" }],
});

import { LlmAgent } from "@google/adk/agents";
import { ScalekitClient } from "@scalekit-sdk/node";

const sk = new ScalekitClient(process.env.SCALEKIT_ENV_URL, process.env.SCALEKIT_CLIENT_ID, process.env.SCALEKIT_CLIENT_SECRET);

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["buildkitemcp"], toolNames: ["buildkite_pipelines_list", "buildkite_builds_list", "buildkite_build_create"] },
  pageSize: 100,
});

const agent = new LlmAgent({ name: "buildkite_agent", model: "gemini-2.0-flash", tools });
await agent.run("List pipelines I can access");

Try these prompts

Paste any prompt into your agent to start working Buildkite pipelines.

Trigger & rerun

Copy the prompt

Copied

Trigger a build on the api pipeline for the main branch.

Copy the prompt

Copied

Rerun the last failed build on the web pipeline.

Copy the prompt

Copied

Start a build on frontend for commit a1b2c3d.

Investigate

Copy the prompt

Copied

Why did the last build on the api pipeline fail?

Copy the prompt

Copied

Show me the job log for the failing rspec step.

Copy the prompt

Copied

List the failed builds on main this week.

Report & recall

Copy the prompt

Copied

List all pipelines I have access to.

Copy the prompt

Copied

Which agents are currently connected and idle?

Copy the prompt

Copied

List the artifacts from the latest release build.

SEE HOW AUTH WORKS

The developer authorises Buildkite once. Every later agent call uses their token with organization scope enforced.

Authorize

Your user connects

Buildkite MCP

once. We tie it to their identity and the meetings they approved — no shared bot account, no org-wide access

Who:

user ‘A’

when:

Once per user

access:

Limited to user

Store

Their

Buildkite MCP

token lives in a vault scoped to them. User A's meetings are never reachable by an agent acting for user B, even on the same connection

vault:

encrypted

scope:

per-user

tokens:

auto-refreshed

Resolve

When your agent calls a

Buildkite MCP

tool, we fetch the right token server-side. It never touches your agent, never appears in the LLM context, never shows up in your logs

speed:

~40ms

check:

before every call

seen by:

nobody

Audit

Every

Buildkite MCP

tool call is logged — who triggered it, which meeting was fetched, what came back. 90 days of history, tied to the user who authorized it

history:

90 days

export:

SIEM-ready

logged:

every call

Test other agents

See the same per-user auth pattern across other developer tools connectors.

Engineering Teams

DevOps assistant agent

Polls GitHub for failing checks and stale PRs, opens Linear issues for the ones that need work, and posts a daily digest to Slack. It acts as the engineer, not a shared service account.

Engineering Teams

Slack triage

Polls Slack for new messages, classifies bugs and support requests with a LangGraph router, files GitHub issues or Zendesk tickets, and confirms in the thread.

Engineering Teams

Engineering standup agent

Pulls commits from GitHub and GitLab, tracks issue movement in Jira, and posts a per-engineer standup brief to Slack. Each engineer's activity is read on their own delegated OAuth.

Engineering Teams

Auto release notes agent

Reads merged GitHub PRs, groups them into structured release notes, publishes the page to Notion, and announces the release in Slack. Every call runs on the engineer's own delegated OAuth.

Why Scalekit

Secure your agent's access. Connectors ship in minutes

01.

Shared tokens break per-user analytics

A shared Buildkite token looks fine in a demo. In production every triggered build logs as one service account, so you lose track of who shipped what. Scalekit resolves the real developer's credential per call.

// shared token
build → ci_bot

// scalekit
build → user_abc ✓

02.

Authentication is not authorization

03.

Multi-tenancy is architectural

04.

Buildkite today. Others tomorrow.

“Our agents act across Salesforce, Gong, Google Drive, and more, on behalf of every customer. Scalekit behind the scenes meant we can keep adding tools without ever rebuilding how credentials or tool calling work.”

Venu Madhav Kattagoni

Head of Engineering / Von

FAQs

Frequently Asked Questions

Does the agent access Buildkite as the user or as a shared key?

As the user. Scalekit resolves the authenticated developer's own Buildkite credential at request time, so every build triggered, log read, and pipeline change is attributed to them in Buildkite's audit log rather than a shared CI bot.

Where is the Buildkite token stored?

In an AES-256 encrypted vault, namespaced per tenant. Tokens are fetched only at the moment of a tool call, refreshed automatically before expiry, and revocable from a single dashboard, never exposed to the model or the prompt.

Can I limit what the agent is allowed to do in Buildkite?

Yes. Pass a toolNames filter to listScopedTools to expose only the actions you want, for example read-only pipeline and build listing without triggering new builds. Scalekit also runs a scope check before each API call.

What happens when a user revokes Buildkite access?

The credential is invalidated at the next tool call, which fails closed rather than falling back to a shared token. Other users are unaffected, and the revocation is recorded in the audit trail.

Can the agent trigger builds, or only read pipeline status?

That is your choice. Expose only buildkite_pipelines_list and buildkite_builds_list for a read-only status agent, or add buildkite_build_create to let it trigger builds. The write scope is enforced per user, so a developer can only build pipelines they already have access to.

On this page

Tool and actions Framework Compatibility Starter Prompt Auth Lifecycle Try Other Agents Why Scalekit