The tool that changes a workflow is find_affected_targets: it turns a diff into the set of targets that need rebuilding, which is the same question CI asks and the one an assistant usually guesses at. Queries are read-only but can be slow — a bare //... over a large workspace will make you wait.
An MCP server over the Bazel command line. It runs queries, builds and tests inside your workspace and returns the results as structure rather than scrollback — failure diagnostics, per-target pass and fail with log excerpts, and dependency graphs an assistant can reason over.
- bazel_build — a build with structured failure diagnostics; extra Bazel flags such as --config=ci or -c opt pass through
- bazel_test — tests with per-target pass and fail results and excerpts from the failure logs
- bazel_query — an arbitrary query expression, read-only but expensive on broad patterns like //...
- list_targets — every target matching a package pattern, defaulting to the whole workspace
- get_deps and get_rdeps — a target's dependencies to a given depth, and its reverse dependencies within a scope, both excluding the target itself
- show_target_info — the BUILD rule definition for a target, noting that macro-generated targets may differ from the on-disk file
- explain_build_file — the contents of a BUILD file for analysis
- find_affected_targets — every target affected by a set of changed files, which is the CI-narrowing question
Uv, and a Bazel workspace for the commands to run in. Clients launch it with uvx bazel-mcp-server over stdio; if your client does not start it from the workspace root, pass --workspace-root explicitly. --bazel-path selects bazelisk or another binary, and --timeout and --max-output-chars bound how long a command may run and how much output comes back.
One command — uvx bazel-mcp-server