Buildkite MCP Server adds job tools and smarter artifact and log handling

The Buildkite MCP Server has new tools for working with jobs, smarter artifact and log handling, and more scalable pagination for large builds and test runs.

Dedicated tools for inspecting jobs

Agents can now look up job details directly with list_jobs and get_job, filter by state (for example, only failed jobs), page through large builds efficiently, and pull full agent details only when needed. This makes it much faster for an agent to zero in on "why did this build fail?" without wading through unrelated build metadata. list_agents and get_agent also now include os_id, arch, and queue by default, so agents can see where a job is running without requesting the full, token-heavy agent response.

Note: get_build and list_builds no longer return job data, and no longer accept detail_level, job_state, or include_agent — use list_jobs or get_job to fetch jobs instead. Your MCP client picks up the updated tool definitions automatically, so there's nothing to reconfigure.

Safer, more efficient artifact downloads

Artifacts now come back the smart way: small text files (under 64 KiB) are returned inline immediately, while larger or binary files get a temporary, ready-to-use download link, no API token juggling required. Listing artifacts across a build is also much lighter now, roughly halving the amount of data returned on large builds, so agents spend less time and budget just listing files before getting to the one they actually need.

Note: list_artifacts_for_build and list_artifacts_for_job no longer include download_url, url, dirname, glob_path, or original_path on each item. Use get_artifact with the id and job_id from a list result to fetch an artifact's content or download URL.

More scalable test result retrieval

Fetching failed test executions from large test runs now paginates properly against the Buildkite API, instead of pulling everything back at once. This means agents can work through large test suites reliably rather than hitting limits on big runs.

More reliable log handling

Under-the-hood improvements to log parsing make searching and tailing build logs more robust against messy or unusually large log output, with fewer dropped or malformed lines when an agent is digging through logs to debug a build.

Better resilience to rate limits

The server now handles Buildkite API rate limiting more gracefully, automatically retrying with proper backoff instead of failing outright. Agents should see fewer transient errors during heavy usage.

These improvements apply to both the open-source MCP server and the Remote MCP server.