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.
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.
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.
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.
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?".
get_repo_flakiness
Current flakiness percentage for a repo over the last 14 days, with the color band (green / yellow / red).
get_repo_coverage
Latest coverage percentage, with the same color bands as the README badge.
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.