BuildPulse MCP server: 9 tools for flaky tests

A narrow connector for flaky-test triage, why the tool count changed between releases, and what the tools do not cover.

Checked 1 September 2026 · from The BuildPulse repository and source, npm and the server's own tools/list response

One of 91 guides to monitoring and developer tools. Each covers what an AI coding agent can get out of the tool through MCP, the protocol that lets the agent query the tool directly.

What is the BuildPulse MCP server?

It is BuildPulse's server for the Model Context Protocol. BuildPulse tracks flaky and disruptive tests across CI runs, so a connected agent can tell a real regression from a known flake.

The core tools follow one workflow. list_recent_submissions shows which CI runs uploaded results, get_repo_flakiness gives a health score, find_flaky_tests lists the offenders and get_test_history shows one test's recent failures with build URLs and commit hashes.

The 0.1.7 additions fill the gaps around that workflow. list_my_organizations and list_repositories find the right scope, get_submission_test_results opens one CI run, and get_recent_failures lists every test that failed in recent runs.

get_repo_coverage is the odd one out. It returns the coverage percentage from the most recent coverage report rather than anything about flakiness.

BuildPulse's nine tools stay deliberately close to test evidence: inventory, score, coverage, history, CI submissions and recent failures. That narrow focus does not make it an operational, agent-observability or cost connector.

For an agent, that means BuildPulse answers one question well: is this failure new, or is this test always like that. It cannot show the code, the pipeline configuration or the running service, so it is a companion to a repository connector rather than a replacement for one.

What can an AI agent do with BuildPulse?

find_flaky_tests returns BuildPulse test IDs, and get_test_history needs one. Running them in that order is the whole workflow.

What the tool definitions cost in context

A client that loads every tool definition at the start of a session spends this much context before the first question. Claude Code defers definitions by default through tool search, and loads a tool's definition when the agent needs it. The method below gives the version and date measured.

A context window is the amount of text a model can hold at once. A client that loads every tool definition upfront sends each tool's name, description and input schema to the model when the session starts. That list is charged whether or not a single tool is called.

On 0.1.5, 5 tools cost between 686 and 1,463 tokens, measured 24 August 2026. The 0.1.7 package registers 9 tools with longer descriptions, and its cost is still to be measured.

The 0.1.5 proportions were unremarkable, which is the point. Descriptions averaged 221 characters and schemas 336, so a narrow server with ordinary text cost almost nothing to keep connected.

Encodings: GPT-5.6, GPT-5.5 o200k_base; GPT-4, GPT-3.5 cl100k_base; Claude Haiku 4.5 to Opus 5 count_tokens. Counted 24 August 2026 from tools/list on the released npm package 0.1.5. It was run locally with a placeholder token.

Registration is static, so no BuildPulse account was involved. Figures cover name, description and input schema. The two models in column one share the o200k_base encoding, so they get one count. The spread is formatting, about 43%. Reasoning tokens are output, spent per request. This count is billed as input whenever the client loads it.

The Claude figures are measured rather than encoded. Anthropic publishes no local tokenizer. The definitions were sent to the API's count_tokens endpoint, and a no-tools baseline was subtracted. The range covers two tokenizer generations rather than two serializations. Haiku 4.5 and Opus 4.6 sit at the low end. Opus 5 and Sonnet 5 sit at the high end. The gap between them is a small fraction.

BuildPulse MCP server limits: where answers come back incomplete

Both limits below come from a bounded window that the results themselves do not mention.

How to configure BuildPulse MCP for agents

1. 1

   Expect a fourteen-day horizon

   find_flaky_tests, get_repo_flakiness and get_test_history all describe that window. get_recent_failures counts submissions instead, the last 10 by default.

2. 2

   Get the token from the right place

   The server's own startup error names the path: the BuildPulse app, then Organization Settings, then API Tokens.

3. 3

   Pair it with a repository connector

   The tools return build URLs and commit hashes, and something else has to open them.

4. 4

   Expect a small context cost

   The five-tool 0.1.5 build measured 686 tokens at the low end. The 0.1.7 build adds four tools, so expect more.

Paste this into your agent’s instructions

Every headline number here is bounded by a fourteen-day window that does not appear in the result. The block makes the agent say so.

When you answer using BuildPulse MCP tools, state:
- The repository the numbers cover.
- The window. find_flaky_tests, get_repo_flakiness and
  get_test_history all report the last fourteen days.
- Whether a coverage figure came from get_repo_coverage, which
  reads the most recent report rather than a period.
- For get_recent_failures, how many submissions it read.
Do not state that data does not exist. State that no results
were returned for the repository and window above.
Write your answer in ASD-STE100 Simplified Technical
English. Use short sentences with one idea in each.

Do you need the MCP server at all?

Yes, during triage. For a weekly review the BuildPulse web application is the better surface, and reading a dashboard costs no context at all.

The connector earns its place inside a failing build. An agent that can ask whether this failure is known, and get a commit hash back, saves the round trip to a browser.

For CI itself, a pipeline connector answers what ran and lets you re-run it. This one only reports on test outcomes.

Connect it during triage. Use the web application for periodic review of the same numbers.

BuildPulse MCP server setup

The package runs with npx and needs one token in BUILDPULSE_TOKEN. Without it the server exits before registering anything.

The startup message names where to find a token, which is unusual and worth using rather than searching the documentation.

claude mcp add-json "buildpulse" '{"command":"npx",
  "args":["-y","@buildpulse/mcp"],
  "env":{"BUILDPULSE_TOKEN":"<your-token>"}}'

{"mcpServers":{"buildpulse":{"command":"npx",
  "args":["-y","@buildpulse/mcp"],
  "env":{"BUILDPULSE_TOKEN":"<your-token>"}}}}

[mcp_servers.buildpulse]
command = "npx"
args = ["-y", "@buildpulse/mcp"]
env = { BUILDPULSE_TOKEN = "<your-token>" }

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

{"mcpServers":{"buildpulse":{"command":"npx",
  "args":["-y","@buildpulse/mcp"],
  "env":{"BUILDPULSE_TOKEN":"<your-token>"}}}}

{"mcpServers":{"buildpulse":{"command":"npx",
  "args":["-y","@buildpulse/mcp"],
  "env":{"BUILDPULSE_TOKEN":"<your-token>"}}}}

{"servers":{"buildpulse":{"command":"npx",
  "args":["-y","@buildpulse/mcp"],
  "env":{"BUILDPULSE_TOKEN":"<your-token>"}}}}

{"mcpServers":{"buildpulse":{"command":"npx",
  "args":["-y","@buildpulse/mcp"],
  "env":{"BUILDPULSE_TOKEN":"<your-token>"}}}}

{"mcpServers":{"buildpulse":{"command":"npx",
  "args":["-y","@buildpulse/mcp@0.1.7"],
  "env":{"BUILDPULSE_TOKEN":"<your-token>"}}}}

Read-only access, permissions and security

• BuildPulse exposes test evidence only

  All nine tools read. They create, update, delete and trigger nothing.

• The token is the whole boundary

  There is no scoping inside the server, so what the token can see is what the agent can see.

• Results carry links outward

  get_test_history returns CI build URLs and commit hashes, which points the agent at systems this connector does not cover.

• The tool list is small enough to audit

  Nine names and nine schemas can be read in full before connecting, which is not true of most servers here.

Troubleshooting

The server exits immediately

BUILDPULSE_TOKEN is not set. The server prints the requirement and names the path to a token: the BuildPulse app, Organization Settings, then API Tokens.

A known flaky test is missing

find_flaky_tests covers tests that failed intermittently in the last fourteen days. A test that was quiet for fourteen days is outside the window.

`get_test_history` returns nothing

It needs a BuildPulse test ID rather than a test name. Run find_flaky_tests first and pass the identifier it returns.

A catalog lists a different tool count

Check the version. The released 0.1.5 package registered five tools on 24 August 2026. The 0.1.7 package, published 14 September 2026, registers nine.

BuildPulse MCP server: Reference

What engineers report

BuildPulse published @buildpulse/mcp to npm on 17 May 2026, released 0.1.7 on 14 September 2026, and pushed the repository on 20 September 2026. It has no stars and little public discussion, so the figures below come from the package and the wire rather than from community reports.

Repository facts from the GitHub API and npm, retrieved 6 October 2026. Tool sizes come from the 0.1.5 package's own tools/list response on 24 August 2026. The 0.1.7 tool list comes from its tagged source.

Should you connect an agent to BuildPulse?

Yes. Best for leaving connected permanently, given how small its tool list is.

Strongest fit

Teams already uploading test results to BuildPulse who want flake triage without leaving the editor.

Main advantage

A small, read-only tool list, with a workflow that runs in two calls.

Main weakness

A fourteen-day horizon on the tools that matter, and no way to reach further back.

Operational risk

None from the tools themselves. Every one reads, and nothing triggers a build.

Frequently asked questions