Release Readiness Triage MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| aggregate_suite_failuresA | 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. |
| cross_reference_flakinessA | 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. |
| correlate_code_changesA | 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. |
| generate_release_recommendationA | 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. |
| detect_temporal_failure_patternsA | 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. |
| analyze_rollback_readinessA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct analysis step: grouping failures, scoring flakiness, correlating code changes, detecting temporal patterns, assessing rollback readiness, and final recommendation. Some overlap exists between cross_reference_flakiness and detect_temporal_failure_patterns (both identify non-regression failures), but descriptions clearly distinguish their inputs and purpose.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., aggregate_suite_failures, correlate_code_changes). The verbs are varied and descriptive, and the naming scheme is uniform throughout the set.
Six tools is well-scoped for a release readiness triage server. Each tool represents a necessary step in the triage workflow, with no redundant or trivial additions.
The tool set covers the full triage pipeline from raw failure aggregation through final recommendation, plus rollback readiness. Minor gaps exist: the agent must supply flakiness history and changed files externally, and there is no direct tool to retrieve raw CI output, but these are acceptable workarounds.