Ai Quality Gate

AI Quality Gate

MCP Server for AI code quality automation.

[npm version] [License: MIT]

What It Does

AI writes code → calls quality_fix → Server fixes what it can → Reports remaining issues to AI.

Hybrid Approach:

• Phase 1: ESLint + 627 rules + Prettier (~2-8s, always runs)
• Phase 2: SonarQube Server (~30-60s, optional)

Important: ESLint vs Prettier

ESLint rules are controlled by MCP for consistent quality gates. Prettier uses project's config so formatting matches project preferences.

Phase 1 Rule Coverage:

Installation

Prerequisites

• Node.js 20.10+ or 21.1+ on your PATH (node -v).
• Cursor, Antigravity, OpenCode (or another MCP-capable editor) with MCP enabled.

Project root is auto-detected when PROJECT_ROOT is omitted: the server walks up from the MCP process working directory until it finds package.json or tsconfig.json. Set PROJECT_ROOT in env only to analyze a different tree than the inferred root.

MCP configuration (Cursor)

Open Settings → Tools & MCP → Edit (user mcp.json). Add one server block; the examples below match .cursor/mcp.json.example (JSONC with comments — if your editor rejects comments, copy the JSON blocks below only).

Server name vs tool name: The key under mcpServers (e.g. "ai-quality-gate") is only the label for that connection in Cursor. The MCP tool your agent calls is always quality_fix — that name is fixed by this package and is separate from the server key and from ai-quality-gate.

A) Recommended: npx (no global install)

Always runs the published package; good for teams and CI-like setups.

{  "mcpServers": {    "ai-quality-gate": {      "command": "npx",      "args": ["-y", "ai-quality-gate"]    }  }}

B) Optional: global npm install

After npm i -g ai-quality-gate, the ai-quality-gate binary is on your PATH:

{  "mcpServers": {    "ai-quality-gate": {      "command": "ai-quality-gate",      "args": []    }  }}

C) SonarQube (Phase 2)

Requires a running SonarQube instance, sonar-scanner available (see SonarQube Setup), and all three variables below. Phase 1 still runs first.

{  "mcpServers": {    "ai-quality-gate": {      "command": "npx",      "args": ["-y", "ai-quality-gate"],      "env": {        "SONAR_HOST_URL": "http://localhost:9000",        "SONAR_TOKEN": "your_sonar_token",        "SONAR_PROJECT_KEY": "your_project_key"      }    }  }}

D) Optional environment variables (any server)

Add an "env" object when you need overrides. Merge order for config is defaults → .quality-gate.yaml / .quality-gate.json → environment variables.

MCP configuration

Cursor, Antigravity, etc..

{  "mcpServers": {    "ai-quality-gate": {      "command": "npx",      "args": ["-y", "ai-quality-gate"]    }  }}

(OpenCode)

Create or edit OpenCode config (typically ~/.config/opencode/opencode.json or project-level config):

{  "$schema": "https://opencode.ai/config.json",  "mcp": {    "ai-quality-gate": {      "type": "local",      "enabled": true,      "command": ["npx", "-y", "ai-quality-gate"]    }  }}

Environment variables can be added under the server config if needed (see C) SonarQube (Phase 2) above).

Local development (this repository)

To dogfood or contribute:

1. yarn build — generates dist/server.js.
2. Point MCP at the built file (absolute paths):

{  "mcpServers": {    "ai-quality-gate-dev": {      "command": "node",      "args": ["/ABSOLUTE/PATH/TO/ai-quality-gate/dist/server.js"]    }  }}

3. Reload MCP. Use env.PROJECT_ROOT only if the repo you analyze differs from the inferred root.

2. Add AI Rule

Settings → Rules and Commands → Add Rule:

After every code change, before telling the user "done",AI must call the quality_fix MCP tool. This is mandatory.

3. Use It

AI writes code → calls quality_fix → Fixes errors → "Done ✅"

CLI: interactive config (--setup)

The interactive wizard creates or updates .quality-gate.yaml without hand-editing: it walks you through project root, optional SonarQube (host URL + project key; token is not saved to disk — use SONAR_TOKEN in your environment), which Phase 1 tools to enable (ESLint, curly-brace / arrow AST fixers, Prettier, JSON validator), timeouts, and i18n rules. The generated file includes a fixers: block you can adjust later.

After yarn build (or install from npm), run from the target project (or any path under it):

node dist/server.js --setup

PROJECT_ROOT is inferred when unset (see MCP configuration). Use the same entrypoint as the MCP server (node dist/server.js or npx ai-quality-gate); only the --setup flag switches to wizard mode. Answer prompts in the terminal; on success you get a ready-to-use config next to your project root.

Other CLI modes: --check (read-only Phase 1), --fix (default behavior when using CLI quality run), --phase1-only, --phase2-only — see docs/DEVELOPMENT.md.

Optional: SonarQube Server (Phase 2)

Configure Sonar env in MCP as in C) SonarQube (Phase 2) above, or copy from .cursor/mcp.json.example. You need sonar-scanner on your machine for analysis (see below).

SonarQube Setup

Docker (Recommended)

# Start SonarQubedocker run -d --name sonarqube -p 9000:9000 sonarqube:community
# First login: admin/admin → change password# http://localhost:9000

Docker Compose

# docker-compose.ymlversion: '3'services:  sonarqube:    image: sonarqube:community    ports:      - '9000:9000'    volumes:      - sonarqube_data:/opt/sonarqube/data      - sonarqube_logs:/opt/sonarqube/logs      - sonarqube_extensions:/opt/sonarqube/extensions
volumes:  sonarqube_data:  sonarqube_logs:  sonarqube_extensions:

docker-compose up -d

Creating SonarQube Token

1. http://localhost:9000 → Login (admin)
2. My Account → Security → Generate Tokens
3. Select token type: Global Analysis Token
4. Copy token → use as SONAR_TOKEN

Installing sonar-scanner

For custom path: SONAR_SCANNER_PATH env var

Configuration

Optional files (discovered by walking up from the inferred project root — same algorithm as package.json / tsconfig.json — or from PROJECT_ROOT when set): .quality-gate.yaml (preferred) or .quality-gate.json. Same fields as environment variables (camelCase); you may nest Sonar settings under sonar: { hostUrl, token, projectKey, scannerPath }.

Merge order: defaults → config file → environment variables (ENV wins on conflicts).

Set QUALITY_GATE_CONFIG to an explicit path to skip discovery.

Custom rules (customRules)

Optional line-based regex checks on lintable files (Phase 1). Each match is reported as an issue with rule set to custom:<id> (and included in quality_fix remaining). Example:

customRules:  - id: no-console    message: 'Console.log is not allowed'    pattern: 'console\\.log\\('    severity: error  - id: no-debugger    message: 'Debugger statement found'    pattern: 'debugger'    severity: warning

Patterns use JavaScript RegExp source (escape backslashes as in YAML strings). An invalid pattern is skipped, and says so in warnings.

JSON validator & i18n locale files

When fixers.jsonValidator is enabled and you pass JSON paths that match locale patterns (for example locales/en.json / locales/tr.json), the tool compares keys across those files.

• Syntax errors, invalid UTF-8 BOM, etc. → reported as issues and fail Phase 1 / quality_fix until fixed.
• Missing or extra keys between locale files → collected as i18nIssues in the validator result and printed as warnings on stderr during Phase 1. They do not set passed: false and do not block the gate.

Treat i18nIssues as advisory unless you add your own CI check on top.

Environment Variables

All variables are optional unless you use Phase 2, which requires SONAR_HOST_URL, SONAR_TOKEN, and SONAR_PROJECT_KEY together.

Auto-Fix

Phase 1 automatically fixes these issues:

ESLint Auto-Fix (~100+ rules)

// var → const/letvar x = 1        →  const x = 1
// forEach → for...of (unicorn/no-array-for-each)arr.forEach(x => f(x))  →  for (const x of arr) f(x)
// Nested ternary → extracted (unicorn/no-nested-ternary)a ? b : c ? d : e  →  const temp = c ? d : e; a ? b : temp
// Unused imports removedimport { unused } from 'x'  →  (removed)
// Type imports (consistent-type-imports)import { Type } from 'x'  →  import type { Type } from 'x'
// Optional chain (prefer-optional-chain)a && a.b && a.b.c  →  a?.b?.c
// Regex optimization (regexp/*)/[0-9]/  →  /\d/

AST Auto-Fix

// Remove unnecessary curly braces (single-line if)if (x) { return true }  →  if (x) return true

Prettier Formatting

After ESLint fixes, Prettier runs to ensure consistent formatting:

// ESLint removes braces but leaves awkward format:if (x) return true
// Prettier fixes to single line:if (x) return true

Note: Prettier uses project's config, not MCP's.

Everything else: Reported to AI, AI fixes it.

API

Tool: quality_fix

// Input{  files: string[] // File paths to check}
// Output{  phase: "local" | "server" | "complete",  success: boolean,  message: string,  fixed: {                 // a FixSummary: edits on disk, kept even when findings remain    eslint: number,          // ESLint auto-fixes    curlyBraces: number,   // AST: single-statement if braces    singleLineArrow: number, // AST: arrow body style    prettier: number,      // Prettier formatting    json: number           // JSON files validated (not an edit, so not part of fixedCount)  },  fixedCount: number,      // Edits on disk: the sum of `fixed`, without `json`  attempted?: FixSummary,  // same fields as `fixed`: edits tried before a rollback, not on disk after a successful one  attemptedCount?: number, // The sum of `attempted`  warnings?: string[],     // Things the gate could not do that do not fail the run (a file a fixer skipped, a custom rule it could not apply)  remaining: Issue[],      // Findings left to fix by hand. Line numbers refer to the files as they are now (line 0 = location unknown)  remainingCount: number,  // remaining.length  totalIssues: number,     // fixedCount + remainingCount  error?: {                // Set when the run could not finish: e.g. ROLLBACK_FAILED, SONAR_API_ERROR, PERSISTENT_FAILURE    code: string,    message: string,    details?: object       // ROLLBACK_FAILED: { unrestoredFiles, restoredFiles }  },  checks?: object,         // Raw typecheck and lint results, in read-only check mode  timing: {    phase1: string,    phase2?: string,    total: string  }}

What a failed run leaves on disk. The gate applies every fix it can and keeps them. Findings it cannot fix (a lint rule, a custom rule, a == that is not provably safe to change) come back in remaining with success: false; the kept fixes are counted in fixed. The run is rolled back only when the fixers themselves broke something: a type error after the fix, a Vue file the compiler rejects, ESLint or Prettier failing to run. Then fixed is zero and the edits that were tried are listed in attempted. If that rollback itself fails, the response is ROLLBACK_FAILED: error.details.unrestoredFiles lists the files that may still hold the edits, phase is the phase that failed, and remaining is what failed, without locations. SonarQube (Phase 2) findings, or an unreachable server, do not undo the verified Phase 1 edits either: they stay and the findings come back in remaining.

Retrying. If the same failure comes back unchanged three times in a row (same files with the same content, same findings), the MCP server answers with error.code: "PERSISTENT_FAILURE" and tells the caller to stop retrying and ask the human. Changing a file, or the findings changing, starts the count over. fixedCount counts edits only; JSON validation passes are in fixed.json and are not fixes.

Overlapping calls. The MCP server runs quality_fix calls whose file sets overlap one after the other, in the order they arrived, so one call's rollback can never restore an older copy over another call's kept edits. Calls on different files still run side by side.

Feature Flags

ENABLE_I18N_RULES

For projects with internationalization (i18n), enable literal string detection:

{  "env": {    "ENABLE_I18N_RULES": "true"  }}

When enabled:

// ⚠️ Warning<h1>Hello World</h1>
// ✅ OK<h1>{t('hello')}</h1>

Troubleshooting

MCP: quality_fix does not appear

1. Node.js 20.10+ or 21.1+ — run node -v and npx --version.
2. Reload Cursor after editing mcp.json (or use the MCP refresh control).
3. JSON — the file must be valid JSON (no trailing commas). Copy from the MCP configuration section if unsure.
4. Global install — if you use "command": "ai-quality-gate", run npm i -g ai-quality-gate once so the binary exists.

Windows

"npx not found" error:

# Node.js must be in PATH# Check in PowerShell:where.exe npx

Permission denied:

# Run PowerShell as Administrator

macOS / Linux

"Permission denied" error:

# Fix npm global directorymkdir ~/.npm-globalnpm config set prefix '~/.npm-global'echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.zshrcsource ~/.zshrc

"sonar-scanner not found" error:

# Install via Homebrewbrew install sonar-scanner
# Or via npmnpm install -g sonarqube-scanner

SonarQube

"Insufficient privileges" error:

• SonarQube → Administration → Security → Global Permissions
• Give Anyone group Browse and Execute Analysis permissions

"Project not found" error:

• Create project manually for first analysis: Projects → Create Project → Manually

Clone & build (contributors)

git clone https://github.com/mustafacagri/ai-quality-gate.gitcd ai-quality-gateyarn installyarn build

Use Local development (this repository) for MCP pointing at dist/server.js.

Docs

• SETUP.md — Local setup (if included in your tree)
• AGREEMENTS.md, docs/ARCHITECTURE.md, etc. — optional; some files may be omitted in minimal clones. README + .cursor/mcp.json.example are enough to run the published package.

Principles

• ✅ 627 ESLint rules (SonarJS, Unicorn, TypeScript-ESLint, etc.)
• ✅ Prettier integration (uses project's config)
• ✅ AST-based transforms (no regex)
• ✅ Verify after each fix
• ✅ Rollback on error
• ✅ ESLint config discovery (uses project config if available, otherwise embedded)
• ✅ Zero workaround
• ✅ Principal level

License

MIT © Mustafa Çağrı Güven

v0.0.1 — Initial release! MCP quality_fix, Phase 1/2 pipeline, CLI, config files, custom rules (see CHANGELOG)

Readonly local verification

Run ai-quality-gate --check --phase1-only <selected-file ...> for readonly local verification. ESLint checks only the explicitly selected real .js, .jsx, .mjs, .cjs, .ts, .tsx, .mts, .cts, and .vue paths, including executable JS configuration and TS declarations. It never expands lint scope through imports. A .vue file is linted in place: vue-eslint-parser applies script rules to <script> and <script setup> only. Template and style are not JavaScript, and no extracted script file is written. @vue/compiler-sfc parse() and compileScript() failures are diagnostics. A structurally invalid SFC fails before ESLint, so a missing end tag is not reported as an unused binding. AST edits keep arrow signatures and terminate a brace-less if with a semicolon. Prettier, when enabled, formats the whole SFC. Deleted and old rename endpoints must first be materialized as real files in an isolated snapshot by the caller, with their base content and endpoint identity retained.

TypeScript checks the full nearest tsconfig.json project context with --noEmit; this can include imports and other project files and does not expand ESLint's selected scope. A .vue file with a TypeScript script (lang="ts" or tsx) is checked with vue-tsc, which also checks its template expressions. A project that compiles .vue files uses vue-tsc for its .ts files too, so they can import .vue modules; a project counts as one that compiles .vue files when its include matches any, or when the nearest package.json depends on vue. The project is the tsconfig that includes the file: for a create-vue style root config that only lists references, that is the referenced project, and a file such as a shared helper that no project lists but a referenced project imports is checked in that project. A .vue file that no tsconfig includes fails instead of passing unchecked. A plain-JavaScript .vue file is not type checked, as a .js file is not. This holds for .ts files too: a file that no tsconfig includes, directly or through imports, fails with "Not included by " instead of passing unchecked. Type errors anywhere in the program fail the check and are all reported (those in the selected files first, at most 50). A plain-JavaScript <script> is linted with the rules a .js file gets, and a lang="ts" one with the TypeScript rules. Type-aware ESLint rules (such as no-floating-promises) are not applied to .vue files: that is a deliberate choice, not a limit of the parser. TypeScript incremental metadata is redirected to a temporary folder outside the project and removed after the check. No source, configuration, lockfile, or control file is rewritten by check mode. The MCP quality_fix tool continues to be a mutating operation; use the CLI check interface for readonly work.

The embedded config uses typescript-eslint's recommendedTypeChecked and projectService for TS sources. TS files must belong to a real tsconfig project. JavaScript files use the non-typed lint profile. Named import aliases, including type aliases, are checked by an AST rule; unchanged named imports are allowed. Warnings fail strict verification (--max-warnings 0). Local check JSON includes checks.typecheck and, when reached, checks.lint, with PASS/FAIL/ERROR status, checked projects, and actual lint result paths. The existing fail-fast pipeline can stop before lint after a failed typecheck or custom rule.

Exit 0 means all reached checks succeeded; exit 1 reports real code findings; exit 2 reports configuration, process, parser, or coverage errors. Empty/malformed lint output, missing selected files, unexpected/duplicate result paths, fatal parser failures, and failed subprocesses cannot become a successful check. The installed package carries its embedded parser, lint plugins/resolver, and TypeScript runtime dependencies. Supported Node versions are ^20.10.0 || >=21.1.0, the intersection required by the retained lint dependency baseline.