MCP.Market

Release Readiness Triage MCP server

by vola-trebla·io.github.vola-trebla/release-readiness-triage-mcp·v0.2.0
No reviews yet

Aggregates CI failures, cross-references flakiness history, and outputs GO/NO_GO release verdicts.

B82/100grade B
Write a reviewInstall
What users say
No reviews yet
Be the first
Safety scan
B82/100

full report

Adoption
New

0 stars

Reviews

Write one

Nobody has reviewed Release Readiness Triage yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Release Readiness Triage tools (6)

write = sends, deletes, buys or posts

Read from the package source without running it. The installed server may list more.

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

  • 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

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

Public scan report

scanner v0.1.9 · 2026-09-27 · same rubric, same numbers if you re-run it

no findings
  • Code scan9 source files scanned25/25
  • –Live reliabilityno gateway calls yet and no remote to proben/a
  • –Tool poisoningtools not inspected (local package is not executed); not countedn/a
  • Auth qualitylocal package, no credentials required12/15
  • Maintenancelast push 131 days ago8/15
  • Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10
Overall 82/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

How Release Readiness Triage compares

Against every graded Developer tools MCP server, from our own scans and uptime checks. Updated after each scan run.

Safety score
82/100
higher than 60% of 1,119 Developer tools servers
Tools
6
the typical Developer tools server has 7
Tools that change things
0%
typical: 5%. Fewer write tools means less an agent can break

What its tools let an agent do: 5 read · 1 create

Install Release Readiness Triage in Claude Code, Cursor or VS Code

Runs npx -y release-readiness-triage-mcp on your machine. Read the scan report first; the gateway never runs local packages.

claude mcp add release-readiness-triage-mcp -- npx -y release-readiness-triage-mcp
Add to Cursor

What the publisher says

From the Release Readiness Triage repository's README, as published. We do not edit it. Read it on GitHub

🚦 release-readiness-triage-mcp

Stop reading CI logs. Start getting verdicts.

MCP server that aggregates test failures, cross-references flakiness history, and outputs a GO / CONDITIONALGO / NOGO / INVESTIGATE release decision — so your AI agent can triage a broken CI run in seconds instead of asking you to read 3000 lines of logs.

🤔 The problem

In any real codebase, CI always has something failing. The hard question isn't "are there failures?" — it's "are these failures real regressions, or just the usual noise?"

Answering that requires correlating three signals at once:

  • 🔍 Error signatures — is this the same failure repeated 12 times, or 12 different problems?
  • 📊 Flakiness history — is this test known to be unreliable?
  • 🔗 Code changes — is the failing test actually related to what changed?

An AI agent can't do this without structured tools. Raw CI logs are thousands of lines. Flakiness databases are external. Code→test mapping requires AST analysis. Without this MCP, the agent just guesses.

🛠️ Tools

aggregatesuitefailures

Groups failures by normalized error signature, deduplicates repeated errors, categorizes as assertion / timeout / network / crash. Pass customInfraPatterns for cloud-specific errors.

crossreferenceflakiness

Scores each failure against your flakiness history: KNOWN FLAKY, MILDLY FLAKY, or NO HISTORY.

correlatecodechanges

Matches changed files against failing tests. Works standalone or with pre-computed affected test lists from ast-impact-mapper-mcp.

generatereleaserecommendation

The final step. Outputs a risk-weighted verdict with confidence score and full breakdown. Supports format: "markdown" for GitHub PR comments and Slack.

Verdict levels:

  • NO_GO — regression in a critical domain (payment, auth, billing, checkout, security)
  • CONDITIONAL_GO — regression in a low/medium-risk domain (analytics, docs, admin); review before releasing
  • GO — all failures are known flaky or infrastructure noise
  • INVESTIGATE — too many unknowns to decide

Output includes:

  • aggregateriskscore — 0.0–1.0, probability union across all regression risk contributions
  • failingtestsanalysis[] — per-regression breakdown with domain, severity (HIGH/MEDIUM/LOW), riskcontribution, blastradius

detecttemporalfailure_patterns

Analyzes historical failures with timestamps to identify chronometric artifacts — failures that only appear at the same UTC hour, weekday, day of month, or during DST transitions. When a pattern is found, the failure is a time artifact, not a code regression.

Output includes:

  • temporalpatterndetected — boolean
  • clusters[] — per-test: patterntype (hourly | daily | monthly | timezoneshift), clustertimes, confidencescore

analyzerollbackreadiness

Scans a repository for versioned migration files (Flyway V*.sql, Prisma migration.sql, Liquibase XML/YAML) and classifies each operation as additive (rollback safe) or destructive (forward-fix only).

Detected destructive operations: DROP TABLE, DROP COLUMN, ALTER COLUMN TYPE, MODIFY COLUMN, TRUNCATE

Output includes:

  • rollback_eligible — boolean
  • blocking_migrations[] — each with file, line, operation, reason
  • deploymentstrategy — standard | forwardfix_only

🧪 What it looks like in practice

5 failures in CI. What's real, what's noise?

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

Release Readiness Triage: common questions

Is Release Readiness Triage MCP server safe?
Mostly: it is graded B (82/100). Read the Release Readiness Triage safety report
How do I install Release Readiness Triage?
It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.
Does Release Readiness Triage need an API key?
Not as far as the registry entry and our scan can tell: no credentials are declared or required.
Is Release Readiness Triage maintained?
The last commit was 166 days ago (2026-05-20). The latest release is v0.2.0.
What can I use instead of Release Readiness Triage?
Servers from other publishers that do the same job: Suvadu MCP server, GitLab MCP Server and Repowise MCP server.
How does Release Readiness Triage compare with other Developer tools MCP servers?
safety score 82/100 (higher than 60% of 1,119 Developer tools servers); tools 6 (the typical Developer tools server has 7); tools that change things 0% (typical: 5%. Fewer write tools means less an agent can break). Full comparison.

Alternatives to Release Readiness Triage

Same job from other publishers: the closest match first, then the best rated.

  • Suvadu
    Local shell history and AI agent sessions over MCP: search commands, failures, risk and git changes
    A
  • GitLab MCP Server
    GitLab MCP server for projects, merge requests, issues, pipelines, wiki, releases, and more.
    B
  • Repowise
    Codebase intelligence for AI coding agents — graph, git history, docs, decisions, code health.
    B
  • maintenant
    Docker monitoring for AI agents: logs, history, alerts. Can ack alerts; never touches containers.
    C
  • SoloMD
    Read and search a folder of Markdown notes: search, backlinks, tags, tasks, outlines, git history.
    B

More from vola-trebla →