BuildPulse
BuildPulse CI test analytics for AI agents — flaky tests, CI failures, flakiness, and code coverage.
Connector by BuildPulseLLC · GitHub account verified by the MCP Registry
Install
Works with Claude Code, VS Code, Codex, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.
npx agentmarket install connector/buildpulsellc-buildpulse-mcp
Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.
Remote endpoint
https://mcp.buildpulse.io/mcpRemote (HTTP)
Get the weekly diff
The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.
About
Reviews
Write a reviewNo reviews yet. Installed it? Reviews come from verified installers only. How reviews work
Permissions
What this server can do and what it asks for, from its tool list and install config. Checked Oct 25, 2026.
- Tools
- 9 read · 0 write · 0 deleteRead-only
- Secrets
- 2 (API keys, tokens or passwords)
- Install scripts
- Not scanned yet
- Runs as
- Node.js package
Tools by what they do 9
Read from the source code; the running server may list different tools.
Read 9 · Look things up without changing anything.
find_flaky_testsget_recent_failuresget_repo_coverageget_repo_flakinessget_submission_test_resultsget_test_historylist_my_organizationslist_recent_submissionslist_repositories
Secrets and settings it asks for
Secrets: values you paste in that let it act as you.
AuthorizationBUILDPULSE_TOKEN
Other settings (environment variables or headers).
PLATFORM_API_URL
Network hosts it talks to 1
mcp.buildpulse.io· found in remote endpoint, install command
Tools (9)
Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].
find_flaky_testsFind flaky testsSearch a repository's flaky / disruptive test inventory. Returns tests that have been intermittently failing in the last 14 days, sorted by disruptiveness (default) or recency. Filter by tags, free-text on test name / file / class, and a since-date. Use this as the entry point for any flaky-test investigation. An empty list means no test crossed the flakiness threshold in the window — it does not mean the repository is unmonitored; check get_repo_flakiness for whether results were uploaded at all. For users in multiple organizations, pass `organization_id` (call list_my_organizations first to …
get_recent_failuresGet failures across recent CI runsReturn tests that failed in any of the most recent N submissions for a repository, aggregated by test identity (name+suite+file). For each test, returns failure_count (how many of the recent runs it failed in), most_recent_failure_at, most_recent_build_url, and the failure message from the most recent occurrence. Unlike find_flaky_tests, this is NOT filtered by the statistical flakiness threshold — it surfaces every test that failed in the recent window, which matches workflows where customers only upload to BuildPulse after their own CI has already passed (so any failure observed by BuildPuls…
get_repo_coverageGet repo coverage %Return the current test coverage percentage for a repository, taken from the most recent coverage report uploaded to BuildPulse. `color` maps the value to green / light_green / yellow / red using the same thresholds as the BuildPulse coverage badge. Reach for this when the user asks "what's our coverage?", "how well tested is X?", "is the suite healthy?", or wants a repo health snapshot (pair it with get_repo_flakiness). `percentage` is -1 when no coverage report exists for the repository — BuildPulse only knows about coverage when the CI job uploads a report (see https://platform.buildpulse.i…
get_repo_flakinessGet repo flakiness %Return the current flakiness percentage for a repository over the last 14 days — the share of CI runs disrupted by tests that failed and then passed without a code change. Higher is worse: `color` maps the value to green / yellow / red using the same thresholds as the BuildPulse badge. Reach for this when the user asks "is the suite healthy?", "how flaky is X?", "how well tested is X?", or wants a repo health snapshot (pair it with get_repo_coverage), then drill into individual tests with find_flaky_tests. `percentage` is -1 when BuildPulse has no test results for the repository in the window …
get_submission_test_resultsGet per-test results for a submissionReturn the individual test results recorded against one submission (one CI run). Use `status="failed"` to filter to just the failures and errors — the typical "red build" set. Each result carries the test name / suite / file / class, the per-attempt duration in microseconds, the failure message, and the runner-recorded run count (1=first attempt, 2+=retries). Get a submission `id` from list_recent_submissions first.
get_test_historyGet test historyReturn the most-recent disruption (failure / flake) events for a specific test, identified by its BuildPulse test_id. Up to 10 events from the last 14 days. Each event includes the CI build URL and commit SHA — useful for correlating regressions with code changes. An empty list means the test has not been disrupted in that window; an unknown test_id is an error, not an empty result. Get test_id values from find_flaky_tests.
list_my_organizationsList my BuildPulse organizationsReturn every BuildPulse organization the current MCP session can access. Multi-tenant users must call this first to discover the `id` (UUID) of the organization they want to scope subsequent tool calls to — pass that `id` as the `organization_id` argument on find_flaky_tests / get_test_history / list_recent_submissions / get_repo_flakiness / get_repo_coverage. Single-tenant callers will see exactly one entry and don't need to pass `organization_id`.
list_recent_submissionsList recent CI runsList the most-recent test submissions (CI runs) for a repository. Each entry corresponds to one CI run that uploaded test results to BuildPulse. Reach for this first when a user asks "why is CI red?" or "what changed in the last hour". Each entry includes an `id` you can pass to get_submission_test_results to drill into the individual test results for that run.
list_repositoriesList repositories in a BuildPulse organizationReturn every repository BuildPulse is monitoring for the given organization, sorted alphabetically. An empty list means the organization has no repositories reporting to BuildPulse yet, not that the call failed. Call this whenever the user asks a repo-scoped question ("do I have flaky tests?", "why is CI red?") without naming a specific repo — the `name` field is what you pass to find_flaky_tests / list_recent_submissions / get_repo_flakiness / get_repo_coverage as their `repository` argument. For multi-tenant users, pass `organization_id` (call list_my_organizations first to enumerate); singl…
Signals
- Stars
- 0
- Forks
- 0
- Open issues
- 0
- Weekly downloads
- 19
- Last commit
- Oct 21, 2026 (7 days ago)
- Last release
- Sep 14, 2026 (1 month ago)
- Last package publish
- Sep 14, 2026 (1 month ago)
From GitHub (fetched Oct 24, 2026) and the package registry.
Details
- Registry name
io.github.BuildPulseLLC/buildpulse-mcp- Version
- 0.1.7
- Auth
- Bearer token, API key
- Packages
- npm @buildpulse/mcp
- License
- MIT
- Repository
- github.com/BuildPulseLLC/buildpulse-mcp
- First seen
- Oct 24, 2026
- Last checked
- Oct 25, 2026
Cite this page
BuildPulse MCP server. Agent Mart. https://agentmart.dev/connectors/buildpulsellc-buildpulse-mcp (last updated 2026-10-25)