commit-check MCP

Return the commit-check rules that are in effect after merging the built-in defaults, the repository's config file (or config_path) and the inline config overrides. Read-only, no side effects. Returns {commit_check_version, config (the merged config), supported_checks (every check name commit-check knows), enabled_rules[]} where each enabled rule carries its check name, config and pattern details. Use this before writing a commit message or branch name to learn the expected format instead of guessing, and to debug why a validation failed or was skipped.

Return server and dependency versions. Read-only, no side effects. Returns {server, server_version, commit_check_version, mcp_sdk_version}. Useful as a first call to verify the server is running and to check version compatibility.

Validate a commit author's name and/or email against the configured rules (e.g. allowed email domains, name patterns). Read-only. 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 to check author metadata before committing. Only the values you pass are checked; if neither is given, both are read from repo_path's git config (falling back to the latest commit) and repo_path must be a git repository. For combined validation use validate_commit_context.

Validate a branch name against the configured naming convention (e.g. feature/*, bugfix/*) and, when configured, that the branch is based on the required merge base. Read-only. 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 before creating or pushing a branch. Omit branch to check the branch currently checked out in repo_path. For combined message+branch+author validation use validate_commit_context.

Run the commit message, branch name and author checks together in one call, for whichever of message, branch, author_name and author_email you pass. Read-only. 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 to validate several aspects of a commit you are about to make with a single call. At least one of message, branch, author_name or author_email is required; omitted aspects are not checked. For one aspect use validate_commit_message, validate_branch_name or validate_author_info; for the commit already at HEAD use validate_repository_state.

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.

Check that a pending push is not a force push (rule CC301, no_force_push): fails when a remote_sha is not an ancestor of its local_sha, i.e. the push would rewrite remote history. Leaves your working tree and commits untouched, but may run `git fetch <remote> <ref>` to resolve SHAs, which updates FETCH_HEAD and remote-tracking refs. A SHA that cannot be resolved even then is a tool error, never a pass. Force pushes are always rejected by this tool; push.allow_force_push in config cannot re-enable them here. 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. Call this before `git push`. Only the no_force_push rule runs. When it fails there is no automatic fix (fix is ''): follow suggest, i.e. push without --force/--force-with-lease or rebase onto the remote first, then validate again.

Validate what is already in a local git repository: the latest commit's message and author, the checked-out branch name and, optionally, whether pushing that branch to its upstream would be a force push. Leaves the working tree and commits untouched; the push check may run `git fetch`, which updates FETCH_HEAD and remote-tracking refs. 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 to check a repository's current state in one call, e.g. after committing and before pushing, or in a hook. The include_* flags select the checks; at least one must be true. To validate values that are not yet committed use validate_commit_context or the single-aspect tools.