BuildPulse BuildPulse MCP
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 a Bearer token. The token is a 40-char hex string from app.buildpulse.io → Organization Settings → API Tokens (the same token works against the Platform API).

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": "your-40-char-hex-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": "your-40-char-hex-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": "your-40-char-hex-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": "your-40-char-hex-token" }
    }
  }
}

Tools the model can call

Tools 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_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.