aggregate_suite_failures
Parse a CI test run and group failures by error signature. Deduplicates repeated errors and categorizes them as assertion, timeout, network, or crash. Use this as the first step before triage.
LABSCO SUMMARY
Checking for applied database migrations before recommending a rollback is the detail that separates this from a test-failure summariser.
Every release triage conversation ends with 'can we just roll it back', and the answer depends on whether a migration went out with it — which is a repository question, not a CI question. Including it in the readiness analysis means the recommendation accounts for the escape route actually being available. The rest of the pipeline is the right sequence for the problem: deduplicate first so the count is real, discount known flakes so the signal is real, then correlate against the diff so causation is at least plausible. The temporal pattern detector is the unusual one and earns its place — a failure that only happens at a particular hour is a category people waste whole afternoons on before someone notices the timestamps.
What it is
A release-triage pipeline in six tools that runs in sequence: aggregate failures, score them against flakiness history, correlate them with changed files, look for time-based patterns, check rollback readiness, and produce a recommendation.
What you get
- aggregate_suite_failures parses a CI run and groups failures by error signature, deduplicating the repeats that make a failure list look worse than it is.
- cross_reference_flakiness scores each failure against a flakiness history, which is what separates a real regression from a test that fails every third Tuesday.
- correlate_code_changes matches changed files against failing tests to work out which failures the release could plausibly have caused.
- detect_temporal_failure_patterns looks at failure timestamps for chronometric patterns — the class of failure that is about time of day rather than about code.
- analyze_rollback_readiness scans for versioned database migration files, because a release with an applied migration is not one you can simply roll back.
- generate_release_recommendation combines the failures, the flakiness history and the change correlation into the actual decision.
Requirements
Nothing to supply — it works on the CI output and repository you hand it.
Setup effort
One command — npx -y release-readiness-triage-mcp
USE CASES
01
Finding out how bad the failure list actually is
Group failures by error signature so repeats collapse, then score them against flakiness history to see which are known noise.
02
Working out whether this release caused it
Match the failing tests against the files that changed, so the discussion is about plausible causes rather than about everything that is red.
03
Catching the failures that are about time, not code
Analyse failure timestamps for chronometric patterns — the ones that survive every code-level investigation because the code was never the problem.
04
Answering 'can we roll it back'
Scan for versioned migration files before assuming a rollback is available, then generate the recommendation with that constraint included.
6 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
analyze_rollback_readiness
Scans a repository for versioned database migration files (Flyway V*.sql, Prisma migration.sql, Liquibase XML/YAML) and classifies each operation as additive (rollback safe) or destructive (forward-fix only). Returns rollback_eligible, a list of blocking_migrations with file and line, and deployment_strategy. Use before recommending deployment to determine whether a rollback is safe after go-live.
correlate_code_changes
Match a list of changed files against failing tests to determine which failures are directly caused by the code changes in this commit. Returns a correlation mapping.
cross_reference_flakiness
Given a list of test failures and a flakiness history, score each failure by how likely it is to be a known flaky test vs a real regression. Returns probability scores per test.
detect_temporal_failure_patterns
Analyzes a history of test failures with timestamps to detect chronometric patterns: failures that cluster at the same UTC hour (hourly jobs), same day of month (billing runs), same weekday (scheduled jobs), or around DST transitions. When a pattern is found, the failure is a time artifact — not a code regression. The agent should schedule a re-run at a different time rather than investigating the source code.
generate_release_recommendation
The final step: combines failures, flakiness history, and code change correlation to produce a GO / NO_GO / INVESTIGATE verdict with confidence score and a breakdown of blockers vs safe-to-ignore failures.
BEFORE YOU INSTALL
What to know first
Tools you get
6 tools when we connected.
Requires
npx on PATH
CONTEXT COST
Light Standing cost
Rated by the size of the 6 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Add the block to your client, or run the command directly.
Server setup
Configuration file
JSON
{
"mcpServers": {
"release-readiness-triage-mcp": {
"command": "npx",
"args": [
"-y",
"release-readiness-triage-mcp"
]
}
}
}npx
TERMINAL
npx -y release-readiness-triage-mcp
