BuildPulse MCP server: 5 tools for flaky tests

A narrow connector for flaky-test triage, why the registry entry and the wire disagree, and what the tools do not cover.

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

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector 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 five 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.

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 five tools stay deliberately close to flaky-test evidence: inventory, score, coverage, history and CI submissions. 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 connecting costs before the first question

A context window is the amount of text a model can hold at once, and connecting uses some of it before the agent asks anything. Every tool the server registers sends its name, description and input schema to the model when the session starts. The tool list is charged whether or not a single tool is called.

5 tools cost between 686 and 1,463 tokens, among the smallest figures measured in this guide; fifteen connectors cost less.

The proportions are unremarkable, which is the point. Descriptions average 221 characters and schemas 336, so a narrow server with ordinary text costs 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 input, charged once at connection.

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, so nothing older is reachable.

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

   Do not budget context for it

   At 686 tokens this is among the cheapest connections measured here, so there is no reason to disconnect it between tasks.

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.
Never 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.5"],
  "env":{"BUILDPULSE_TOKEN":"<your-token>"}}}}

Read-only access, permissions and security

• BuildPulse exposes test evidence only

  None of its five tools creates, updates, deletes or triggers a build.

• 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

  Five names and five 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.

The registry lists a different tool count

Trust the wire. The released 0.1.5 package registers five tools, which is what was captured for this page on 24 August 2026.

BuildPulse MCP server: Reference

What engineers report

BuildPulse published @buildpulse/mcp to npm on 17 May 2026 and pushed the repository on 19 August 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 24 August 2026. Tool counts and sizes come from the released package's own tools/list response, which is the figure this page uses wherever a catalog disagrees.

Should you connect an agent to BuildPulse?

Yes. Best for leaving connected permanently, given that it costs under a thousand tokens to do so.

Strongest fit

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

Main advantage

One of the cheapest connections measured here, 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