Skip to main content
Glama
commit-check

commit-check-mcp

Official
by commit-check
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Validate commit message

validate_commit_message
Read-onlyIdempotent

Validate a commit message against commit-check rules (Conventional Commits, subject length, body, sign-off). Get pass/fail status with warnings and fixes before committing.

Instructions

Validate a commit message against commit-check rules (Conventional Commits type and format, subject length and case, body, sign-off, WIP/fixup markers, AI attribution: whatever the effective config enables). Read-only; touches no git state.

Returns {status, warnings, checks[]}. status is 'pass', 'fail' or 'skip': only 'fail' is a rejection; 'skip' means every check skipped, so nothing was validated and the result is not approval. warnings is the number of checks with status 'warn'. Each check has: rule_id (stable rule id, e.g. 'CC001'); check (rule name, e.g. 'message'); status 'pass' | 'fail' | 'warn' | 'skip' ('warn' = the config lists the check under warn, so the finding is reported without failing the run; 'skip' = the rule did not run, e.g. the author is in ignore_authors or there was nothing to check); value (what was checked); error (why it failed); suggest (advice for a person); fix (the corrected value when the correction is unambiguous, else ''); docs_url (documentation for the rule). On 'fail', apply a non-empty fix verbatim; when fix is '', rewrite following suggest; then validate again.

Use this when you have one commit message string to check before committing. To check message, branch and author in one call use validate_commit_context; to check the latest commit already in a repository use validate_repository_state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configNoInline commit-check config overrides as a JSON object, merged on top of the built-in defaults and any config file, e.g. {"warn": ["message"]} or {"commit": {"require_body": true}}.
messageYesFull commit message text to validate: subject line, optional blank line, body (and trailers such as Signed-off-by). Must be non-empty.
repo_pathNoPath to the git repository to validate against. Its cchk.toml or commit-check.toml (also looked up under .github/) is loaded, and a relative config_path is resolved from it. Omit to use the server's working directory.
config_pathNoPath to a commit-check TOML config file, used instead of the repository's own cchk.toml/commit-check.toml; a relative path is resolved from repo_path.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.10
    • addedInput schema / properties / config / description
      Added value: +"Inline commit-check config overrides as a JSON object, merged on top of the built-in defaults and any config file, e.g. {\"warn\": [\"message\"]} or {\"commit\": {\"require_body\": true}}."
    • addedInput schema / properties / config_path / description
      Added value: +"Path to a commit-check TOML config file, used instead of the repository's own cchk.toml/commit-check.toml; a relative path is resolved from repo_path."
    • addedInput schema / properties / message / description
      Added value: +"Full commit message text to validate: subject line, optional blank line, body (and trailers such as Signed-off-by). Must be non-empty."
    • addedInput schema / properties / repo_path / description
      Added value: +"Path to the git repository to validate against. Its cchk.toml or commit-check.toml (also looked up under .github/) is loaded, and a relative config_path is resolved from it. Omit to use the server's working directory."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations carry readOnlyHint/idempotentHint/destructiveHint, and the description reinforces them ('Read-only; touches no git state'). It goes far beyond annotations by explaining the full return semantics: status values with the critical 'skip ≠ approval' distinction, warn-vs-skip meanings, every check field, and the actionable workflow (apply fix verbatim, else follow suggest, then re-validate). Rich and non-redundant.

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?

Well-structured and front-loaded with purpose, then rules list, then result semantics, then routing. The return-format explanation is long and somewhat redundant given an output schema exists, though the semantic interpretation (skip is not approval, warn vs skip) adds value the schema structure alone may not convey. Each section earns its place but the whole is dense.

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?

Complete for a validation tool with 4 params and an output schema. It explains when to call it, what it returns, how to interpret results, and how to act on failures. An output schema covers the return structure, so the description's job is routing + semantics, both fully handled. Nothing an agent needs to call it correctly is missing.

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 description coverage is 100%, so baseline is 3. The description relates the config parameter to effective behavior ('whatever the effective config enables') but adds little parameter-specific syntax beyond the schema. The schema already documents config overrides, repo_path and config_path lookup, so the description rightly leaves this to 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?

States a specific verb+resource ('Validate a commit message against commit-check rules') and enumerates the rule families checked (Conventional Commits type/format, subject length/case, body, sign-off, WIP/fixup, AI attribution). It distinguishes itself from siblings by explicitly scoping to a single message string, which separates it from validate_commit_context and validate_repository_state.

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?

Gives an explicit when-to-use directive ('Use this when you have one commit message string to check before committing') and names the two alternatives with their exact conditions: validate_commit_context for message+branch+author in one call, validate_repository_state for a latest commit already in a repo. No inference required.

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