What can you do with this server?

This server exposes Bazel build system capabilities to AI assistants via the Model Context Protocol (MCP), allowing you to query, build, test, and analyze Bazel workspaces. * bazel_query: Run arbitrary Bazel query expressions with configurable output formats (label, build, xml, package, location, graph, etc.) * list_targets: List all targets in a package, subtree, or entire workspace using patterns like //... or //pkg/... * get_deps: Retrieve direct or transitive dependencies of a target up to a configurable depth * get_rdeps: Find all targets that depend on a given target within a specified scope * show_target_info: Display the BUILD rule definition for a target using bazel query --output=build * find_affected_targets: Identify which targets are affected by changes to specific files * bazel_build: Run bazel build on one or more targets with optional flags, returning stdout, stderr, and exit code with structured failure diagnostics * bazel_test: Execute bazel test and get structured pass/fail results including failure log excerpts and duration per test target * explain_build_file: Read and return the contents of a BUILD file (by path relative to workspace root) for analysis

Which integrations are available for this server?

Provides tools for interacting with the Bazel build system, enabling AI assistants to run queries, list targets, get dependencies, perform builds and tests, and analyze BUILD files.

bazel-mcp

by saeid-rez

Overview Schema Source Related Servers Discussions Admin

Python

Local

Bazel MCP

A Model Context Protocol server that exposes Bazel build system capabilities to AI assistants.

Repo: github.com/saeid-rez/bazel-mcp

Tools

Tool	Description
`bazel_query`	Run arbitrary `bazel query` expressions
`bazel_cquery`	Run configured `bazel cquery` expressions (select() and platforms)
`bazel_aquery`	Run action `bazel aquery` expressions (compiler flags, commands)
`list_targets`	List targets in a package or subtree
`get_deps`	Direct or transitive dependencies of a target
`get_rdeps`	Reverse dependencies within a scope
`show_target_info`	Rule definition via `query --output=build`
`find_affected_targets`	Find targets affected by changed files
`bazel_build`	Run `bazel build` with structured failure diagnostics
`bazel_test`	Run `bazel test` with structured target and failed-case results
`explain_build_file`	Read BUILD file contents for analysis

Related MCP server: gemini-cli-mcp-slim

Usage

Requires uv. Configure the server with a Bazel workspace path if your MCP client does not start it from that workspace.

Antigravity (agy)

Add the following to ~/.gemini/config/mcp_config.json:

{
  "mcpServers": {
    "bazel": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/saeid-rez/bazel-mcp",
        "bazel-mcp-server"
      ]
    }
  }
}

Bazel commands run in your active workspace by default. If Antigravity does not start the server from your Bazel workspace, pass --workspace-root explicitly:

{
  "mcpServers": {
    "bazel": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/saeid-rez/bazel-mcp",
        "bazel-mcp-server",
        "--workspace-root",
        "/path/to/your/bazel/workspace"
      ]
    }
  }
}

OpenCode

Add the following to opencode.json or opencode.jsonc. Replace /path/to/your/bazel/workspace with the absolute path to your Bazel workspace.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "bazel": {
      "type": "local",
      "command": [
        "uvx",
        "--from",
        "git+https://github.com/saeid-rez/bazel-mcp",
        "bazel-mcp-server",
        "--workspace-root",
        "/path/to/your/bazel/workspace"
      ],
      "enabled": true
    }
  }
}

GitHub Copilot CLI

Add the following to ~/.copilot/mcp-servers.json. Replace /path/to/your/bazel/workspace with the absolute path to your Bazel workspace.

{
  "mcp": {
    "servers": {
      "bazel": {
        "command": "uvx",
        "args": [
          "--from",
          "git+https://github.com/saeid-rez/bazel-mcp",
          "bazel-mcp-server",
          "--workspace-root",
          "/path/to/your/bazel/workspace"
        ],
        "protocol": "stdio"
      }
    }
  }
}

Alternatively, run /mcp add bazel inside Copilot CLI and provide the same command and arguments.

Install With uv

To install the server persistently instead of running it from GitHub, run:

uv tool install bazel-mcp-server

Then use the following installed-server configuration in place of the GitHub-based command above. Include --workspace-root and its path when the client does not start the server from the Bazel workspace.

Antigravity (agy):

{
  "mcpServers": {
    "bazel": {
      "command": "bazel-mcp-server",
      "args": ["--workspace-root", "/path/to/your/bazel/workspace"]
    }
  }
}

OpenCode:

{
  "mcp": {
    "bazel": {
      "type": "local",
      "command": ["bazel-mcp-server", "--workspace-root", "/path/to/your/bazel/workspace"],
      "enabled": true
    }
  }
}

GitHub Copilot CLI:

{
  "mcp": {
    "servers": {
      "bazel": {
        "command": "bazel-mcp-server",
        "args": ["--workspace-root", "/path/to/your/bazel/workspace"],
        "protocol": "stdio"
      }
    }
  }
}

Cursor

Add this to .cursor/mcp.json in the Bazel workspace.

{
  "mcpServers": {
    "bazel": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/saeid-rez/bazel-mcp", "bazel-mcp-server"]
    }
  }
}

Bazel commands run in your open workspace by default.

If Cursor does not start the server from the Bazel workspace, pass the workspace explicitly:

{
  "mcpServers": {
    "bazel": {
      "command": "uvx",
      "args": [
        "bazel-mcp-server",
        "--workspace-root",
        "/path/to/your/bazel/workspace"
      ]
    }
  }
}

Other optional flags:

bazel-mcp-server --bazel-path bazelisk --timeout 600 --max-output-chars 64000

Development

Clone the repo and run tests locally:

git clone https://github.com/saeid-rez/bazel-mcp
cd bazel-mcp
uv sync --group dev
uv run pytest

Available Tools

8 tools

bazel_buildB

Run a Bazel build and return stdout, stderr, and exit code.

options are passed as extra bazel flags (e.g. --config=ci, -c opt).

ParametersJSON Schema

Name	Required	Description	Default
`targets`	Yes
`options`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide basic info (not read-only, destructive, or idempotent), but the description adds no behavioral context beyond the build action. It does not disclose side effects like file system changes, concurrency, or required permissions, which are important for a build tool with openWorldHint true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, front-loading the core purpose. Every sentence adds value without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers return values but lacks details on side effects, failure behavior, or prerequisites. Given the complexity (3 parameters, output schema exists), it is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the 'options' parameter ('extra bazel flags') but does not mention 'targets' or 'timeout'. With schema description coverage at 0%, the description insufficiently compensates, leaving key parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Run a Bazel build' and the resource, and specifies the return values (stdout, stderr, exit code). It distinguishes from siblings like 'bazel_test' by focusing on the build action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'bazel_test', 'bazel_query'). It only describes what it does, missing context on prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bazel_queryA

Read-onlyIdempotent

Run an arbitrary Bazel query expression.

Query is read-only but can be expensive on broad patterns like //... output_format: label, build, xml, package, location, graph, etc.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`output_format`	No		label

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds a valuable behavioral warning about potential expensiveness on broad patterns, which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the purpose, and contains no extraneous words. Every part serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is an output schema, return values are covered. However, for a tool with complex query syntax, the description does not explain how to form queries or provide examples. It is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It lists example values for output_format, adding meaning beyond the schema. However, the 'query' parameter is only described implicitly as 'Bazel query expression', which is minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Run' and the resource 'arbitrary Bazel query expression', distinguishing it from siblings like build and test tools. It also notes the read-only nature, adding clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions the tool is read-only and can be expensive on broad patterns, providing some context. However, it does not explicitly state when to use this tool over alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bazel_testB

Run Bazel tests and return structured pass/fail results with failure log excerpts.

ParametersJSON Schema

Name	Required	Description	Default
`targets`	Yes
`options`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`exit_code`	Yes
`summary`	Yes
`targets`	No
`stdout`	No
`stderr`	No

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate the tool is not read-only (readOnlyHint=false) but not destructive. The description adds that it returns results and failure excerpts, but it omits side effects like test execution triggering builds or modifying test caches. More detail on behavioral implications would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently communicates the core action and result. It is front-loaded with the verb and resource, and every word adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic return value (structured results with excerpts) and action (run tests), but it lacks details on parameter roles, expected behavior for timeouts or options, and potential side effects. Given the tool has an output schema and three parameters, more context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for its three parameters (targets, options, timeout). The tool description does not explain any of these parameters, leaving the agent to infer their meaning from names alone. For a critical parameter like 'targets', explicit semantics would be valuable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Run Bazel tests'. It also specifies the return value: 'structured pass/fail results with failure log excerpts'. This distinguishes it from sibling tools like bazel_build (build) and bazel_query (query) by focusing specifically on testing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as bazel_build or bazel_query. It does not mention scenarios where this tool is appropriate or inappropriate, nor does it reference any prerequisites or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_build_fileB

Read-onlyIdempotent

Return BUILD file contents for analysis by the host LLM.

path is relative to the workspace root (e.g. foo/bar/BUILD or foo/bar).

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds no additional behavioral context (e.g., error handling, auth needs, or side effects), offering no value beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first states the purpose, the second explains the parameter format. No redundant or irrelevant content; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and an existing output schema, the description is largely complete. It covers what the tool returns and how to specify the path, though it lacks mention of error cases or file existence assumptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter schema has 0% coverage; the description compensates by specifying the path is relative to workspace root and provides examples (e.g., 'foo/bar/BUILD' or 'foo/bar'). This adds meaningful guidance beyond the schema's type and title alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns BUILD file contents for analysis, with a specific verb and resource. It distinguishes from siblings like bazel_build or bazel_query by its focus on file content retrieval, though not explicitly contrasted.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or when not to use it, leaving the agent to infer from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_depsA

Read-onlyIdempotent

Get dependencies of a target up to the given depth, excluding the target itself.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`depth`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and idempotent. Description adds the behavioral detail that the target itself is excluded from results, which is not inferable from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with verb, no unnecessary words. Efficiently conveys core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, output schema existence, and annotations, the description covers the essential behavior: depth-limited dependency retrieval excluding the target. No gaps for typical usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains 'depth' concept and 'target' is implicit, but does not fully describe parameter semantics or constraints beyond what is inferable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool retrieves dependencies of a target, with depth control and exclusion of the target itself. This specific verb+resource combination distinguishes it from siblings like get_rdeps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage when needing dependency information, but no explicit guidance on when to use this vs alternatives like get_rdeps or bazel_query. Missing when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_rdepsA

Read-onlyIdempotent

Find reverse dependencies of a target within scope, excluding the target itself.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`scope`	No		//...

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds behavioral detail: it excludes the target from results and respects scope, which annotations don't cover. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence with no wasted words. It could benefit from slightly more structure (e.g., separating target and scope), but it's efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (reverse deps) and existing annotations, the description covers core functionality but omits return format, scope semantics, and edge cases. It's minimally adequate but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'target' and 'scope' indirectly but doesn't explain their meanings (e.g., scope's default '//...' pattern). Missing parameter-level semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds reverse dependencies (specific verb+resource), and includes crucial nuances: within a scope and excluding the target itself. This distinguishes it from sibling tools like get_deps (forward deps).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through 'within scope' and 'excluding target', but lacks explicit guidance on when to use versus alternatives like get_deps, or when not to use. Sibling names hint at distinction, but no explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_targetsA

Read-onlyIdempotent

List all targets matching a package pattern.

Default //... lists targets across the entire workspace (can be slow). For a single package use //pkg or pkg (normalized to //pkg:all). For a subtree use //pkg/...

ParametersJSON Schema

Name	Required	Description	Default
`package`	No		//...

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds value by noting that the default pattern can be slow and explaining pattern normalization, which goes beyond structured data. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with 4 sentences, front-loading the purpose. Every sentence adds necessary detail without verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers core usage and performance considerations. Since an output schema exists, return values need not be explained. It is complete for a listing tool, though it omits behavior for empty results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description bears the full burden. It explains the 'package' parameter meaning, default value, and usage patterns (//pkg, //pkg/...), significantly enhancing understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists targets matching a package pattern, with a specific verb and resource. It provides examples of usage but does not explicitly differentiate from sibling tools like bazel_query, which may also list targets. However, the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on default vs. specific patterns and a performance warning. However, it does not advise when to use alternative tools like bazel_query or bazel_test for different query needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

show_target_infoA

Read-onlyIdempotent

Show the BUILD rule definition for a target (bazel query --output=build).

Macro-generated targets may differ from on-disk BUILD files.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the important caveat that macro-generated targets may differ from on-disk BUILD files, which is behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy. First sentence defines purpose, second adds a key nuance. Every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter, existing annotations, and an output schema, the description covers the main purpose and a key caveat. Missing target format details but otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter 'target' with no schema description. The description mentions 'target' but does not specify expected format (e.g., fully qualified, relative path). With 0% schema coverage, the description should provide more detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool shows the BUILD rule definition for a target and likens it to a specific Bazel query. It is specific and distinguishes from siblings like 'bazel_query'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool over siblings like 'bazel_query' or 'explain_build_file'. The comparison to 'bazel query --output=build' is implicit but not extended to tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Jun 21, 2026
- First observedbazel_build
- First observedbazel_query
- First observedbazel_test
- First observedexplain_build_file
- First observedget_deps
- First observedget_rdeps
- First observedlist_targets
- First observedshow_target_info

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-06-21 10:00 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: build, test, query, file explanation, dependency queries, target listing, and target info. No overlap or ambiguity.

Naming Consistency3/5

Three tools use the 'bazel_' prefix (bazel_build, bazel_test, bazel_query) while the rest use plain verb_noun (explain_build_file, get_deps, etc.). The inconsistency is noticeable but still readable.

Tool Count5/5

8 tools is well-scoped for a Bazel MCP server, covering the essential operations without unnecessary bloat.

Completeness4/5

Core workflows (build, test, query, dependency analysis, file inspection) are covered. Minor gaps like 'bazel run' or 'clean' are missing but not critical.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238

Related MCP Servers

mcp-cli-catalog
Shell Access
abcpro1
A
license
Not graded
quality
D
maintenance
An MCP server that publishes CLI tools on your machine for discoverability by LLMs
Updated 10 months ago (2025-11-16 20:50 UTC)
7 npm
1
MIT
gemini-cli-mcp-slim
AI & Machine Learning Command Line
tksfjt1024
A
license
Not graded
quality
C
maintenance
Thin MCP server wrapping the Gemini CLI for AI assistants, supporting workspace-aware multi-repository analysis and forward-compatible flags.
Updated 4 months ago (2026-05-08 05:51 UTC)
MIT
AI Knowledge Center MCP
Developer Tools Knowledge & Memory Command Line
AHappyAtlas
A
license
Not graded
quality
A
maintenance
Local-first MCP server that provides project context, verification gates, and structured tools for coding agents to discover knowledge, run diagnostics, and execute allowlisted commands within a repository.
Updated 2 months ago (2026-07-14 16:22 UTC)
24 npm
MIT
gavelofficial
Code Analysis Developer Tools
gavelcode
A
license
A
quality
A
maintenance
MCP server for gavel, a code-quality gate for Bazel monorepos. Exposes judge, findings, coverage and architecture tools so a coding agent can check its change against the quality gate (lint, coverage, layer rules) before declaring it done — all off the Bazel build graph, over just what changed.
Updated 7 days ago (2026-09-07 20:12 UTC)
8
10
Apache 2.0

Bazel MCP

Tools

Usage

Antigravity (agy)

OpenCode

GitHub Copilot CLI

Install With uv

Cursor

Development

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

gavelofficial