Skip to main content
Glama
srbsa

DiffGate

by srbsa
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

DiffGate

npm version npm downloads VS Code Marketplace Open VSX License GitHub stars

A deterministic guardrail your coding agent runs on itself — before the code reaches your disk.

Every other check fires too late. A review bot needs a PR. A pre-commit hook runs after the agent has finished and moved on. DiffGate is an agent hook: your agent calls it over MCP, gets back structured findings in milliseconds for zero LLM tokens, and fixes the problem while it still has the context — then the same engine, same verdict runs in your editor, your pre-commit hook, and CI. Not a model grading its own homework: the same input always produces the same answer.

It stays quiet by construction. It grades only the lines that changed (🟢 merge · 🟡 glance · 🟠 verify), runs your tests only when a change earns it, and blocks only when it's earned — 0 false blocks on a public, versioned corpus you can rerun yourself with diffgate bench (BENCHMARK.md). Everyone claims low noise; this one ships the corpus.

Across local and frontier models: 0% classic OWASP bugs (SQL injection, XSS, hardcoded secrets) in code written from scratch. But the same frontier model that wrote flawless greenfield code reintroduced security footguns in 13% of edits — an unguarded recursive merge (prototype pollution), a bare cors() (any origin), a path built from request data with no containment check. Editing existing code is most of what an agent does, and the residue lives in the diff, not in the textbook. Rerun it yourself with diffgate marginal. The measurement →

The same shift shows up in third-party maintainability data: GitClear's 2026 analysis finds block duplication up 81% since 2023 (40.3 → 73.0 per million changed lines) and cross-file function connectivity down 35% — agents reinvent code rather than reuse it. That's what the reinvented-helper rule is for (docs/STRUCTURAL-RULES.md).

DiffGate demo: diffgate check on a real repo, mostly green with one orange finding and its reason

Tier

Meaning

What you do

Examples

🟢 Green

Safe / self-contained

merge freely

comments, local logging

🟡 Yellow

Review (soft dependency)

take a look

deprecated APIs, raw SQL, network calls, dependency edits

🟠 Orange

High-impact, gate it

verify before merge

schema/migrations, hardcoded secrets, auth/crypto, public-API changes, injection sinks

Why an agent hook, not another review bot

Every check in the pipeline fires after the code exists, and each one is later than the last:

Fires when

Problem

Review bot (CodeRabbit, Greptile)

a PR exists

the code is finished, defended, and someone is waiting on it

Pre-commit hook

you're done and committing

the agent has moved on; you're re-loading context to fix it

DiffGate over MCP

the agent is still writing

it fixes its own output before the code lands

Being early is not the only thing that matters, though — it has to be quiet, or the agent learns to ignore it. Review bots comment after the PR exists; linters and scanners flag everything they see. Neither guarantees the risky line gets discussed: we scanned 350 merged AI-assisted PRs — of the 109 with flagged AI-attributed changes, only 3 drew public discussion from any human besides the author. DiffGate decides what deserves your attention, your tests, or a block, and stays quiet otherwise. That's the whole product:

  • Diff-scoped. Findings report only on the lines that changed, against the committed baseline — no whole-file noise, no re-litigating code you didn't touch.

  • Tiered triage, not a flat list. Three tiers route attention: green merges, yellow is a glance, orange is gated.

  • The gate runs your tests — selectively. On an orange change, DiffGate runs your testCommand and shows the real exit code and output. Green and yellow pass instantly. The pre-commit hook is fast because tests fire only when a change is genuinely high-impact.

  • Earns the right to block. Broad cross-language injection findings stay advisory on their own; they escalate to a blocking finding only when the optional code graph proves the sink is reachable from an untrusted entry point (an HTTP/event handler). Recall from the rules, the right to block from the graph.

  • Change-impact aware. With an optional code graph, a finding carries its cross-file blast radius — caller counts, suggested reviewers, untested call sites — and an exported symbol nobody calls is de-escalated. Cross-file context makes reviews quieter, not louder.

  • Fast. A review runs in milliseconds on the changed lines — quick enough to sit in the agent and editor inner loop, not only in CI.

  • Provably low-noise. diffgate bench runs a versioned corpus offline: 100% precision / 0 false blocks on clean changes. Reproduce it yourself — that's the point of shipping the corpus. See BENCHMARK.md.

The measurement is reproducible

The 0% / 13% numbers aren't a marketing line — they come from a scripted experiment (four models from local to frontier, greenfield vs. edit mode, Wilson confidence intervals) that you can rerun with diffgate marginal. Methodology, per-model tables, and caveats: docs/MEASUREMENT.md. DiffGate's security rules are tuned to that measured residue, not to maximizing rule count.

Related MCP server: grippy-code-review

Quick start

npm install -g diffgate-review
cd your-repo
diffgate init                    # auto-detects language + test command, writes .diffgate.json
diffgate check --since=HEAD~20   # see what it catches in your own history — no PR required
diffgate check                   # review your pending changes right now

No git history or uncommitted changes yet? See the output on bundled examples first:

diffgate init --demo   # live scan, no config or git changes needed

The surfaces (one shared engine, one verdict)

1. In your coding agent (via MCP)

The highest-leverage spot: the agent self-checks generated code before it's written to disk, gets back structured findings (zero LLM tokens), and surfaces what it corrected (original + fix + why) instead of silently rewriting. A trustworthy, deterministic self-check is what makes it safe to grant the agent more autonomy.

# Claude Code — one command:
claude mcp add diffgate -- diffgate mcp

# One-click via Smithery (zero config):
npx @smithery/cli install diffgate-review --client claude

# Cursor — add to MCP settings:
# { "diffgate": { "command": "diffgate", "args": ["mcp"] } }

Or one-click in Claude Desktop: download diffgate.mcpb and open it. The server also exposes prompts and resources; see MCP.md.

2. In your editor (VS Code / Cursor)

Inline squiggles on changed lines, hover cards (why · who owns it · quick-fix), a Risk Review tree, a status-bar summary, and Deep Review (agentic blast-radius analysis for orange findings). The same verdict you'd get from the CLI, on the diff you're reviewing.

Install from the VS Code Marketplace or Open VSX (Cursor / Windsurf / Gitpod).

3. On the command line — and in CI

diffgate check reviews your diff and exits non-zero on high-impact findings: a pre-commit hook locally, the same gate in your pipeline.

diffgate install-hook  # adds .git/hooks/pre-commit; only runs tests on 🟠 orange changes

The local loop is the wedge — fix while the context is fresh — and the same engine runs as a PR gate so the verdict carries to where it's enforced for the whole team. See docs/TEAM.md for the GitHub Action, shared learnings, and org policy packs. CI runs can optionally layer an external scanner (Semgrep) through the same gate for broader language coverage — advisory-only, off by default (docs/CONFIG.md).

Common commands:

diffgate check                 # review pending changes (the gate)
diffgate check --staged        # staged-only (pre-commit)
diffgate check --since=HEAD~20 # audit recent history, per-commit (see below)
diffgate check --agent         # machine verdict for coding agents
diffgate scan <path>           # analyze files directly (no git needed)
diffgate watch                 # live review as you edit
diffgate guidelines            # review diff against AGENTS.md / CLAUDE.md etc.
diffgate feedback <rule> <f> <l> --dismiss   # suppress a false positive (shared via git)
diffgate mcp                   # start the MCP stdio server

Audit recent AI-authored history. Point check at commits already in your log — each finding is attributed to a specific commit, so you get a story, not a repo-wide report card:

diffgate check --since=HEAD~20        # last 20 commits, one block per commit
diffgate check --since="2 weeks ago"  # by date instead of a rev
diffgate check --ai-authored          # only agent commits (Claude/Copilot/Cursor/… — heuristic)
diffgate check --author="Claude"      # matches author *and* Co-authored-by trailers
diffgate check <sha>                  # a single commit by hash

History mode is report-only (it audits the past — it never runs your test command or blocks a commit) and honors --json and --limit=<n> (default 50). Merge commits are skipped.

Run diffgate --help for the full list (report, bench, stats, graph, marginal, …).

How it works

  • Diff-aware: git diff (CLI) or an in-memory LCS diff (editor, accurate on unsaved buffers) finds changed lines; findings only report on those lines.

  • Real AST where it counts: @babel/parser (JS/TS) and tree-sitter (Python, PHP, Go, Ruby, Java, C#, Kotlin — via WASM, no native build) power precise rules: deprecated calls aren't matched inside comments or strings, exported-signature changes are detected structurally, and SQL injection is sink-targeted, parameter-aware, and sanitizer-aware — cur.execute(f"… {uid}") / $pdo->query("… $id") block, while cur.execute("… %s", (uid,)), $pdo->prepare("… ?"), a single-quoted '… $id', and a SELECT in a log line don't.

  • A deterministic floor everywhere else: comment-aware pattern rules for secrets, destructive/schema changes, auth/crypto, dynamic execution / shell-out, raw queries, and network calls across Go, Java, Ruby, and any text. Commented-out code (# os.system(x)) isn't flagged; a secret committed inside a comment still is. Docs/prose files (.md, .rst, …) are held to the same standard: the word "oauth2-provider" in a changelog isn't auth code, but a key pasted in a README is still a leak.

  • Earned blocking: broad cross-language injection advisories for the non-AST languages (Ruby #{}, Go/Ruby shell-out) escalate to blocking only when the optional code graph proves reachability from an untrusted entry point — community CodeGraph, no Pro taint engine required. (JS/TS, Python, and PHP block on local AST evidence and don't need this.)

  • The gate: on a high-impact change, DiffGate runs your testCommand and shows the actual exit code and output.

  • Learnings: diffgate feedback records dismiss/confirm verdicts; dismissed findings (same rule + same code) are suppressed everywhere. Stored in .diffgate/learnings.json; commit it to share across the team.

  • Optional add-ons: a provider-agnostic AI layer (plain-English explanations + fixes) and a cross-file blast-radius pass via an optional code graph. Both are off by default and degrade gracefully to a no-op.

Engine layout: src/core (shared) · src/cli.ts (CLI) · src/mcp.ts (MCP) · extension/ (VS Code).

Coverage scales with language

How deeply DiffGate analyzes a change depends on the file's language — be explicit about this so you can calibrate how much to trust a clean result.

Tier

Languages

Depth

Deep (AST)

JS / TS (@babel)

All injection classes + public-API & signature changes + deprecated-API quick-fixes. Prototype pollution and NoSQL injection are JS/TS-only; JS/TS findings are also eligible for code-graph taint confirmation.

Deep (AST)

Python, PHP, Go, Ruby, Java, C#, Kotlin (tree-sitter)

Sink-targeted, parameter- and sanitizer-aware injection detection — placeholders, argument-vectors, and escapers are correctly treated as safe. Sink classes per language below.

Sink classes per Deep-AST language (full detail — every sanitizer and safe-form, plus the code-graph boundary — in docs/SCOPE.md):

  • Python (7) — SQL · XSS · path traversal · CORS · command · code · deserialization

  • PHP (8) — SQL · command · code · file inclusion · deserialization · XSS · path traversal · CORS

  • Go (4) — SQL · command · path traversal · CORS

  • Ruby (6) — SQL · command · code · deserialization · XSS · CORS

  • Java (6) — SQL · command · deserialization · path traversal · XXE · CORS

  • C# (7) — SQL · command · deserialization · path traversal · XSS · XXE · CORS

  • Kotlin (6) — SQL · command · deserialization · path traversal · XXE · CORS

SSRF is a cross-language advisory across all eight Deep-AST languages (a request-tainted URL into an outbound-request sink; library-qualified and tainted-only, so static/config URLs aren't flagged). XXE covers the JVM (Java, Kotlin) and .NET (C#), suppressed when the file shows recognized hardening. Permissive CORS now also covers all eight — wildcard Access-Control-Allow-Origin, allow-all framework configs (gin/rs-cors, Spring @CrossOrigin, ASP.NET AllowAnyOrigin(), Ktor anyHost(), rack-cors), and request-reflected origins; explicit allowlists aren't flagged.

Tier

Languages

Depth

Floor (pattern)

C/C++, Rust, Swift, Scala, …

Secrets, destructive/schema changes, auth/crypto, dynamic exec / shell-out, raw queries, network calls, TODO. Cross-language injection advisories that escalate via the code graph.

Text

YAML, Terraform, JSON, any text

Secrets and TODO/FIXME markers.

Fast by design — and scoped to match. A review runs in milliseconds on the changed lines, which is exactly what lets the same check sit in the agent and editor inner loop. That speed is a deliberate trade: DiffGate is the deterministic gate on the diff, not an exhaustive whole-repo taint engine. Coverage is per-language (deep where there's an AST, a pattern floor elsewhere), the security rules are tuned to the residue agents actually ship rather than to maximize raw rule count, and a clean result means "nothing matched at this language's tier," not "proven safe." For deep cross-file taint analysis across many languages, pair it with a dedicated SAST. Full per-language detail and the code-graph boundary: docs/SCOPE.md.

Configuration

diffgate init writes a tailored .diffgate.json at your repo root. Minimal example:

{
  "testCommand": "npm test",          // run for orange changes (the gate)
  "gate": { "mode": "working", "failOn": "orange" },
  "deprecated": [
    { "pattern": "StripeClient.charge", "replacedBy": "StripeClient.createPaymentIntent" }
  ]
}

Any rule — built-in or custom — can be path-scoped with include/exclude globs, the escape hatch for the one file where a forbidden idiom is legitimate (e.g. process.env inside the config loader itself). Full schema, the built-in rule table, LLM providers, and per-rule tuning: docs/CONFIG.md.

More

  • The PR was reviewed. The risky line wasn't. — our PR-trail study: 350 merged AI-assisted PRs, 109 with flagged AI-attributed changes, 3 with public human discussion beyond the author.

  • docs/SCOPE.md: per-language coverage tiers (deep AST vs. pattern vs. text-only) and what the code graph does and doesn't do.

  • docs/CONFIG.md: full .diffgate.json schema, all built-in rules, LLM providers, native precision & test-scope behavior.

  • docs/TEAM.md: rolling DiffGate out to a team (GitHub Action / PR gate, shared learnings, org-wide policy packs, SOC 2 evidence, metrics for leaders).

  • docs/CODE-GRAPH.md: optional cross-file blast radius (caller counts, suggested reviewers, test gaps, reachability, taint analysis).

  • docs/STRUCTURAL-RULES.md: the structural pack — over-engineering rather than vulnerabilities (needless abstractions, pass-through wrappers, complexity spikes), all non-blocking, with per-language thresholds.

  • docs/MEASUREMENT.md: what agents actually ship unprompted and how to reproduce it (diffgate marginal).

  • MCP.md: MCP tools, prompts, resources, and AI configuration.

Try it

diffgate scan mock_project

You'll see green findings (logging), yellow findings (a deprecated call), and orange findings (a DROP COLUMN migration, a public export).

Tests

npm test    # builds the extension, runs the full unit/integration suite + extension smoke test

Support the project

If DiffGate caught something for you — or you just like the idea of a deterministic gate for agent code — star the repo ⭐. It's the signal that tells other people this is worth trying.

  • 🐛 Found a false block, or a sink it missed? Open an issue — a false block is a bug we treat as P0.

  • 💡 Want a language or rule covered? File a feature request with the idiom you'd like caught.

  • 🔒 Security report? Please disclose privately — see SECURITY.md.

Contributing & License

See CONTRIBUTING.md. Apache 2.0; see LICENSE.

Available Tools

7 tools
diffgate_analyzeAnalyze a fileA
Read-onlyIdempotent

Analyze a file for code review findings. Only flags risk on lines changed vs the git baseline (diff-aware). Pass content to analyze unsaved or generated code before it is written to disk. When a code graph is available, public-surface findings carry an impact field (caller count, suggested reviewers, test gaps) and may be tier-adjusted — fix high-blast-radius findings before surfacing the code.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoRepo root directory. Defaults to process.cwd().
contentNoFile content to analyze. Omit to read from disk.
filePathYesAbsolute or repo-relative path to the file.

Output Schema

ParametersJSON Schema
NameRequiredDescription
tierYesOverall risk tier for the file.
findingsYesPer-line findings, each with ruleId, tier, line, and message.
_diffgateNoCapability hint: which layers (core/graph/llm) produced this result.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only and idempotent, so the description adds value by disclosing diff-aware behavior and impact field adjustments. No contradictions; it contributes context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences with no fluff; the purpose is front-loaded in the first sentence. Every sentence adds distinct information, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description adequately covers diff-aware analysis, content parameter usage, and code graph impact. It lacks details on error handling or rate limits, but for a non-destructive, idempotent tool, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all three parameters fully (100%), but the description adds specific use-case guidance for the `content` parameter (unsaved code), enhancing understanding. No additional detail for `filePath` or `cwd`, so it's above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes a file for code review findings and is diff-aware, which distinguishes it from siblings like diffgate_check_staged and diffgate_deep_review by highlighting its focus on changes from git baseline.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While it explains when to use the `content` parameter (unsaved/generated code) and mentions code graph availability, it does not explicitly guide when to use this tool over its siblings or when not to use it, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diffgate_capabilitiesReport active capabilitiesA
Read-onlyIdempotent

Report which DiffGate layers are active (core / code graph / LLM), which tools you can call right now without an error, and the agent autonomy budget (fix limit, escalation, trust source). Call this once up front so you know what's available instead of discovering it via thrown errors.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoRepo root. Defaults to process.cwd().

Output Schema

ParametersJSON Schema
NameRequiredDescription
agentNoAutonomy budget: fix limit, escalation, trust source.
toolsNoTool names callable without error right now.
layersNoWhich of core/graph/llm are active.

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds value by detailing the specific information reported (active layers, callable tools, autonomy budget) and reinforces that it is safe to call upfront.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence defines the outputs, the second gives usage guidance. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a simple purpose, full schema coverage, informative annotations, and an output schema, the description covers all essential aspects: what it does, when to use it, and what it reports. It is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the 'cwd' parameter. The description does not add any additional meaning about the parameter, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reports which DiffGate layers are active, which tools are callable, and the agent autonomy budget. It uses specific verbs ('Report') and resources ('active capabilities'), distinguishing it from sibling tools that analyze, check, review, explain, or provide feedback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises calling the tool upfront to discover available capabilities instead of discovering them via thrown errors. This provides a clear usage directive and implies an alternative (error-driven discovery), which is effective guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diffgate_check_stagedCheck staged or working diffA
Read-onlyIdempotent

Check all staged (or working-tree) changes in a git repo for DiffGate findings. Returns overall tier, counts, and per-file findings across the whole diff, plus a verdict block (the agent autonomy ladder: pass/review/blocked overall, with a rung — block/escalate/autofix/advisory — per finding) so you can decide whether to surface the diff without reimplementing the rules.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoRepo root. Defaults to process.cwd().
modeNoCheck staged-only or all working-tree changes. Default: working.

Output Schema

ParametersJSON Schema
NameRequiredDescription
tierYesOverall risk tier across the diff.
filesYesPer-file review results with findings.
verdictNoAgent autonomy ladder: pass/review/blocked, with a rung per finding.
_diffgateNoCapability hint: which layers (core/graph/llm) produced this result.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds behavioral context by detailing the return values (tier, counts, verdict block) and the autonomy ladder concept, which helps the agent understand the output without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the main action and supplements with essential details about the return value, with no extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description sufficiently covers the tool's behavior and return values (verdict block, tiers). It lacks mention of prerequisites or error handling, but for a simple check tool, this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both parameters. The tool description does not add new semantics beyond what the schema provides, maintaining baseline adequacy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks staged or working-tree changes for DiffGate findings, using specific verbs and resource. It distinguishes from siblings like diffgate_analyze and diffgate_capabilities by focusing on the diff check purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by stating the return of a verdict block to decide whether to surface the diff without reimplementing rules. However, it does not explicitly mention when not to use or compare with alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diffgate_deep_reviewDeep-review a findingA
Read-only

Run an agentic deep review on a single high-impact (orange) finding. The model uses real repo tools (grep, read_file, find_references, git_blame) to investigate blast radius before rendering a verdict.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdYesRepo root. Defaults to process.cwd().
findingYesA finding object from diffgate_analyze.
snippetNoCode snippet around the finding.
filePathYesRepo-relative path of the file containing the finding.
languageNoLanguage id (javascript, python, go, etc.).

Output Schema

ParametersJSON Schema
NameRequiredDescription
verdictYesThe model's final verdict on the finding.
rationaleNoWhy the model reached that verdict.
toolStepsNoThe investigation trace (tool calls the model made).

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds valuable behavioral context: it uses real repo tools, investigates blast radius, and renders a verdict. This goes beyond the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and contains no extraneous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and annotations, the description provides sufficient completeness. It explains the tool's behavior and inputs, making it adequate for a complex tool with nested parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description does not need to add parameter-level details. The description does not provide extra semantic information beyond what is already in the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('deep-review') and resource ('a single high-impact (orange) finding'). It distinguishes from sibling tools by mentioning the use of real repo tools like grep and git_blame.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies the context (single high-impact finding) and outlines the tool's actions, but it does not explicitly state when not to use it or provide alternatives. Implicit differentiation from siblings is present but lacks direct exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diffgate_explainExplain a findingA
Read-only

Get a concise AI explanation for a DiffGate finding. Faster than diffgate_deep_review — a single LLM call with no tool loops.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdYesRepo root. Defaults to process.cwd().
findingYesA finding object from diffgate_analyze.
snippetNoCode snippet around the finding.
languageNoLanguage id.

Output Schema

ParametersJSON Schema
NameRequiredDescription
explanationYesA concise plain-language explanation of the finding.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint. The description adds that the tool is 'concise', 'single LLM call', and 'no tool loops', which clarifies performance and simplicity beyond annotations. However, it does not explicitly mention non-determinism or open-world behavior, though implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The purpose is front-loaded and the comparison to a sibling is immediate. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description does not need to explain return values. It covers the core behavior and differentiation. However, it could mention prerequisites (e.g., prior use of diffgate_analyze) but that is implied by the parameter description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. The tool description does not add additional meaning beyond what the schema already provides; it merely restates the purpose. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('explanation for a DiffGate finding'). It explicitly distinguishes from a sibling tool (diffgate_deep_review) by contrasting speed and single LLM call, making purpose and differentiation clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool ('Faster than diffgate_deep_review') and contrasts the approach ('single LLM call with no tool loops'), providing clear guidance on choosing between siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diffgate_feedbackRecord a reviewer verdictA
Idempotent

Record a reviewer's verdict on a finding so DiffGate learns. verdict 'dismiss' suppresses that same flagged code (ruleId + code) in future reviews (noise reduction); 'confirm' marks it as a real, valued catch. Stored in .diffgate/learnings.json at the repo root.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoRepo root. Defaults to process.cwd().
codeYesThe flagged code (finding.code).
fileNoOptional repo-relative file path for context.
noteNoOptional reviewer note (why).
ruleIdYesThe finding's ruleId.
verdictYesdismiss = noise/false-positive; confirm = real issue.

Output Schema

ParametersJSON Schema
NameRequiredDescription
recordedYesThe stored learnings entry (ruleId, code, verdict, note, timestamp).

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide idempotentHint and readOnlyHint, but the description adds critical behavioral details: writes to .diffgate/learnings.json, the specific effects of 'dismiss' (suppressing future flags) and 'confirm' (marking as real). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff. The first sentence states the purpose, the second clarifies verdicts and storage location. Ideal length and structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 params, 3 required) and the existence of an output schema, the description covers the core behavior (learning, storage, verdict effects). No missing context needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description does not add per-parameter details but provides context about verdict's role. It does not significantly enhance understanding of parameters beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('Record', 'suppresses', 'marks') and specifies the resource (reviewer's verdict on a finding). It clearly distinguishes from sibling tools by focusing on feedback/learning rather than analysis, capabilities, or checking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the context (after a review, to suppress noise or confirm findings) but does not explicitly state when not to use this tool or contrast with siblings like diffgate_analyze or diffgate_explain.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diffgate_guidelinesReview against repo guidelinesA
Read-onlyIdempotent

Review the diff against the repo's own coding guideline files (AGENTS.md, CLAUDE.md, .cursorrules, etc.), scoped per directory (nearest file wins). IMPORTANT: if the result has mode='host', NO external model was used — this is a SELF-REVIEW, not an independent gate: YOU (the calling agent) evaluate each group's hunks against its guidelines text using your own model. Treat host-mode results as ADVISORY only — never block the change on them. If mode='model', findings were produced by the configured provider and are returned directly.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoRepo root. Defaults to process.cwd().
modeNoDiff scope. Default: working.

Output Schema

ParametersJSON Schema
NameRequiredDescription
modeYes'host' = self-review (advisory only); 'model' = an external provider produced findings.
groupsNoPer-guideline-file groups of hunks (host mode) or findings (model mode).

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds context beyond annotations: explains that host mode is a self-review, provides mode interpretation, and notes scoping behavior. Annotations already declare readOnlyHint, openWorldHint, etc., and description does not contradict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is informative but slightly lengthy. It front-loads key distinctions (mode='host' behavior) and avoids unnecessary repetition. Could be trimmed, but it's efficient given the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (two modes, scoping, advisory behavior), the description fully covers usage, result interpretation, and edge cases. Output schema exists and annotations support it, so no gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and parameters are well-documented in the schema. Description adds minimal extra detail (e.g., scoping per directory relates to cwd), but overall the schema carries the burden. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description clearly state the tool reviews the diff against repo-specific guideline files. It distinguishes from sibling tools like 'diffgate_analyze' or 'diffgate_deep_review' by specifying the exact resource (guideline files).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use the tool, how to interpret results based on mode ('host' vs 'model'), and gives crucial guidance: 'Treat host-mode results as ADVISORY only — never block the change on them.' It also notes scoping per directory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: capabilities introspection, single-file analysis, staged changes check, deep review, explanation, feedback, and guideline review. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow a consistent 'diffgate_<verb>' pattern (e.g., diffgate_analyze, diffgate_check_staged, diffgate_explain). The naming is uniform and predictable.

Tool Count5/5

With 7 tools, the surface is well-scoped for a code review assistant. Each tool serves a specific need without being excessive or sparse.

Completeness4/5

The tool set covers analysis, staged checks, deep reviews, explanations, feedback, and guidelines. Missing a tool for listing all findings from a review session, but core workflows are well-represented.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • Deslopify

    veroxsity
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    A universal MCP server that acts as a code quality gate for AI assistants, providing pre-generation guidance, post-generation review, and root cause analysis to improve code quality.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/srbsa/diffgate'

If you have feedback or need assistance with the MCP directory API, please join our Discord server