mcpField
B
BuildPulse

BuildPulse

Remote
platform.buildpulse.ioDeveloper Tools0Updated 1d ago

About BuildPulse

BuildPulse is an MCP server for querying BuildPulse CI test analytics from AI agents and MCP clients. It provides repository-level views of flaky tests, CI runs, failures, and coverage through hosted or local transports.

Key features

  1. 01List organizations and repositories
  2. 02Search flaky-test inventories
  3. 03Inspect test and CI-run history
  4. 04Aggregate recent test failures
  5. 05Check repository flakiness and coverage
  6. 06Open linked BuildPulse results

Use cases

  1. 01Investigate a failing CI run
  2. 02Find recurring flaky tests
  3. 03Review recent failures across submissions
  4. 04Assess repository flakiness and coverage

MCP support

Provides BuildPulse tools, guided prompts, and resource templates to MCP clients. It supports hosted Streamable HTTP with OAuth 2.1 sign-in or tokens, and local stdio with an API token.

Configuration

Remote servers need no local install. Pick your client, then copy the config or install in one click.

Endpointhttps://mcp.buildpulse.io/mcp
Copy install command
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

Run commands in a terminal; paste JSON into the client’s MCP config and restart. Servers that need sign-in will prompt on first connect.

All endpoints
Streamable HTTPhttps://mcp.buildpulse.io/mcpAuth required
Packages
npm@buildpulse/mcp0.1.7

Tools

Details

From the project README

buildpulse-mcp, by BuildPulse

Runs on BuildPulse

Model Context Protocol server for the BuildPulse Platform API. Surface flaky tests, CI run history, and coverage health in Claude Desktop, Cursor, ChatGPT, Cline, Windsurf, Continue, Zed, VS Code Copilot, and any other MCP-aware AI agent.

npm version npm downloads License: MIT MCP Registry Install on Smithery Docs

Quickstart

Hosted (recommended) — nothing to install, no API token. Your client opens a browser and you sign in with your BuildPulse account (Google, GitHub, Bitbucket, Apple, or email):

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

Claude.ai, ChatGPT, Cursor, VS Code: add https://mcp.buildpulse.io/mcp as an HTTP/remote MCP server and complete the sign-in when prompted.

Local stdio — for clients that only spawn a process, or for scripts and CI where a browser sign-in is not possible. This path needs an API token:

BUILDPULSE_TOKEN=bp_... npx -y @buildpulse/mcp

See Authentication for where tokens come from and when you need one.

Try asking

  • "Why is CI red on web-client? Show me the failing tests from the last run."
  • "Which tests in platform-api have been flakiest this week, and where do they fail?"
  • "How well tested is agents? Give me flakiness and coverage."
  • "Which tests failed in more than one of the last 10 runs of api?"
  • "Triage the flaky tests in frontend and tell me which to quarantine first."

Install

npx -y @buildpulse/mcp

Or pin globally:

npm install -g @buildpulse/mcp

The package downloads the matching native binary for your platform on first install. Supported platforms: macOS arm64/x64, Linux arm64/x64, Windows x64.

Authentication

There are two ways to authenticate, and most people only need the first.

How you sign inNeeds an API token?Use it for
Hosted SSO (https://mcp.buildpulse.io/mcp)OAuth 2.1: your client opens the BuildPulse login (Google, GitHub, Bitbucket, Apple, or email) and stores a session for youNoClaude Code, Claude.ai, ChatGPT, Cursor, VS Code, and any client that supports remote MCP servers with OAuth
API tokenBUILDPULSE_TOKEN=bp_... for stdio, or an Authorization: Bearer bp_... header against the hosted URLYesLocal npx stdio, clients without OAuth support, scripts and CI

Get a token at https://buildpulse.io → Organization Settings → API Tokens. Tokens look like bp_<64 hex chars>; the older 40-character hex tokens still work. A token grants access to the same organizations your account does.

Configure

Hosted snippets sign you in via SSO. Stdio snippets need BUILDPULSE_TOKEN; replace bp_... with your token.

Claude Code

Hosted (SSO, no token):

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

Stdio (token):

claude mcp add buildpulse -e BUILDPULSE_TOKEN=bp_... -- npx -y @buildpulse/mcp
Claude Desktop

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

{
  "mcpServers": {
    "buildpulse": {
      "command": "npx",
      "args": ["-y", "@buildpulse/mcp"],
      "env": { "BUILDPULSE_TOKEN": "bp_..." }
    }
  }
}
Cursor

.cursor/mcp.json (per-project) or ~/.cursor/mcp.json (global). Hosted with SSO (Cursor prompts you to sign in the first time):

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

To use a token instead of signing in, add "headers": { "Authorization": "Bearer bp_..." }. For stdio, use the command / args / env shape from the Claude Desktop snippet.

VS Code (GitHub Copilot agent mode)

.vscode/mcp.json. Hosted with SSO (VS Code opens the sign-in when the server first starts):

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

To use a token instead, add "headers": { "Authorization": "Bearer bp_..." }. For stdio, use "type": "stdio" with the command / args / env fields from the Claude Desktop snippet.

Windsurf

~/.codeium/windsurf/mcp_config.json — same mcpServers block as Claude Desktop.

Cline

Cline → MCP Servers → Configure → paste the same mcpServers block into cline_mcp_settings.json.

ChatGPT

ChatGPT → Settings → Connectors → Create → URL https://mcp.buildpulse.io/mcp. ChatGPT completes the SSO sign-in; no token to paste.

Claude.ai

Settings → Connectors → Add custom connector → URL https://mcp.buildpulse.io/mcp. Sign in when prompted; no token.

Other clients

Continue, Zed, and anything else MCP-aware takes the same command / args / env fields. See the install hub for copy-paste snippets per client.

Organizations (multi-tenant)

Your BuildPulse token may grant access to more than one organization. Every repo-scoped tool takes an optional organization_id argument (the org's id UUID, discoverable via list_my_organizations):

  • Single-org tokens — omit organization_id. It auto-defaults to your one organization. Nothing changes; you never need to think about orgs.
  • Multi-org sessions (list_my_organizations returns 2+ orgs) — you must pass organization_id on every repo-scoped call (list_repositories, find_flaky_tests, get_test_history, list_recent_submissions, get_submission_test_results, get_recent_failures, get_repo_flakiness, get_repo_coverage). The org is not auto-selected — omitting it returns an error that lists every accessible organization and its UUID, so the agent can pick the right one and retry. Call list_my_organizations first to enumerate them.

This avoids silently querying the wrong (often empty) organization and getting confusingly empty results.

Tools

ToolPurpose
list_my_organizationsEnumerate the organizations this token can access; get the id (UUID) to pass as organization_id.
list_repositoriesList repositories in an organization.
find_flaky_testsSearch a repository's flaky test inventory; filter by tags, recency, free-text.
get_test_historyRecent disruption events for a specific test.
list_recent_submissionsRecent test-result submissions (CI runs) for a repository.
get_submission_test_resultsPer-test results for one submission (one CI run).
get_recent_failuresTests that failed across the most recent submissions, aggregated by test identity.
get_repo_flakinessCurrent flakiness % over the last 14 days. -1 means no recent results.
get_repo_coverageCurrent coverage % from the latest uploaded report. -1 means no report.

Repo-scoped tools accept an organization_id argument — required for multi-org sessions, optional (auto-defaulted) for single-org tokens. See Organizations above.

Every output that names a test or repo includes a web_url deep-link back to the BuildPulse web app — the same polish Sentry / Atlassian use in their MCP responses.

Prompts

The server also ships four guided prompts (slash-pickable in clients that support them):

  • /triage_flaky_tests
  • /ci_health_check
  • /explain_test_failure
  • /whats_red

Two transports

TransportBinaryWhere it goes
stdiocmd/mcpnpm → npx -y @buildpulse/mcp
Streamable HTTPcmd/mcp-remotehosted at https://mcp.buildpulse.io/mcp

Same tool surface; same prompts; same resources. Pick whichever your client supports. The stdio path is universal; the hosted variant is the path to Claude.ai web and ChatGPT, and authenticates with OAuth 2.1 SSO by default (PKCE + dynamic client registration; discovery at /.well-known/oauth-authorization-server) or a Bearer API token. The hosted server also publishes a landing page, robots.txt, sitemap.xml, and llms.txt on the bare host.

Resources

The server exposes two MCP resource templates so agents can pull state into context without a tool call:

  • buildpulse://repos/{repo}/flaky-tests
  • buildpulse://repos/{owner}/{name}/submissions

Environment variables

VariableRequiredDefault
BUILDPULSE_TOKENstdio only (hosted uses SSO)—
PLATFORM_API_URLnohttps://platform.buildpulse.io

The hosted server (mcp-remote) will refuse to start unless PLATFORM_API_URL is production or development Platform API. Local stdio (npx @buildpulse/mcp) is unchanged. See SECURITY.md for the threat model, tenant isolation, P1 rate limits (120 tool calls / token / minute), the tool audit log, RFC 7009 /oauth/revoke, and what we deliberately do not gate (HITL on reads, hiding tools, killing multi-step triage).

Build from source

git clone https://github.com/BuildPulseLLC/buildpulse-mcp
cd buildpulse-mcp
go build -o ./bin/buildpulse-mcp ./cmd/mcp
go build -o ./bin/buildpulse-mcp-remote ./cmd/mcp-remote

Requires Go 1.26+ (see go.mod).

Run tests

go test -race ./...

See CONTRIBUTING.md for the development workflow and CHANGELOG.md for release history.

License

MIT — see LICENSE.

Related

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.