Skip to main content
Glama
commit-check

commit-check-mcp

Official
by commit-check

Validate push safety

validate_push_safety
Idempotent

Prevent accidental force pushes by verifying the remote commit is an ancestor of the local commit before pushing, rejecting any push that would rewrite remote history.

Instructions

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.

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}}.
push_refsNoRefs about to be pushed, in git pre-push hook stdin format, one ref per line: '<local_ref> <local_sha> <remote_ref> <remote_sha>', e.g. 'refs/heads/main 1a2b3c... refs/heads/main 9f8e7d...'. A remote_sha of 40 zeros means a new branch (never a force push). Every other SHA must resolve to a commit in repo_path (the check runs git merge-base and may fetch the remote ref first); a SHA that still cannot be resolved is a tool error, not a pass, so fetch it first. Omit to check the current branch of repo_path against its upstream instead. Must be non-empty when provided.
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 / push_refs / description
      Added value: +"Refs about to be pushed, in git pre-push hook stdin format, one ref per line: '<local_ref> <local_sha> <remote_ref> <remote_sha>', e.g. 'refs/heads/main 1a2b3c... refs/heads/main 9f8e7d...'. A remote_sha of 40 zeros means a new branch (never a force push). Every other SHA must resolve to a commit in repo_path (the check runs git merge-base and may fetch the remote ref first); a SHA that still cannot be resolved is a tool error, not a pass, so fetch it first. Omit to check the current branch of repo_path against its upstream instead. Must be non-empty when provided."
    • 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.7/5.0
Behavior5/5

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

The description discloses a side effect not captured by annotations: 'may run `git fetch <remote> <ref>` to resolve SHAs, which updates FETCH_HEAD and remote-tracking refs.' It also states that force pushes are always rejected regardless of config, and that a SHA that cannot be resolved is a tool error, never a pass. These details go well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) and give the agent accurate expectations of side effects and failure semantics.

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 long but every sentence adds necessary information. It is front-loaded with the core purpose, then covers side effects, return schema, and usage notes in a logical order. It avoids fluff and repetition, making the length justified by the complexity of the tool (non-trivial statuses, warn/skip semantics, and fix handling).

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 goes beyond it to explain the meaning of status values ('only fail is a rejection', 'skip means nothing was validated'), warn vs skip semantics, and the fix/suggest handling. It also covers edge cases (unresolvable SHAs, force push always rejected, config cannot re-enable). Together with the schema, an agent has everything needed to call the tool correctly and interpret results.

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 input schema has 100% description coverage with detailed explanations for every parameter (config, push_refs, repo_path, config_path), including formats, defaults, and behaviors. The tool description itself does not add parameter-specific meaning beyond referencing the rule logic; it focuses on behavior and return format. Since the schema already carries the parameter documentation, a baseline score of 3 is appropriate.

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 states a specific verb and resource: 'Check that a pending push is not a force push' with the exact rule ID (CC301, no_force_push). It clearly distinguishes this tool from the sibling validators (validate_commit_message, validate_branch_name, etc.) by focusing exclusively on push safety, and even notes 'Only the no_force_push rule runs.' This leaves no ambiguity about what the tool does.

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?

The description explicitly instructs 'Call this before `git push`.' It also clarifies when the tool is not a pass: 'skip' means nothing was validated and the result is not approval. It explains the failure path (no automatic fix, follow suggest) and the requirement to fetch unresolvable SHAs first. This provides clear when-to-use and edge-case handling beyond the schema.

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