k11 Release Gate
OfficialRuns the release gate as a CI step: evaluates the collected QA evidence against the release policy, writes release-decision.md (suitable as a PR comment) and release-decision.json (the audit record), sets GitHub Actions outputs (verdict, blockers, needs_human, conditions, report) and exits non-zero according to --fail-on block | needs-human | conditions | never.
Ingests JUnit XML produced by Gradle test runs as release evidence, turning test failures and errors into blockers and skipped tests into notes according to the release policy.
Ingests JUnit XML output from Jest test runs as release evidence, so failing or erroring JavaScript tests block the release while skipped tests are recorded as notes.
Ingests JUnit XML output from pytest runs as release evidence; failures or errors in the results trigger the junit.failures block rule (or a policy override), while skipped tests are reported as notes.
Consumes the self-healing UI evidence (heal-report.json) produced by the k11 Selenium QA heal-ci pipeline, reporting healed-and-verified locators as conditions to approve, and unresolved or reverted locators as blockers.
This server does not currently have a deployable release on Glama. Follow the repository's setup instructions to install and configure it for your MCP client, including any required credentials and local dependencies.
k11 Release Gate — MCP server & CI gate
One release decision from all your QA evidence, under a policy you can read, with an audit trail.
Teams already have the evidence: UI test runs, API checks, security scans, JUnit files. What they lack is a consistent answer to "can we ship?". Today that answer is a person reading five dashboards under deadline pressure. k11 Release Gate reads the evidence, applies a written policy and returns one verdict, with every reason and the file it came from:
Verdict | Meaning |
🟢 ship | nothing in the policy objects |
🟡 ship with conditions | ship, but someone must do something (e.g. approve the locator-heal PR) |
🟠 needs a person | ship only with sign-off from a named approver: risk-proportionate human-in-the-loop |
🔴 block | don't ship; here is each blocker and its evidence |
Deterministic. The same evidence and the same policy always give the same verdict. There's no LLM in the decision, so it holds up in an audit. Every evidence file is recorded with its SHA-256, timestamp and age, alongside the policy's own hash and the git commit.
What it reads
The kind of evidence is recognised from the file's content:
Evidence | Produced by |
UI tests with self-healing ( | k11 Playwright QA or k11 Selenium QA |
API contract ( | k11 API Contract QA |
API functional tests ( | |
LLM red-team ( | |
Any JUnit XML | pytest, Maven Surefire, Gradle, Jest, Playwright, … |
Missing evidence is never treated as a pass. Required kinds that are missing block by default, and optional kinds without evidence are listed as not tested.
Related MCP server: blop
See it decide
demo/ contains two release candidates whose evidence comes from real runs of the five K11 tools against their own demos.
rc1 → 🔴 Block, with 7 blockers, each traced to its source:
1 UI test failed for reasons other than locators (
ui.real_failures): page title changed2 broken locators still unresolved (
ui.unresolved_locators): "Edit profile" needs review;cart-btnheal revertedAPI change breaks billing-svc, checkout-web, notification-svc (
contract.breaks_critical_consumer): billing-svc is critical, owner @team-billing2 API flows failed (
api.flow_failed): "Order total is quantity times price", negative tests forPOST /orders2 server errors (5xx) in API tests (
api.server_error): wrong type / missingitems[0].qty6 critical and 13 high-severity LLM findings (
llm.critical,llm.high): unverified refund, other customers' records, indirect prompt injection, …Needs a person: the contract check escalated (3 consumers break). Conditions: approve the healed
view-orderslocator; confirm the consumer list for 3 unused breaking changes.
rc2 (after the fixes) → 🟠 Needs a person's sign-off:
Sign-off needed from @qa-lead, @ai-safety-lead before release.
Needs a person: 1 LLM probe inconclusive (
llm.inconclusive)Condition: 1 locator healed and verified: approve the heal pull request
Everything passes, but one security probe couldn't be decided automatically, so the policy asks a named person to look. It doesn't let it through silently and doesn't block the release outright.
QA_MCP_ROOT=demo/rc1 k11-release-gate-mcp evaluate --label rc1
QA_MCP_ROOT=demo/rc2 k11-release-gate-mcp evaluate --label rc2The policy: .qa-mcp/release-policy.yaml
name: Order platform release policy
evidence: # where each tool writes its report (globs inside the project)
api_tests: [".qa-mcp/api-test-report/api-test-report.json"]
junit: ["test-results/**/*.xml"]
required: [api_tests, contract, ui_heal, llm]
max_age_hours: 24 # older evidence → evidence.stale
critical_consumers: [critical, high] # their breakage blocks
approvers: ["@qa-lead", "@ai-safety-lead"] # named on a needs_human verdict
rules: # override any rule: block | needs_human | conditional | info | off
llm.medium: needs_human
ui.healed: infok11-release-gate-mcp init writes a commented starter policy; k11-release-gate-mcp rules lists every rule.
Rules
Rule | Default | Fires when |
| block | a required kind has no evidence |
| needs a person | an evidence file can't be parsed |
| condition | evidence is older than |
| block | an API returned a 5xx during functional tests |
| block | an API flow failed |
| needs a person | a flow was blocked by guardrails or errored, so it proved nothing |
| block | an API change breaks a consumer in |
| needs a person | it breaks another consumer |
| needs a person | the contract check asked for a person |
| condition | breaking changes with no known consumer |
| block | UI tests failed for reasons other than locators |
| block | broken locators were reverted, need review or weren't found |
| condition | locators were healed and verified; approve the heal PR |
| condition | heals were suggested in a dry run |
| block | LLM security findings at that severity |
| condition | medium findings |
| needs a person | probes that need review or errored |
| note | low findings |
| block | failures or errors in any JUnit file |
| note | skipped tests |
Tools
Tool | What it does |
| The verdict, every finding with its evidence, what wasn't tested; writes |
| What evidence exists: kind, file, age, SHA-256, key numbers, missing required kinds. |
| Every rule with its default and its outcome under your policy. |
| Writes a commented starter policy (never overwrites without asking). |
The Claude Code plugin adds /release-check, which collects the evidence, tells you which tool produces anything missing, evaluates and explains, without ever softening the verdict.
In CI
k11-release-gate-mcp evaluate --label v2.4.0It writes release-decision.md (the PR comment) and release-decision.json (the audit record), sets GitHub Actions outputs (verdict, blockers, needs_human, conditions, report) and exits non-zero according to --fail-on block | needs-human | conditions | never. See docs/release-gate.yml.
Install
/plugin marketplace add K11-Software-Solutions/k11techlab-release-gate-mcp
/plugin install release-gate@k11-release-gateOr the MCP server only: claude mcp add release-gate -- uvx k11-release-gate-mcp, or pip install k11-release-gate-mcp for CI.
Background
This puts into practice the risk-proportionate human-in-the-loop idea from the K11 research on autonomous CI/CD quality assurance (IJECS, 2026): automate the clear cases and send the uncertain ones to a named person, with the evidence attached. It's an independent implementation and doesn't depend on the research code.
Development
python -m venv .venv && .venv/Scripts/pip install -e ".[dev]" # bin/pip on macOS/Linux
pytest # real evidence from all five tools, policy, determinism, CLI, MCP (10)Roadmap
A GitHub Check with per-rule annotations
Signed decision records (Sigstore) for regulated releases
Approvals recorded against the decision (who signed off a
needs_humanverdict, and when)The Release Readiness Agent: a Claude Code plugin that decides which checks a change needs, runs them through the K11 servers, and asks this gate for the verdict
Built by K11 Software Solutions. Part of the K11 Tech Lab agentic QA series. MIT licensed.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
This server cannot be deployed
Maintenance
Related MCP Connectors
Pre-launch website QA: deterministic rule-based scans, readiness score, and blockers for agents.
Deterministic decision layer for autonomous agents: reproducible PROCEED/REVIEW/SKIP verdicts.
Typed AI decisions for agents: classify, route, screen evidence, score and batch-label text.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Related MCP Servers
- AlicenseAqualityCmaintenanceRelease gate agents call before they tell users a public website is ready to ship. Scans public websites across security, SEO, accessibility, legal compliance, and sustainability.9MIT
- AlicenseBqualityCmaintenanceMCP-native release confidence control plane that turns browser execution into auditable go/no-go decisions by combining business-critical journey context, evidence-heavy QA runs, and risk governance.281MIT

EVIDIQ Rubric MCPofficial
AlicenseNot gradedqualityBmaintenanceDetermines whether a deliverable meets its contract using deterministic rules, criteria, and signed attestations.1MIT- AlicenseNot gradedqualityAmaintenanceProvides autonomous QA and a deterministic ship/no-ship verdict for iOS and web apps, enabling coding agents to explore, screenshot, and test apps via MCP tools.1,499 npm3MIT