Secure Buildkite access for AI agents
Pipelines, builds, jobs, clusters, and test runs, plus build/job log search, via Buildkite's official MCP server.
Buildkite is where agents are most useful and most dangerous at the same time. Reading a failing job's log to explain what broke is exactly what you want; triggering builds, rewriting pipelines, or pausing a cluster queue on a hunch is not. Adding Buildkite here puts every tool call through your policies and onto the audit log, so you can hand agents the logs without handing them the CI system.
Server URL: https://mcp.buildkite.com/mcp
Setup
- Navigate to Resources and click Add Resource.
- Select Buildkite from the catalog.
- Click the Per-org dynamic registration card. Buildkite is DCR-only, so this is the single option shown — and picking it installs the resource immediately.
Nothing needs registering on Buildkite's side, and no client ID or secret is required. Each user then authorizes their own Buildkite account the first time an agent calls a Buildkite tool; manage linked accounts in Connections.
Buildkite's own organization, pipeline, and cluster-level permissions still apply. The gateway never widens access beyond what the authorizing user could already do in Buildkite — it only narrows it.
Dynamic client registration
Buildkite's MCP server supports OAuth dynamic client registration, so the gateway registers a fresh OAuth client against Buildkite's authorization server for your org during install. No SecureAuth-shared app is involved and no app registration is needed on your side.
See Credential modes for how this compares to the other modes catalog resources use.
Available tools
Buildkite exposes 46 tools. They are grouped below; the resource's Overview tab shows the authoritative per-tool list under Available Tools once installed.
| Tool | Description |
|---|---|
current_user | Get the currently authenticated user |
user_token_organization | Get the organization associated with the current access token |
access_token | Get details about the current access token |
list_pipelines / get_pipeline | List pipelines, or get details about a specific pipeline |
create_pipeline / update_pipeline | Create or update a pipeline |
list_pipeline_schedules / get_pipeline_schedule | List or get a pipeline's scheduled builds |
create_pipeline_schedule / update_pipeline_schedule | Create or update a pipeline schedule |
list_builds / get_build | List builds, or get details about a specific build |
create_build | Trigger a new build |
cancel_build / rebuild_build | Cancel a running build, or rebuild a previous one |
get_build_test_engine_runs | Get Test Engine runs associated with a build |
list_jobs / get_job | List jobs on a build, or get details about a specific job |
get_job_env | Get a job's environment variables |
retry_job / unblock_job | Retry a failed job, or unblock a blocked job |
read_logs / tail_logs / search_logs | Read, tail, or search a job's build log |
list_artifacts_for_build / list_artifacts_for_job | List artifacts for a build or a specific job |
get_artifact | Get details about a specific artifact |
create_annotation / list_annotations | Create or list build annotations |
list_agents / get_agent | List agents, or get details about a specific agent |
list_clusters / get_cluster | List clusters, or get details about a specific cluster |
create_cluster / update_cluster | Create or update a cluster |
list_cluster_queues / get_cluster_queue | List queues in a cluster, or get a specific queue |
create_cluster_queue / update_cluster_queue | Create or update a cluster queue |
pause_cluster_queue_dispatch / resume_cluster_queue_dispatch | Pause or resume dispatch on a cluster queue |
list_test_runs / get_test_run | List test runs, or get details about a specific test run |
get_test | Get details about a specific test |
get_failed_executions | Get failed test executions for a test run |
Two of these read tools deserve a second look before you allow them broadly: get_job_env returns a job's environment variables, and access_token describes the token behind the connection.
Policy examples
Read-only Buildkite for everyone
One deny rule blocks every mutating tool while leaving reads on the default path:
- In Access Policies, click Add Rule and name it "Buildkite: no CI mutations."
- Set the effect pill to Deny and the MCP scope pill to Buildkite.
- Add these tool patterns:
create_*,update_*,cancel_build,rebuild_build,retry_job,unblock_job,pause_cluster_queue_dispatch,resume_cluster_queue_dispatch. - Set the status to Active and click Create.
create_* and update_* cover all ten pipeline, schedule, cluster, queue, build, and annotation writers; the six explicit names are the mutating tools that don't share those prefixes. Everything else — the reads — keeps working.
Scope one agent to build and log triage
An allow rule on its own restricts nothing, because every org is seeded with an Allow all rule that anything unmatched falls through to. To confine an agent, pair the allow with a deny beneath it:
- Create the deny rule first: effect Deny, MCP scope Buildkite, Agent scope your triage agent, tool pattern
*. - Then create the allow rule: effect Allow, MCP scope Buildkite, the same Agent scope, tool patterns
list_builds,get_build,list_jobs,get_job,read_logs,tail_logs,search_logs,get_failed_executions.
Order matters, and so does the sequence you create them in: new rules insert at the top of the list, so building the deny first leaves the allow above it — which is what you need. Evaluation is first-match-wins, so the agent's triage calls hit the allow, every other Buildkite call hits the deny, and neither ever reaches Allow all.
Scoping both rules to one agent keeps the blast radius small. A deny with no Agent scope would cut off every agent and user in the org.
Next steps
- Create a policy — the full rule editor walkthrough.
- Policies — how first-match-wins ordering and the default Allow all rule interact.
- Block an agent from deleting GitHub branches — the same deny-first shape on another resource.