Skip to main content
Glama
commit-check

commit-check-mcp

Official
by commit-check
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

commit-check-mcp

PyPI version Python versions Build Coverage MCP server MCP Registry Glama

Model Context Protocol (MCP) server for commit-check.

commit-check-mcp exposes commit-check as local MCP tools so an MCP client can validate commit messages, branch names, author info, push safety, and repository state.

Features

This MCP server exposes commit-check validations as MCP tools:

  • server_health — returns server/sdk versions

  • validate_commit_message — validates a commit message

  • validate_branch_name — validates a branch name or the current repo branch

  • validate_push_safety — validates that a push is not a force push

  • validate_author_info — validates author name/email or the repo's git author config

  • validate_commit_context — runs combined checks in one call

  • validate_repository_state — validates latest commit, current branch, author state, and optional push safety for a repo

  • describe_validation_rules — returns the effective config and enabled rules after merging defaults and repo config

All validation tools return the same structured commit-check result shape:

{
  "status": "pass|fail",
  "checks": [
    {
      "check": "message",
      "status": "pass|fail",
      "value": "...",
      "error": "...",
      "suggest": "..."
    }
  ]
}

Related MCP server: mcp-commits

Installation

pip install commit-check-mcp

This installs the commit-check-mcp CLI entrypoint.

For local development from this repository:

pip install -e .

Use With An MCP Client

This server runs over stdio, so it is meant to be launched by an MCP client rather than used as a long-running HTTP service.

With uvx (recommended — no install needed):

# Run once, no pip install required
uvx commit-check-mcp

Tip: If uv is not installed, get it via curl -LsSf https://astral.sh/uv/install.sh | sh.

Claude Desktop

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

Claude Code CLI

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

Add to your ~/.claude/settings.json or project-level .claude/settings.local.json.

Cursor

In Cursor, go to Settings → Cursor Settings → MCP → Add new MCP server and paste:

Field

Value

Name

commit-check

Type

command

Command

uvx commit-check-mcp

Or add to your project's .cursor/mcp.json:

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

Windsurf

Add to your ~/.codeium/windsurf/mcp_config.json:

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

Cline (VS Code)

Add a new MCP server in the Cline extension settings:

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

Continue.dev (VS Code / JetBrains)

Add to your ~/.continue/config.json:

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

Roo Code

Add to your Roo Code MCP settings:

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

Zed

Add to your ~/.config/zed/settings.json:

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

Generic / Any MCP Client

If your client does not support uvx, use pip and the direct path:

pip install commit-check-mcp
which commit-check-mcp

Then use the absolute path in your config:

{
  "mcpServers": {
    "commit-check": {
      "command": "/path/to/commit-check-mcp"
    }
  }
}

Run Manually

# If installed via pip
commit-check-mcp

# Or via uvx (no install needed)
uvx commit-check-mcp

The server uses stdio transport, which is the recommended MCP default for local tool integrations.

Tool Usage

After the client starts the server, it will expose these tools:

  • server_health: returns server, SDK, and dependency versions

  • validate_commit_message(message, config?, repo_path?, config_path?)

  • validate_branch_name(branch?, config?, repo_path?, config_path?)

  • validate_push_safety(push_refs?, config?, repo_path?, config_path?)

  • validate_author_info(author_name?, author_email?, config?, repo_path?, config_path?)

  • validate_commit_context(message?, branch?, author_name?, author_email?, config?, repo_path?, config_path?)

  • validate_repository_state(repo_path?, config?, config_path?, include_message?, include_branch?, include_author?, include_push?)

  • describe_validation_rules(config?, repo_path?, config_path?)

The common optional arguments are:

  • repo_path: repository directory to validate against

  • config_path: explicit TOML config file; relative paths resolve from repo_path

  • config: ad-hoc config overrides merged on top of defaults and repo config

Common Examples

Validate a commit message using repo-local rules:

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

Validate the current repository branch using an explicit config file:

{
  "repo_path": "/path/to/repo",
  "config_path": ".github/commit-check.toml"
}

Validate the full repository state:

{
  "repo_path": "/path/to/repo",
  "include_message": true,
  "include_branch": true,
  "include_author": true
}

Validate push safety from git pre-push hook ref metadata:

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

Inspect the final merged rules that will be applied:

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

Repository-Aware Validation

commit-check is most useful when it runs against a real git repository and its cchk.toml or commit-check.toml file. This MCP server now supports that directly:

  • repo_path — run git-based validations against a specific repository

  • config_path — point to an explicit TOML config file; relative paths are resolved from repo_path

  • config — apply ad-hoc overrides on top of defaults and repo config

Typical patterns:

  • Validate an explicit message with a repository's rules

  • Validate the current repository state without passing message/branch/author values manually

  • Validate push safety using pre-push ref metadata, or check the current branch against its upstream

  • Inspect which rules are actually enabled after config merging

Example payload for a repository-wide validation:

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

Config precedence is:

  1. commit-check built-in defaults

  2. repository config loaded from repo_path

  3. config_path when explicitly provided

  4. inline config overrides passed to the tool

Published On

Directory

Link

Official MCP Registry

io.github.commit-check/commit-check-mcp

Glama.ai

github/commit-check/commit-check-mcp

PyPI

commit-check-mcp

mcp-name: io.github.commit-check/commit-check-mcp

Available Tools

8 tools
describe_validation_rulesA

Return enabled commit-check rules after merging defaults, repo config, and inline overrides. Read-only, no side effects. Returns a dict with commit_check_version, the full merged config, supported check types, and enabled rules (each with check name, config, and pattern details).

Use this to inspect which validation rules are currently active before running any validation. Helps debug rule configuration and check which checks will be applied.

Parameters:

  • config (optional): Inline JSON config overrides on top of any loaded config file.

  • repo_path (optional): Path to the git repository for repo-relative config loading.

  • config_path (optional): Path to a custom commit-check TOML config file.

ParametersJSON Schema
NameRequiredDescriptionDefault
configNo
repo_pathNo
config_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and clearly states 'Read-only, no side effects.' It also details the return dict contents (commit_check_version, merged config, supported check types, enabled rules). This is transparent and accurate.

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 description is front-loaded with the main action and return value. It uses two paragraphs and a bullet-like list for parameters. Every sentence adds value, though the parameter list could be more structured. Overall, it is appropriately sized.

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?

Given that an output schema exists, the description already covers return values. It also explains the tool's use case, differentiates from siblings, and covers all three optional parameters. It is complete for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains each parameter: config (inline JSON overrides), repo_path (path to repo for config loading), config_path (path to custom config file). These explanations add meaning beyond the schema properties, which only have type and default.

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 clearly states the tool's purpose: 'Return enabled commit-check rules after merging defaults, repo config, and inline overrides.' It specifies the verb 'Return' and the resource 'enabled commit-check rules,' distinguishing it from sibling tools that perform actual validation.

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?

The description says 'Use this to inspect which validation rules are currently active before running any validation. Helps debug rule configuration and check which checks will be applied.' It implies when to use and hints at alternatives (the validate_* tools), but does not explicitly state when not to use it.

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

server_healthA

Return server and dependency versions. Read-only, no side effects. Returns dict with server name, server version, commit-check version, and MCP SDK version. Useful as a first call to verify the server is running and check version compatibility.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses that the tool is read-only and has no side effects. Since annotations are absent, this provides necessary behavioral context. However, it does not cover potential rate limits or authentication requirements, but for a simple health check, this is adequate.

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 two sentences, efficiently conveying the purpose, safety, return value, and recommended usage. No redundant information is present.

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?

Given the tool has no parameters and a simple output, the description fully captures its functionality. The existence of an output schema further reduces the need to detail return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so the description does not need to add parameter meaning. With 100% schema coverage and zero parameters, the baseline score of 4 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 clearly states the tool returns server and dependency versions and is useful as a health check. It distinguishes itself from sibling tools, which are validation-related, by focusing on server status and version compatibility.

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?

The description explicitly recommends using this tool as a first call to verify server availability and version compatibility. While it does not mention when not to use it, the context makes its usage clear and distinct from siblings.

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

validate_author_infoA

Validate commit author name and/or email with commit-check. Read-only validation. Returns a structured result with overall status and per-check results (check name, status, value, error, suggest).

Use this when you need to verify author metadata against configured rules (e.g., allowed email domains, name patterns). When both name and email are provided, both are validated. If neither is provided, both are checked against repo context. For combined validation, use validate_commit_context.

Parameters:

  • author_name (optional): The author name to validate.

  • author_email (optional): The author email to validate.

  • config (optional): Inline JSON config overrides.

  • repo_path (optional): Path to the git repository.

  • config_path (optional): Path to a custom commit-check TOML config file.

ParametersJSON Schema
NameRequiredDescriptionDefault
configNo
repo_pathNo
author_nameNo
config_pathNo
author_emailNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It declares 'Read-only validation' and explains behavior when both or neither name/email are provided, as well as the return structure. However, it does not elaborate on potential errors or what constitutes a valid config, leaving minor gaps.

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 concise: a few sentences establishing purpose and behavior, followed by a bulleted list of parameters. It front-loads the main action and result, with no unnecessary words or repetition.

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?

Given the tool has 5 optional parameters and an output schema (mentioned in context), the description adequately covers inputs with parameter descriptions and outputs with the return structure. It also references a sibling for combined validation, making it complete for an agent to use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It lists all 5 parameters with brief explanations (e.g., config as 'Inline JSON config overrides', config_path as 'Path to a custom commit-check TOML config file'). This adds value beyond the schema's type-only information, though it lacks details on defaults or constraints.

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 description clearly states the tool validates commit author name and/or email using commit-check, and specifies it is read-only. It also mentions returning a structured result. While it distinguishes from the sibling validate_commit_context by pointing out combined validation, it could be more explicit about which rules are applied.

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 says 'Use this when you need to verify author metadata against configured rules' and directs users to 'use validate_commit_context' for combined validation. This provides clear when-to-use guidance and an alternative, fulfilling the dimension criteria.

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

validate_branch_nameA

Validate branch naming conventions with commit-check. Read-only validation. Returns a structured result with overall status ('pass'/'fail') and per-check results (check name, status, value, error, suggest).

Use this when you need to verify a branch name follows configured convention rules (e.g., feature/, bugfix/). For combined message+branch+author validation, use validate_commit_context.

Parameters:

  • branch (optional): The branch name to validate. If omitted, detected from the current repo.

  • config (optional): Inline JSON config overrides.

  • repo_path (optional): Path to the git repository.

  • config_path (optional): Path to a custom commit-check TOML config file.

ParametersJSON Schema
NameRequiredDescriptionDefault
branchNo
configNo
repo_pathNo
config_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior4/5

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

Discloses read-only nature and return structure (overall status + per-check results). No annotations exist, so description covers key behavioral aspects. Could mention config handling implications but not required.

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?

Concise: one summary sentence, usage guidance, and parameter list. Front-loaded with purpose. No unnecessary words.

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?

Given optional parameters, output schema existence, and sibling context, description covers usage, parameters, and return value adequately. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; description thoroughly explains each parameter's purpose and default behavior (e.g., branch auto-detected if omitted, config as inline JSON).

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?

Clear verb 'validate' and specific resource 'branch name conventions'. Distinguishes from siblings by mentioning combined validation alternative.

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?

Explicitly states when to use (verify branch name follows conventions) and when not (use validate_commit_context for combined checks). Includes parameter behavior details.

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

validate_commit_contextA

Run combined commit-check validations for message, branch, and/or author in one call. Read-only validation. Returns a structured result with overall status and a unified list of per-check results (check name, status, value, error, suggest).

Use this when you need to validate multiple commit aspects simultaneously in a single call. At least one of message, branch, author_name, or author_email must be provided. For individual aspects, use the specific validate_commit_message, validate_branch_name, or validate_author_info tools.

Parameters:

  • message (optional): Commit message text to validate.

  • branch (optional): Branch name to validate.

  • author_name (optional): Author name to validate.

  • author_email (optional): Author email to validate.

  • config (optional): Inline JSON config overrides on top of any loaded config file.

  • repo_path (optional): Path to the git repository for repo-relative config loading.

  • config_path (optional): Path to a custom commit-check TOML config file.

ParametersJSON Schema
NameRequiredDescriptionDefault
branchNo
configNo
messageNo
repo_pathNo
author_nameNo
config_pathNo
author_emailNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Explicitly states 'Read-only validation' and describes the structured return format (overall status, per-check results with fields like check name, status, value, error, suggest). With no annotations, this provides good behavioral context.

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: first sentence for purpose, then read-only note and return shape, then usage guidance, then parameter list. Front-loaded with core function. Slight redundancy with parameter list but justified.

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?

Given no required parameters and 7 optional, description clarifies at least one must be provided. Mentions return structure fields. Siblings are listed in context. Sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description fully compensates. All 7 parameters are explained: message, branch, author_name, author_email, config (inline JSON overrides), repo_path (repo-relative config), config_path (custom TOML file). Adds meaning beyond names.

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 clearly states it runs combined commit-check validations for message, branch, and/or author in one call. It distinguishes itself from siblings by naming the specific tools for individual aspects.

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?

Explicitly says 'At least one of message, branch, author_name, or author_email must be provided' and directs users to specific validate_commit_message, validate_branch_name, or validate_author_info tools for individual aspects.

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

validate_commit_messageA

Validate a commit message against commit-check rules. Read-only validation. Returns a structured result with overall status ('pass'/'fail') and a list of per-check results. Each check includes the check name, status, value, error message (on failure), and suggestion (on failure).

Use this tool when you have a specific commit message string to validate. For batch validation of message, branch, and author together, use validate_commit_context instead.

Parameters:

  • message (required): The commit message text to validate.

  • config (optional): Inline JSON config overrides on top of any loaded config file.

  • repo_path (optional): Path to the git repository for repo-relative config loading.

  • config_path (optional): Path to a custom commit-check TOML config file.

ParametersJSON Schema
NameRequiredDescriptionDefault
configNo
messageYes
repo_pathNo
config_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A5/5.0
Behavior5/5

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

States the tool is read-only validation, which is a key behavioral trait. Without annotations, the description fully covers behavior and describes the return structure (overall status and per-check results).

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 concise and well-structured: first paragraph states purpose and output, second provides usage guidance, third lists parameters. No superfluous content.

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?

Given the tool's complexity (4 parameters, no annotations, with output schema), the description is complete, covering all parameters, usage context, and output format. It also differentiates from siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining each parameter's purpose (message required, config for inline JSON overrides, repo_path for repo-relative config, config_path for custom config file), adding meaning beyond 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?

The description clearly states the tool validates a commit message against commit-check rules, specifies it is read-only, and distinguishes it from the sibling tool validate_commit_context by stating this tool is for a single message string.

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?

Explicitly says when to use this tool ('when you have a specific commit message string') and when not to, providing an alternative (validate_commit_context for batch validation).

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

validate_push_safetyA

Validate that a push is not a force push. Read-only validation. Returns a structured result with overall status and per-check results (check name, status, value, error, suggest). By default, force push is rejected; configure via 'push.allow_force_push' in config.

Use this before performing a git push to ensure force-push protection rules are satisfied. Only validates the no_force_push rule. Use validate_commit_context for combined checks.

Parameters:

  • push_refs (optional): The push ref specification to validate. If omitted, checks upstream fallback state.

  • config (optional): Inline JSON config overrides.

  • repo_path (optional): Path to the git repository.

  • config_path (optional): Path to a custom commit-check TOML config file.

ParametersJSON Schema
NameRequiredDescriptionDefault
configNo
push_refsNo
repo_pathNo
config_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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

Discloses read-only behavior, describes return format (structured result with status and per-check details), and mentions configuration for allowing force push, all without annotations.

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?

Efficiently structured: first line states purpose and behavior, then output, usage, and parameter list. No unnecessary words.

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?

Covers all aspects: purpose, usage, output format, parameters, configuration, and sibling reference. Output schema exists, so return details are complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description adds meaning for all 4 parameters: explains push_refs (and behavior if omitted), config (inline JSON overrides), repo_path, and config_path. Lacks some detail on expected formats but is helpful.

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?

Clearly states the tool validates that a push is not a force push, explicitly mentions it is read-only, and distinguishes itself from sibling 'validate_commit_context' for combined checks.

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?

Provides explicit guidance: use before git push for force-push protection, notes it only validates the no_force_push rule, and directs to sibling for combined checks.

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

validate_repository_stateA

Validate the current repository state including latest commit message, active branch, author metadata, and optional push safety. Read-only validation. Reads git data (message, branch, author) from the local repository. Returns a structured result with overall status and per-check results.

Use this to validate the entire state of a local git repository in one call — ideal for pre-commit or CI hooks. Controls which checks run via boolean include_* flags. For validating arbitrary (non-repo) values, use validate_commit_context or individual validation tools instead.

Parameters:

  • repo_path (optional): Path to the git repository. If omitted, uses current working directory.

  • config (optional): Inline JSON config overrides on top of any loaded config file.

  • config_path (optional): Path to a custom commit-check TOML config file.

  • include_message (optional, default true): Whether to validate the latest commit message.

  • include_branch (optional, default true): Whether to validate the current branch name.

  • include_author (optional, default true): Whether to validate the latest commit author.

  • include_push (optional, default false): Whether to validate push safety.

ParametersJSON Schema
NameRequiredDescriptionDefault
configNo
repo_pathNo
config_pathNo
include_pushNo
include_authorNo
include_branchNo
include_messageNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior4/5

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

Declares read-only validation, reads git data, returns structured results. Does not cover error behavior for missing repos or invalid paths, but sufficient given no annotations.

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?

Well-structured: purpose, behavior, usage, then parameter list. Front-loaded with key info. No unnecessary words.

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?

Covers all 7 parameters, returns structure, and differentiates from 7 siblings. Output schema exists, so return description is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description adds essential meaning: explains each parameter's purpose, defaults, and optionality. Provides context like 'if omitted, uses current working directory'.

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 clearly states it validates the entire repository state (commit message, branch, author, push safety). It distinguishes from sibling tools by specifying that for non-repo values, other tools should be used.

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?

Explicitly says 'Use this to validate the entire state of a local git repository in one call — ideal for pre-commit or CI hooks' and provides alternatives for other cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv0.1.0
    • First observeddescribe_validation_rules
    • First observedserver_health
    • First observedvalidate_author_info
    • First observedvalidate_branch_name
    • First observedvalidate_commit_context
    • First observedvalidate_commit_message
    • First observedvalidate_push_safety
    • First observedvalidate_repository_state
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct aspect of commit validation (author, branch, message, push safety, repository state, config inspection, and health). No two tools have overlapping purposes; the composite tools clearly indicate their scope.

Naming Consistency5/5

All tools follow a consistent verb_noun naming pattern (e.g., describe_validation_rules, validate_author_info, server_health). No mixing of conventions or ambiguous verbs.

Tool Count5/5

Eight tools is well-scoped for a commit-check validation server. It covers individual validation areas, combined validation, config introspection, and health checks without being excessive or sparse.

Completeness5/5

The tool surface covers all common commit validation needs: message, branch, author, push safety, and repository state. Combined validation tools avoid dead-ends, and config inspection supports debugging. No obvious gaps.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/commit-check/commit-check-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server