How is this different from connecting Buildkite MCP directly?

Connected directly, an agent sees every tool the server exposes and holds the credential itself. Through TrustGate you choose which tools each agent gets, and every call is logged against the agent that made it.

What if the Buildkite MCP API changes?

We track the Buildkite MCP schema, so the tool catalogue stays current. Tools you have already allowed keep working, and anything new stays denied until you enable it.

Can I give different agents different Buildkite tools?

Yes. Access is set per agent: one can get a handful of read tools, another the full set. You grant the whole MCP or single tools within it.

Where can I see what my agents did in Buildkite?

Every call is logged against the agent that made it, with the tool it used. Activity can be sent on to your own monitoring.

Do I need to run the Buildkite MCP server myself?

No. TrustGate connects to the Buildkite MCP server and sits in front of it. Your agent only talks to your TrustGate URL, never to Buildkite directly.

Connect Buildkite MCP to your AI agents, securely.

Q: Is Buildkite MCP secure?

The server itself exposes 56 tools, and some of them can write to your Buildkite account. Behind TrustGate an agent only sees the tools you allow, requests and responses are inspected, and every call is logged. Anything outside the allowlist is denied before it reaches Buildkite.

One secured endpoint for every Buildkite call your AI agents make, scoped per user, inspected, and logged.

Get started for free

Get a demo

Try Buildkite MCP now

What your agents can ask once Buildkite MCP is connected.

Select the tools your AI agents can call

56 tools from the Buildkite MCP schema.

Showing 56 tools

access_tokenreadReturns information about the current API access token, including its scopes and UUID.
current_userreadReturns details about the user account that owns the API token: name, email, avatar and account creation date. Scope: read_user.
user_token_organizationreadReturns details about the Buildkite organization associated with the user token. Scope: read_organizations.
list_clustersreadLists all clusters in an organization with their names, descriptions, default queues and creation details. Scope: read_clusters.
get_clusterreadReturns a specific cluster's name, description, default queue and configuration. Scope: read_clusters.
list_cluster_queuesreadLists all queues in a cluster with their keys, descriptions, dispatch status and agent configuration. Scope: read_clusters.
get_cluster_queuereadReturns a specific queue's key, description, dispatch status and hosted agent configuration. Scope: read_clusters.
create_clusterwriteCreates a new cluster in an organization. Scope: write_clusters.
create_cluster_queuewriteCreates a new self-hosted queue in a cluster. Scope: write_clusters.
update_clusterhigh riskUpdates an existing cluster's name, description, emoji, colour or default queue. Annotated destructive. Scope: write_clusters.
update_cluster_queuehigh riskUpdates an existing queue's description or retry agent affinity. Annotated destructive. Scope: write_clusters.
pause_cluster_queue_dispatchhigh riskPauses dispatch on a queue, preventing new jobs from reaching agents. Annotated destructive. Scope: write_clusters.
resume_cluster_queue_dispatchhigh riskResumes dispatch on a paused queue so jobs reach agents again. Annotated destructive. Scope: write_clusters.
list_cluster_secretsreadLists a cluster's secrets and their details. Values are never returned. Scope: read_secrets_details.
get_cluster_secretreadReturns details about a specific secret. The value itself is never returned. Scope: read_secrets_details.
create_cluster_secrethigh riskCreates a secret with an optional description and access policy, introducing a credential into the CI environment. Scope: write_secrets.
list_cache_registriesreadLists a cluster's cache registries ordered by slug with cursor pagination. Scope: read_clusters.
get_cache_registryreadReturns a cache registry including its policy and whether it is the cluster's default. Scope: read_clusters.
create_cache_registrywriteCreates a cache registry in a cluster with optional metadata and policy. Scope: write_clusters.
update_cache_registryhigh riskUpdates a cache registry's name, description, emoji, colour or policy. Annotated destructive. Scope: write_clusters.
set_default_cache_registryhigh riskSets another cache registry in the same cluster as the cluster's default. A cluster always has a default, so this cannot clear it. Annotated destructive.
delete_cache_registryhigh riskDeletes a cache registry and its cache metadata. A cluster's default cache registry cannot be deleted. Annotated destructive.
list_agentsreadLists agents in an organization with their connection state, host details, version, current job and pause status. Scope: read_agents.
get_agentreadReturns a specific agent's connection state, host details, current job, metadata and pause status. Scope: read_agents.
list_pipelinesreadLists all pipelines in an organization with their basic details, build counts and current status. Scope: read_pipelines.
get_pipelinereadReturns a pipeline's configuration, steps, environment variables and build statistics. Scope: read_pipelines.
list_pipeline_schedulesreadLists a pipeline's schedules with cron expression, target branch, environment variables, enabled state and next build time. Scope: read_pipelines.
get_pipeline_schedulereadReturns a single pipeline schedule's cron expression, branch, environment variables, enabled state, last failure and next build time. Scope: read_pipelines.
create_pipelinehigh riskCreates a new CI/CD pipeline with YAML configuration, repository connection and cluster assignment. Annotated destructiveHint false, but it creates executable configuration. Scope: write_pipelines.
update_pipelinehigh riskModifies an existing pipeline's configuration, repository, settings or metadata. Annotated destructive. Scope: write_pipelines.
create_pipeline_schedulehigh riskCreates a schedule that triggers builds on a cron-driven interval, so it runs unattended afterwards. Scope: write_pipelines.
update_pipeline_schedulehigh riskModifies an existing schedule's cron expression, branch, environment variables or enabled state. Annotated destructive. Scope: write_pipelines.
list_buildsreadLists builds for an organization, or for a pipeline when a slug is given, as lightweight summaries with state, branch, commit, message, URL and creation time. Scope: read_builds.
get_buildreadReturns metadata for a specific build without jobs or expanded pipeline information. Scope: read_builds.
get_build_test_engine_runsreadReturns Test Engine runs data for a specific build, used to look up test runs. Scope: read_builds.
create_buildhigh riskTriggers a new build on a pipeline for a specific commit and branch, with optional environment variables, metadata and author information. It carries destructiveHint false yet executes pipeline commands, which Buildkite cites as the reason not to treat that annotation as a read-only allowlist. Scope: write_builds.
cancel_buildhigh riskCancels a running build on a pipeline. Annotated destructive. Scope: write_builds.
rebuild_buildhigh riskRebuilds or retries an entire build on a pipeline. Annotated destructive. Scope: write_builds.
list_jobsreadLists jobs for a build with optional state filtering and cursor-based pagination. Scope: read_builds.
get_jobreadReturns a job by UUID, scoped to a build when a pipeline slug and build number are given, or organization-wide when both are omitted. Scope: read_builds.
get_job_envreadReturns the environment variables for a specific job in a build, which is where CI credentials typically live. It requires its own read_job_env scope.
unblock_jobhigh riskUnblocks a blocked job so it can continue execution, releasing a gate that was there for a person to approve. Annotated destructive. Scope: write_builds.
retry_jobhigh riskRetries a specific job that failed or timed out in a build. Annotated destructive. Scope: write_builds.
search_logsreadSearches log entries using regex patterns with optional context lines, over the Parquet conversion of the job's logs.
tail_logsreadShows the last N entries from the log file, for recent errors and status checks.
read_logsreadReads log entries from the file, optionally starting from a specific row number.
list_artifacts_for_buildreadLists a build's artifacts across all its jobs with file details, paths, sizes, MIME types and download URLs. Scope: read_artifacts.
list_artifacts_for_jobreadLists an individual job's artifacts with file details, paths, sizes, MIME types and download URLs. Scope: read_artifacts.
get_artifactreadDownloads a specific artifact's content, returned base64-encoded, so arbitrary build output lands in the model's context. Scope: read_artifacts.
list_annotationsreadLists the annotations for a build or a specific job. Scope: read_builds.
create_annotationhigh riskCreates an annotation on a build or a specific job, visible to everyone looking at that build. Annotated destructive. Scope: write_builds.
list_testsreadLists tests in a Test Engine suite with execution metrics aggregated over a selected time range, with filtering, metric sorting and pagination. Scope: read_suites.
get_testreadReturns a specific test with additional metadata for failed test executions. Scope: read_suites.
list_test_runsreadLists all test runs for a test suite in Test Engine. Scope: read_suites.
get_test_runreadReturns a specific test run in Test Engine. Scope: read_suites.
get_failed_executionsreadReturns failed test executions for a run, optionally expanding to full error messages and stack traces. Scope: read_suites.

What Buildkite MCP exposes

Buildkite MCP groups its 56 tools into 12 categories, each with a suggested starting policy.

All 56 tools as JSON, ready to paste.

Category	Covers	Access	Suggested policy
Clusters & Queues	Listing and reading clusters with their default queues and configuration, creating and updating clusters, listing and reading queues with their dispatch status and agent configuration, creating and updating queues, and pausing or resuming queue dispatch	Read / Write	pause_cluster_queue_dispatch stops new jobs reaching agents without anything appearing broken, which is the quiet failure here. Every write needs the write_clusters token scope
Pipelines & Schedules	Listing and reading pipelines with their configuration, steps, environment variables and build statistics, creating YAML pipelines and updating existing ones, and listing, reading, creating and updating pipeline schedules with their cron expressions, branches and environment variables	Read / Write	A pipeline is executable configuration and a schedule makes it run unattended on a cron. get_pipeline returns environment variables as part of the configuration, so treat the read as sensitive too
Cache Registries	Listing and reading a cluster's cache registries with their policy and default status, creating and updating them, setting another registry as the cluster's default and deleting one with its cache metadata	Read / Write	delete_cache_registry is the only true delete on this surface. A cluster's default registry cannot be deleted, and these tools are absent from MCP server v1.24.0 and earlier
Builds	Listing builds for an organization or a pipeline as lightweight summaries, reading a single build's metadata, getting its Test Engine runs, triggering a new build for a commit and branch with optional environment variables, cancelling a running build and rebuilding one	Read / Write	create_build is annotated destructiveHint false but starts a build and executes pipeline commands, which Buildkite gives as the reason not to treat that annotation as a read-only allowlist. It accepts environment variables, so it can inject values into the run
Jobs	Listing a build's jobs with state filtering, reading a job by UUID at build or organization scope, unblocking a blocked job, retrying a failed or timed-out job, and retrieving a job's environment variables	Read / Write	get_job_env returns a job's environment variables, which is where CI credentials typically live; it needs its own read_job_env scope, so leave that scope off the token unless the agent genuinely needs it. unblock_job releases a gate a person was meant to approve
Test Engine	Listing tests in a suite with execution metrics over a time range, reading a specific test with failure metadata, listing and reading test runs, and retrieving failed executions with optional full error messages and stack traces	Read	Entirely read-only under the read_suites scope. get_failed_executions can expand to full stack traces, which often contain file paths and occasionally data from the system under test
User & Organization	The current API access token with its scopes and UUID, the user account that owns the token, and the Buildkite organization that token belongs to	Read	Read-only. access_token is the fastest way to confirm what the connection can actually do, since every other tool is bounded by that token's scopes
Cluster Secrets	Listing a cluster's secrets with their details, reading a specific secret's details, and creating a secret with an optional description and access policy	Read / Write	Secret values are write-only and never returned by the Buildkite API or the MCP server, so the reads expose metadata rather than material. create_cluster_secret introduces a credential into the CI environment
Logs	Searching log entries with regex patterns and optional context lines, showing the last N entries for recent errors, and reading entries from a specific row number, all over Parquet conversions of the raw job logs	Read	Read-only, but the Parquet copies persist: logs for terminal jobs are stored indefinitely, locally under the home directory or /tmp for the local server and in the Buildkite platform for the remote one. BKLOG_CACHE_URL can redirect that cache to an S3 bucket
Artifacts	Listing a build's artifacts across all its jobs and an individual job's artifacts with file details, paths, sizes, MIME types and download URLs, and downloading a specific artifact's content	Read	get_artifact returns the content base64-encoded, so arbitrary build output lands in the model's context. Scope by what the pipeline actually produces rather than allowing the whole artifact surface
Agents	Listing agents in an organization with their connection state, host details, version, current job and pause status, and reading a specific agent with its metadata	Read	Read-only under the read_agents scope. Host details and metadata describe the build infrastructure, so treat the output as internal
Annotations	Listing the annotations on a build or a specific job, and creating an annotation on either	Read / Write	create_annotation is annotated destructive and writes content visible to everyone looking at the build, which makes it the agent's voice in a shared place

Connect Buildkite MCP to your AI agent

Four steps, under ten minutes.

01
Sign in to NeuralTrust
Open the NeuralTrust platform, sign in and go to Getting started, then Connect your tools.
02
Choose your agent
When asked which agent you use, pick Claude Code, Codex, Cursor, Windsurf, Copilot or your own code.
03
Connect Buildkite
Find Buildkite in the tool list and connect it.
04
Connect your agent
Follow the steps on screen to add the config to your agent, then send the test prompt.

Permissions down to the single tool

You do not allow Buildkite MCP or block it. You allow the exact tools each agent can call, one by one.

Buildkite MCP	56 TOOLS AVAILABLE
Code review agent	4 tools, read only
Issue triage bot	9 tools
Platform team assistant	all 56 tools

Tool by toolConnecting the server is not the unit of access. Each tool is granted on its own.
Default denyA tool you have not enabled is never exposed to the agent.
Approval on writesTools that change or delete things can require a human to confirm.

Is Buildkite MCP secure?

One endpoint instead of raw credentials. Every call is checked against policy and logged.

AI agentsConnect through your MCP client configuration.	NeuralTrustApply controls based on your configuration.	Buildkite MCP56 documented tools, each carrying standard MCP annotations that Buildkite describes as hints that grant and enforce nothing. 21 are write tools, 14 of them annotated destructive. Toolsets can be selected through the X-Buildkite-Toolsets header on the remote server or --enabled-toolsets locally, and a --read-only flag and least-privilege token scopes are the controls that actually bind.
Coding assistants	Connection & credentialsper user	Clusters & Queues10 tools
Internal copilots	Tool access policiesdeny by default	Pipelines & Schedules8 tools
Workflow automations	Request & response inspectioninline	Cache Registries6 tools
Compatible MCP clients	Activity monitoringalerts and logs	All other tools32 tools