commit-check MCP

Catch bad commits before they merge — inside your AI agent.

Docs · Rules · CLI · GitHub Action · GitHub App

The Model Context Protocol server for Commit Check, commit policy as code for teams and AI agents. It gives your coding agent the rules your CI enforces: the agent validates its commit message, branch name and author before it commits or pushes, and when a correction is unambiguous it gets the fix to apply.

Quick start

claude mcp add commit-check -- uvx commit-check-mcp

Every other client launches the same command. This is the object to register:

{
  "mcpServers": {
    "commit-check": {
      "command": "uvx",
      "args": ["commit-check-mcp"]
    }
  }
}

No uv yet? curl -LsSf https://astral.sh/uv/install.sh | sh — or use pip install commit-check-mcp, as in the last row below.

Where each client keeps it

Continue's config.yaml entry in full (name, version and schema are required by Continue; drop them if you are adding only the mcpServers fragment to an existing file, or save this as a standalone file in .continue/mcpServers/):

name: commit-check
version: 0.0.1
schema: v1
mcpServers:
  - name: commit-check
    command: uvx
    args: ["commit-check-mcp"]

Tools

Every tool but server_health also takes:

• repo_path — the repository whose cchk.toml / commit-check.toml applies. It must be a git repository when the tool reads git state; a plain directory holding a config file is enough when you pass every value yourself.
• config_path — a config file to use instead of the repository's own; relative paths resolve from repo_path.
• config — inline overrides merged on top, e.g. {"commit": {"require_body": true}}.

No tool changes the working tree or the commits. validate_push_safety and validate_repository_state may run git fetch to resolve a SHA, so only they are annotated as not read-only; a client that gates on MCP tool hints can auto-approve the other six.

{
  "message": "feat(api): add MCP validation tool",
  "repo_path": "/path/to/repo"
}

{
  "repo_path": "/path/to/repo",
  "include_push": true
}

{
  "repo_path": "/path/to/repo",
  "push_refs": "refs/heads/main abc123 refs/heads/main def456"
}

{
  "repo_path": "/path/to/repo",
  "config": {
    "commit": {
      "require_body": true
    }
  }
}

Results

Every validate_* tool returns the shape commit-check --format json prints:

{
  "status": "pass|fail|skip",
  "warnings": 0,
  "checks": [
    {
      "rule_id": "CC001",
      "check": "message",
      "status": "pass|fail|warn|skip",
      "value": "...",
      "error": "...",
      "suggest": "...",
      "fix": "...",
      "docs_url": "https://commit-check.com/rules/#cc001"
    }
  ]
}

• Only fail is a rejection. skip means nothing was validated — never read it as approval — and warn is reported without failing the run.
• On fail, apply a non-empty fix verbatim, otherwise follow suggest, then validate again. The server's instructions teach the agent this loop.
• A call that cannot run at all — an empty message, a repo_path that does not exist or is not a git repository where one is needed, an invalid config, a push_refs SHA that cannot be resolved — comes back as an MCP tool error that names the problem, never as a pass.

Development

pip install -e .[dev]
python -m pytest

The server speaks stdio, so an MCP client launches it; run uvx commit-check-mcp by hand only to see that it starts.

_{mcp-name: io.github.commit-check/commit-check-mcp}