crapkit

Overview Schema Source Related Servers Discussions Admin

Commit gate verdict for an edited file

check_gate

Read-onlyIdempotent

Verify an edited source file passes the commit gate by comparing changed functions' complexity against their allowed ceiling. Use after an edit to confirm gate.ok before committing.

Instructions

Checks whether an edited file clears the hook's commit gate: fresh ccn per changed function against its scope's ceiling less pardoned ratchet debt. Call it after an edit once get_function_brief states the rule. CLI verify gives the repo-wide verdict. It runs no tests, and a breach reads gate.ok false, not an error. path is repo-relative or absolute inside repo, outside or missing is a config error. A tracked file is judged on its diff from HEAD, an untracked one in full, an unchanged or unscoped one judges 0. repo may be any directory under the checkout.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	Yes	repo-relative source file to judge as edited
`repo`	No	path to the scored repo's root (default: the repo the server was started in)

Output Schema

TableJSON Schema

Name	Required	Description
`gate`	No	the verdict block
`note`	No	fixed reminder that coverage is the baseline run's and complexity the working tree's; crapkit verify gives the real verdict
`schema`	No	payload schema version, 1
`functions`	No	every function in the file, rescored
`baseline_run`	No	id of the run whose coverage was reused
`baseline_commit`	No	that run's commit, full sha

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.7.6Sep 21, 2026

changedOutput schema / properties / functions / items / properties / remedy / description

Previous value: -"decompose (ccn over ceiling), add-tests (coverage short) or ok (nothing left to do)"New value: +"decompose (ccn over ceiling), split-lines (another function shares its source lines, so coverage cannot tell them apart and no test lowers the score until the definitions sit on separate lines), add-tests (coverage short) or ok (nothing left to do)"

changedOutput schema / properties / functions / items / properties / remedy / enum

Previous value: -[
-  "decompose",
-  "add-tests",
-  "ok"
-]New value: +[
+  "decompose",
+  "split-lines",
+  "add-tests",
+  "ok"
+]

changedOutput schema / properties / gate / properties / breaches / items / properties / remedy / description

Previous value: -"decompose (ccn over ceiling), add-tests (coverage short) or ok (nothing left to do)"New value: +"decompose (ccn over ceiling), split-lines (another function shares its source lines, so coverage cannot tell them apart and no test lowers the score until the definitions sit on separate lines), add-tests (coverage short) or ok (nothing left to do)"

changedOutput schema / properties / gate / properties / breaches / items / properties / remedy / enum

Previous value: -[
-  "decompose",
-  "add-tests",
-  "ok"
-]New value: +[
+  "decompose",
+  "split-lines",
+  "add-tests",
+  "ok"
+]

Addedv0.6.0Sep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses significant behavior beyond annotations: it runs no tests, a breach returns gate.ok false rather than an error, path outside/missing causes a config error, and tracked vs untracked files are judged differently. These details are not implied by readOnlyHint, idempotentHint, or destructiveHint, adding valuable operational context.

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 dense but well-structured, front-loading the core purpose and usage, then covering edge cases. Every sentence adds essential information—purpose, timing, scope, error handling, and file-state logic—with no redundancy or filler.

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?

With an output schema present, the description need not explain return values. It covers usage timing, input constraints, and behavioral edge cases (tracked/untracked, unchanged/unscoped) comprehensively. For a tool with this complexity, the description provides everything an agent needs to call it correctly without additional inference.

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 description adds meaning beyond the schema by clarifying that path can be repo-relative or absolute inside the repo, and that outside or missing is a config error. It also states repo may be any directory under the checkout, which extends the schema's default behavior. This goes beyond the schema's basic descriptions, though not exhaustively covering every parameter nuance.

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 precisely states the tool's purpose: checking whether an edited file clears the hook's commit gate, with a specific rule (fresh ccn against scope ceiling minus pardoned debt). It also differentiates from siblings by referencing get_function_brief as a prerequisite and CLI verify as a repo-wide alternative, making it clear when this tool is the right choice.

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?

Explicit usage guidance is provided: 'Call it after an edit once get_function_brief states the rule' and 'CLI verify gives the repo-wide verdict.' This tells the agent when to invoke this tool and when to use a different one, plus clarifies that it runs no tests, preventing expectations of test results.

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

Deploy Server