BuildPulse BuildPulse
Model Context Protocol

BuildPulse, in your agent.

Surface flaky tests, CI run history, and coverage health directly in Claude, Cursor, ChatGPT, and any MCP-aware tool. One install, your existing BuildPulse token, no infra.

Install in your client

The MCP ships two ways: a hosted remote server with OAuth (recommended — no token to copy), and an npm package for stdio clients. Tool surface is identical either way.

Recommended — URL only, no token

For Claude Code, Claude.ai, ChatGPT, and any client that handles /.well-known/oauth-authorization-server: point it at https://mcp.buildpulse.io/mcp and the client will run the OAuth flow on first use. You sign in with your existing BuildPulse account — no API token to generate, no env vars to set.

Claude Code (CLI) recommended

Add an .mcp.json at the root of your repo (or to ~/.mcp.json for global use). On the next session start, Claude Code will pop a browser to complete OAuth.

{
  "mcpServers": {
    "buildpulse": {
      "type": "http",
      "url": "https://mcp.buildpulse.io/mcp"
    }
  }
}

Claude.ai (web) recommended

In Claude.ai → Settings → Connectors, click Add custom connector and paste the URL below. You'll be redirected to BuildPulse to sign in once, then the connector is live.

https://mcp.buildpulse.io/mcp

OAuth discovery doc: /.well-known/oauth-authorization-server

ChatGPT / OpenAI recommended

ChatGPT Plus, Team, and Enterprise can add the hosted remote MCP via Settings → Connectors → Custom connector. Same URL, same OAuth flow as Claude.ai — both clients use RFC 8414 discovery.

https://mcp.buildpulse.io/mcp

Stdio clients (fallback)

For clients that don't speak Streamable HTTP yet, install the npm package and authenticate with an API token. Create one (it starts with bp_) at buildpulse.io → Organization Settings → API Tokens (the same token works against the Platform API). API and MCP access require a plan that includes them — see pricing.

Claude Desktop stdio

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows). Restart Claude.

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

Cursor stdio

Edit .cursor/mcp.json in your project, or ~/.cursor/mcp.json globally.

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

Or use a deep link: Install in Cursor →

VS Code (Copilot Chat) stdio

In Settings → MCP Servers, add:

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

Cline / Continue / Windsurf stdio

All three read an mcpServers block; use the same JSON as Claude Desktop in their respective config files (~/.continue/config.json, ~/.codeium/windsurf/mcp_config.json, etc.).

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

Other ways to get it

npm

@buildpulse/mcp — the stdio server used by every config above.

npx -y @buildpulse/mcp

Claude Code one-liner

Registers the hosted server; OAuth runs on first use.

claude mcp add --transport http buildpulse https://mcp.buildpulse.io/mcp

MCP Registry

Listed on the official Model Context Protocol registry as io.github.BuildPulseLLC/buildpulse-mcp. Clients that browse the registry can install it from there.

Smithery

Also on Smithery, which writes the mcpServers entry into your client config.

npx -y @smithery/cli install @buildpulse/mcp --client claude

Source

Open source on GitHub: BuildPulseLLC/buildpulse-mcp (Go). Issues and pull requests welcome.

Tools the model can call

Nine read-only tools. They are intent-shaped, not 1:1 with HTTP endpoints. Every output that names a test or repository includes a web_url deep link back to BuildPulse. The typical flow is discover then scope: list_my_organizations to find the id for multi-tenant users, then list_repositories to find the name values to pass as repository on the rest of the tools.

list_my_organizations

List every BuildPulse organization the current session can access. Multi-tenant users call this first to discover the id to pass back as organization_id on subsequent tool calls. Single-tenant callers get a one-element list and don't need it.

e.g. "Which BuildPulse orgs do I have access to?"

list_repositories

List the repositories BuildPulse is monitoring for the current organization. Use the returned name values as the repository argument on the repo-scoped tools below — the model should call this whenever the user asks a repo question without naming a repo, rather than asking them to type one.

e.g. "What repos do I have in BuildPulse?"

find_flaky_tests

Search a repository's flaky inventory. Filter by tags, free-text on test name / file, or a since-date. Default sort is by disruptiveness. Accepts an optional organization_id for users with access to multiple orgs.

e.g. "What flaky tests have I had this week tagged auth?"

get_test_history

Up to 10 most-recent disruption events for one test, with build URLs and failure messages — perfect for cross-referencing regressions with commits.

e.g. "Why does test_login_success keep failing?"

list_recent_submissions

Recent CI runs for a repo. Reach for this when the user asks "why is CI red?" or "what just broke?".

e.g. "Show me the last 10 CI runs for acme/widgets."

get_submission_test_results

Individual test results for one CI run, using a submission id from list_recent_submissions. status="failed" narrows to the failures and errors. Each result carries name, suite, file, class, duration, failure message, and the run count (1 = first attempt, 2+ = retries).

e.g. "Which tests failed in the last run on main?"

get_recent_failures

Every test that failed in any of the last N CI runs (default 10), aggregated by test identity with failure count, most recent failure time, build URL, and message. Not filtered by the flakiness threshold, so it catches one-off failures that find_flaky_tests would not.

e.g. "What has failed in the last 10 runs?"

get_repo_flakiness

Current flakiness percentage for a repo over the last 14 days, with the color band (green / yellow / red).

e.g. "How flaky is widgets right now?"

get_repo_coverage

Latest coverage percentage, with the same color bands as the README badge.

e.g. "What's our coverage on widgets?"

Guided prompts

The MCP also ships four built-in prompts that show up in your client's slash-prompt picker — one click, multi-tool workflows.

/triage_flaky_tests

Walk through the flakiest tests in a repo and propose next actions (quarantine, owner, root-cause hypothesis).

/ci_health_check

One-shot health snapshot: flakiness %, coverage %, and the top three flaky tests of the week.

/explain_test_failure

Given a test_id, pull recent disruption history and propose a root-cause hypothesis.

/whats_red

What broke my CI? Lists recent runs and identifies what's currently failing.