BuildPulse

Search 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 enumerate).

Return 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 BuildPulse is by definition unexpected). Default window is the last 10 submissions.

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.io/docs); it is not derived from test results. For users in multiple organizations, pass `organization_id` (call list_my_organizations first to enumerate).

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 — that means nothing has been uploaded recently, not that the suite is clean. For users in multiple organizations, pass `organization_id` (call list_my_organizations first to enumerate).

List the BuildPulse runner sizes the organization has configured: the `label` a workflow targets (the GitHub Actions `runs-on` value, e.g. bp-ubuntu-latest-x64-2x), CI provider, vCPU, memory, architecture, list price per minute and provisioning status. For CircleCI and Semaphore, `provider_config` holds the resource class or agent type the pipeline points at (never a token). Use this when editing a workflow onto BuildPulse runners or answering "which runner labels can I use?". An empty list with runners activated means no size has been added yet; `web_url` is the setup page. For users in multiple organizations, pass `organization_id`.

Report whether the organization has activated BuildPulse CI runners, and how to start if it has not. BuildPulse runners are drop-in runners for GitHub Actions, CircleCI and Semaphore that finish jobs about 2x faster at half the cost of the provider's hosted runners, with Test Intelligence (flaky-test detection, coverage and CI metrics) included with every minute. Every organization gets 3,000 free minutes a month, no card required. With a tenant: `status`, `billing_mode` (free: cardless, served from the monthly grant; metered: card on file; exempt: BuildPulse's own) and `activated_at`. Without one: `how_to_start` is a sentence you can relay, and `setup_url` (https://buildpulse.io/organizations/{orgId}/runners/setup) is where activation happens: the customer picks a size and changes one line in the workflow (the runs-on label, resource class or agent type). Call this before get_runner_usage when you do not know whether the organization uses runners. For users in multiple organizations, pass `organization_id`.

Return what the organization's BuildPulse runners did over the last `days` days (1-90, default 30): jobs, billable minutes, cost before free minutes, free minutes used and their value, net cost, p50 and p90 job duration in seconds, p50 queue wait (only when jobs measured it), and the same minutes priced at GitHub's hosted larger-runner list rate with `savings_percent`. Given as `totals` and as a `breakdown` per runner size, architecture and CI provider (highest cost first). `pricing` carries the published offer and the full rate card (BuildPulse and GitHub list price per size, free minutes per month, speedup), and is returned even when the organization has no runners, so use it for any estimate instead of remembering prices. Zeroed totals with an empty breakdown means nothing ran on BuildPulse runners in the window; check get_runner_status for whether runners are activated at all. For users in multiple organizations, pass `organization_id`.

Return 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.

Return 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.

Return 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`.

Takes no parameters.

List 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.

Return 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); single-tenant tokens see exactly the bound org's repos.