Skip to main content
Glama
Sign In
CodeHealth MCP Server

CodeHealth MCP Server

by microbrewerGM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pre_commit_code_health_safeguard

Check staged and modified files against HEAD before each commit and fail the quality gate when touched code worsens, preventing code health regressions.

Instructions

Check staged and modified files against HEAD before committing.

When to use: before every commit made by an agent.
Limitations: tracked files only (untracked files are skipped); compares
the working tree with HEAD using HEAD's root rules file for both sides.
Returns: {quality_gate: passed|failed, counts, rules_changed?,
files:[{path, verdict (improved|degraded|stable|removed|unknown),
old_score, new_score, new_findings, worsened, improved, fixed}],
cross_file_duplication?: CPD copies and renamed clones between changed files (informational),
analyzers?}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repository_path": "<repository_path>"
    },
    "name": "pre_commit_code_health_safeguard"
  }
}

Input Schema

NameRequiredDescriptionDefault
repository_pathYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full disclosure burden and does reasonably well: it names the comparison baseline (working tree vs HEAD), the rules-file resolution rule (HEAD's root rules file for both sides), and the tracked-files-only limitation, which is a real behavioral caveat. It does not say whether the tool only reports or can block a commit, nor whether it modifies anything, leaving the safeguard's enforcement semantics ambiguous.

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 label-prefixed structure (behavior, When to use, Limitations, Returns) is well front-loaded and easy to scan. The Returns block is long and restates field names that an output schema already provides, so part of it is redundant, though the verdict vocabulary adds genuine semantic detail.

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?

An output schema exists, so the tool does not need to enumerate return values, and its limitations plus usage trigger cover the key agent decisions. The main residual gap is the undocumented repository_path and the unstated consequence of a failed quality_gate, which for a pre-commit safeguard is the one thing an agent most needs to know.

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?

The schema has a single required parameter, repository_path, at 0% description coverage, and the description never mentions it. The name is largely self-explanatory, so an agent can plausibly supply an absolute repo path, but no format, rooting, or resolution behavior is confirmed anywhere.

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

Purpose4/5

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

The first sentence gives a specific verb and scope: check staged and modified files against HEAD. That is materially more precise than the tool name alone and implies a pre-commit quality gate. It stops short of naming a sibling to contrast with (e.g. code_health_review or analyze_change_set), so differentiation is inferred from timing rather than stated.

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?

'When to use: before every commit made by an agent' is an explicit, actionable trigger that tells the agent exactly when to reach for this tool. There is no when-not guidance and no named alternative for cases like reviewing an already-committed change set, which keeps it out of the top band.

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

Deploy Server

Other Tools