commit-check-mcp 0.1.1.post1.dev1__tar.gz → 0.1.2__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (23) hide show
  1. commit_check_mcp-0.1.2/.github/workflows/labeler.yml +14 -0
  2. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/.github/workflows/main.yml +9 -1
  3. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/.github/workflows/release-drafter.yml +1 -1
  4. commit_check_mcp-0.1.2/PKG-INFO +210 -0
  5. commit_check_mcp-0.1.2/README.md +194 -0
  6. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/pyproject.toml +2 -1
  7. commit_check_mcp-0.1.2/src/commit_check_mcp.egg-info/PKG-INFO +210 -0
  8. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/src/commit_check_mcp.egg-info/requires.txt +1 -0
  9. commit_check_mcp-0.1.1.post1.dev1/.github/workflows/labeler.yml +0 -22
  10. commit_check_mcp-0.1.1.post1.dev1/PKG-INFO +0 -86
  11. commit_check_mcp-0.1.1.post1.dev1/README.md +0 -71
  12. commit_check_mcp-0.1.1.post1.dev1/src/commit_check_mcp.egg-info/PKG-INFO +0 -86
  13. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/.github/workflows/publish.yml +0 -0
  14. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/.gitignore +0 -0
  15. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/LICENSE +0 -0
  16. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/setup.cfg +0 -0
  17. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/src/commit_check_mcp/__init__.py +0 -0
  18. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/src/commit_check_mcp/server.py +0 -0
  19. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/src/commit_check_mcp.egg-info/SOURCES.txt +0 -0
  20. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/src/commit_check_mcp.egg-info/dependency_links.txt +0 -0
  21. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/src/commit_check_mcp.egg-info/entry_points.txt +0 -0
  22. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/src/commit_check_mcp.egg-info/top_level.txt +0 -0
  23. {commit_check_mcp-0.1.1.post1.dev1 → commit_check_mcp-0.1.2}/tests/test_server.py +0 -0
@@ -0,0 +1,14 @@
1
+ name: PR Autolabeler
2
+
3
+ permissions:
4
+ contents: write
5
+ pull-requests: write
6
+
7
+ on:
8
+ # pull_request event is required for autolabeler
9
+ pull_request:
10
+ types: [opened, reopened, synchronize]
11
+
12
+ jobs:
13
+ draft-release:
14
+ uses: commit-check/.github/.github/workflows/pr-labeler.yml@main
@@ -35,7 +35,15 @@ jobs:
35
35
  python -m pip install -e .[dev]
36
36
 
37
37
  - name: Run tests
38
- run: python -m pytest -q
38
+ run: python -m pytest -q --cov=src/commit_check_mcp --cov-report=xml
39
+
40
+ - name: Upload coverage reports to Codecov
41
+ if: matrix.python-version == '3.12'
42
+ uses: codecov/codecov-action@v5
43
+ with:
44
+ token: ${{ secrets.CODECOV_TOKEN }}
45
+ slug: commit-check/commit-check-mcp
46
+ files: ./coverage.xml
39
47
 
40
48
  build:
41
49
  runs-on: ubuntu-24.04
@@ -12,5 +12,5 @@ jobs:
12
12
  draft-release:
13
13
  permissions:
14
14
  contents: write
15
- pull-requests: read
15
+ pull-requests: write
16
16
  uses: commit-check/.github/.github/workflows/release-drafter.yml@main
@@ -0,0 +1,210 @@
1
+ Metadata-Version: 2.4
2
+ Name: commit-check-mcp
3
+ Version: 0.1.2
4
+ Summary: MCP server exposing commit-check validation tools
5
+ Author: commit-check
6
+ License: MIT
7
+ Requires-Python: >=3.10
8
+ Description-Content-Type: text/markdown
9
+ License-File: LICENSE
10
+ Requires-Dist: commit-check<3,>=2.5.0
11
+ Requires-Dist: mcp<2,>=1.27.0
12
+ Provides-Extra: dev
13
+ Requires-Dist: pytest<10,>=9.0.0; extra == "dev"
14
+ Requires-Dist: pytest-cov<7,>=6.0.0; extra == "dev"
15
+ Dynamic: license-file
16
+
17
+ # commit-check-mcp
18
+
19
+ [![PyPI version](https://img.shields.io/pypi/v/commit-check-mcp)](https://pypi.org/project/commit-check-mcp/)
20
+ [![Python versions](https://img.shields.io/pypi/pyversions/commit-check-mcp)](https://pypi.org/project/commit-check-mcp/)
21
+ [![Build](https://github.com/commit-check/commit-check-mcp/actions/workflows/main.yml/badge.svg)](https://github.com/commit-check/commit-check-mcp/actions/workflows/main.yml)
22
+ [![Coverage](https://codecov.io/gh/commit-check/commit-check-mcp/graph/badge.svg)](https://codecov.io/gh/commit-check/commit-check-mcp)
23
+ [![MCP server](https://img.shields.io/badge/MCP-server-0A7B83)](https://modelcontextprotocol.io/)
24
+
25
+ Model Context Protocol (MCP) server for [commit-check](https://github.com/commit-check/commit-check).
26
+
27
+ `commit-check-mcp` exposes `commit-check` as local MCP tools so an MCP client can validate commit messages, branch names, author info, and repository state.
28
+
29
+ ## Features
30
+
31
+ This MCP server exposes commit-check validations as MCP tools:
32
+
33
+ - `server_health` — returns server/sdk versions
34
+ - `validate_commit_message` — validates a commit message
35
+ - `validate_branch_name` — validates a branch name or the current repo branch
36
+ - `validate_author_info` — validates author name/email or the repo's git author config
37
+ - `validate_commit_context` — runs combined checks in one call
38
+ - `validate_repository_state` — validates latest commit, current branch, and author state for a repo
39
+ - `describe_validation_rules` — returns the effective config and enabled rules after merging defaults and repo config
40
+
41
+ All validation tools return the same structured commit-check result shape:
42
+
43
+ ```json
44
+ {
45
+ "status": "pass|fail",
46
+ "checks": [
47
+ {
48
+ "check": "message",
49
+ "status": "pass|fail",
50
+ "value": "...",
51
+ "error": "...",
52
+ "suggest": "..."
53
+ }
54
+ ]
55
+ }
56
+ ```
57
+
58
+ ## Installation
59
+
60
+ ```bash
61
+ pip install commit-check-mcp
62
+ ```
63
+
64
+ This installs the `commit-check-mcp` CLI entrypoint.
65
+
66
+ For local development from this repository:
67
+
68
+ ```bash
69
+ pip install -e .
70
+ ```
71
+
72
+ ## Use With An MCP Client
73
+
74
+ 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.
75
+
76
+ Generic MCP client config:
77
+
78
+ ```json
79
+ {
80
+ "mcpServers": {
81
+ "commit-check": {
82
+ "command": "commit-check-mcp"
83
+ }
84
+ }
85
+ }
86
+ ```
87
+
88
+ If the client needs the full path to the executable, first locate it:
89
+
90
+ ```bash
91
+ which commit-check-mcp
92
+ ```
93
+
94
+ Then use that absolute path in the client config.
95
+
96
+ Example using an absolute path:
97
+
98
+ ```json
99
+ {
100
+ "mcpServers": {
101
+ "commit-check": {
102
+ "command": "/absolute/path/to/commit-check-mcp"
103
+ }
104
+ }
105
+ }
106
+ ```
107
+
108
+ For local development from this repository, that absolute path may point to something like `.venv/bin/commit-check-mcp`.
109
+
110
+ ## Run Manually
111
+
112
+ ```bash
113
+ commit-check-mcp
114
+ ```
115
+
116
+ The server uses stdio transport, which is the recommended MCP default for local tool integrations.
117
+
118
+ ## Tool Usage
119
+
120
+ After the client starts the server, it will expose these tools:
121
+
122
+ - `server_health`: returns server, SDK, and dependency versions
123
+ - `validate_commit_message(message, config?, repo_path?, config_path?)`
124
+ - `validate_branch_name(branch?, config?, repo_path?, config_path?)`
125
+ - `validate_author_info(author_name?, author_email?, config?, repo_path?, config_path?)`
126
+ - `validate_commit_context(message?, branch?, author_name?, author_email?, config?, repo_path?, config_path?)`
127
+ - `validate_repository_state(repo_path?, config?, config_path?, include_message?, include_branch?, include_author?)`
128
+ - `describe_validation_rules(config?, repo_path?, config_path?)`
129
+
130
+ The common optional arguments are:
131
+
132
+ - `repo_path`: repository directory to validate against
133
+ - `config_path`: explicit TOML config file; relative paths resolve from `repo_path`
134
+ - `config`: ad-hoc config overrides merged on top of defaults and repo config
135
+
136
+ ## Common Examples
137
+
138
+ Validate a commit message using repo-local rules:
139
+
140
+ ```json
141
+ {
142
+ "message": "feat(api): add MCP validation tool",
143
+ "repo_path": "/path/to/repo"
144
+ }
145
+ ```
146
+
147
+ Validate the current repository branch using an explicit config file:
148
+
149
+ ```json
150
+ {
151
+ "repo_path": "/path/to/repo",
152
+ "config_path": ".github/commit-check.toml"
153
+ }
154
+ ```
155
+
156
+ Validate the full repository state:
157
+
158
+ ```json
159
+ {
160
+ "repo_path": "/path/to/repo",
161
+ "include_message": true,
162
+ "include_branch": true,
163
+ "include_author": true
164
+ }
165
+ ```
166
+
167
+ Inspect the final merged rules that will be applied:
168
+
169
+ ```json
170
+ {
171
+ "repo_path": "/path/to/repo",
172
+ "config": {
173
+ "commit": {
174
+ "require_body": true
175
+ }
176
+ }
177
+ }
178
+ ```
179
+
180
+ ## Repository-Aware Validation
181
+
182
+ `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:
183
+
184
+ - `repo_path` — run git-based validations against a specific repository
185
+ - `config_path` — point to an explicit TOML config file; relative paths are resolved from `repo_path`
186
+ - `config` — apply ad-hoc overrides on top of defaults and repo config
187
+
188
+ Typical patterns:
189
+
190
+ - Validate an explicit message with a repository's rules
191
+ - Validate the current repository state without passing message/branch/author values manually
192
+ - Inspect which rules are actually enabled after config merging
193
+
194
+ Example payload for a repository-wide validation:
195
+
196
+ ```json
197
+ {
198
+ "repo_path": "/path/to/repo",
199
+ "include_message": true,
200
+ "include_branch": true,
201
+ "include_author": true
202
+ }
203
+ ```
204
+
205
+ Config precedence is:
206
+
207
+ 1. `commit-check` built-in defaults
208
+ 2. repository config loaded from `repo_path`
209
+ 3. `config_path` when explicitly provided
210
+ 4. inline `config` overrides passed to the tool
@@ -0,0 +1,194 @@
1
+ # commit-check-mcp
2
+
3
+ [![PyPI version](https://img.shields.io/pypi/v/commit-check-mcp)](https://pypi.org/project/commit-check-mcp/)
4
+ [![Python versions](https://img.shields.io/pypi/pyversions/commit-check-mcp)](https://pypi.org/project/commit-check-mcp/)
5
+ [![Build](https://github.com/commit-check/commit-check-mcp/actions/workflows/main.yml/badge.svg)](https://github.com/commit-check/commit-check-mcp/actions/workflows/main.yml)
6
+ [![Coverage](https://codecov.io/gh/commit-check/commit-check-mcp/graph/badge.svg)](https://codecov.io/gh/commit-check/commit-check-mcp)
7
+ [![MCP server](https://img.shields.io/badge/MCP-server-0A7B83)](https://modelcontextprotocol.io/)
8
+
9
+ Model Context Protocol (MCP) server for [commit-check](https://github.com/commit-check/commit-check).
10
+
11
+ `commit-check-mcp` exposes `commit-check` as local MCP tools so an MCP client can validate commit messages, branch names, author info, and repository state.
12
+
13
+ ## Features
14
+
15
+ This MCP server exposes commit-check validations as MCP tools:
16
+
17
+ - `server_health` — returns server/sdk versions
18
+ - `validate_commit_message` — validates a commit message
19
+ - `validate_branch_name` — validates a branch name or the current repo branch
20
+ - `validate_author_info` — validates author name/email or the repo's git author config
21
+ - `validate_commit_context` — runs combined checks in one call
22
+ - `validate_repository_state` — validates latest commit, current branch, and author state for a repo
23
+ - `describe_validation_rules` — returns the effective config and enabled rules after merging defaults and repo config
24
+
25
+ All validation tools return the same structured commit-check result shape:
26
+
27
+ ```json
28
+ {
29
+ "status": "pass|fail",
30
+ "checks": [
31
+ {
32
+ "check": "message",
33
+ "status": "pass|fail",
34
+ "value": "...",
35
+ "error": "...",
36
+ "suggest": "..."
37
+ }
38
+ ]
39
+ }
40
+ ```
41
+
42
+ ## Installation
43
+
44
+ ```bash
45
+ pip install commit-check-mcp
46
+ ```
47
+
48
+ This installs the `commit-check-mcp` CLI entrypoint.
49
+
50
+ For local development from this repository:
51
+
52
+ ```bash
53
+ pip install -e .
54
+ ```
55
+
56
+ ## Use With An MCP Client
57
+
58
+ 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.
59
+
60
+ Generic MCP client config:
61
+
62
+ ```json
63
+ {
64
+ "mcpServers": {
65
+ "commit-check": {
66
+ "command": "commit-check-mcp"
67
+ }
68
+ }
69
+ }
70
+ ```
71
+
72
+ If the client needs the full path to the executable, first locate it:
73
+
74
+ ```bash
75
+ which commit-check-mcp
76
+ ```
77
+
78
+ Then use that absolute path in the client config.
79
+
80
+ Example using an absolute path:
81
+
82
+ ```json
83
+ {
84
+ "mcpServers": {
85
+ "commit-check": {
86
+ "command": "/absolute/path/to/commit-check-mcp"
87
+ }
88
+ }
89
+ }
90
+ ```
91
+
92
+ For local development from this repository, that absolute path may point to something like `.venv/bin/commit-check-mcp`.
93
+
94
+ ## Run Manually
95
+
96
+ ```bash
97
+ commit-check-mcp
98
+ ```
99
+
100
+ The server uses stdio transport, which is the recommended MCP default for local tool integrations.
101
+
102
+ ## Tool Usage
103
+
104
+ After the client starts the server, it will expose these tools:
105
+
106
+ - `server_health`: returns server, SDK, and dependency versions
107
+ - `validate_commit_message(message, config?, repo_path?, config_path?)`
108
+ - `validate_branch_name(branch?, config?, repo_path?, config_path?)`
109
+ - `validate_author_info(author_name?, author_email?, config?, repo_path?, config_path?)`
110
+ - `validate_commit_context(message?, branch?, author_name?, author_email?, config?, repo_path?, config_path?)`
111
+ - `validate_repository_state(repo_path?, config?, config_path?, include_message?, include_branch?, include_author?)`
112
+ - `describe_validation_rules(config?, repo_path?, config_path?)`
113
+
114
+ The common optional arguments are:
115
+
116
+ - `repo_path`: repository directory to validate against
117
+ - `config_path`: explicit TOML config file; relative paths resolve from `repo_path`
118
+ - `config`: ad-hoc config overrides merged on top of defaults and repo config
119
+
120
+ ## Common Examples
121
+
122
+ Validate a commit message using repo-local rules:
123
+
124
+ ```json
125
+ {
126
+ "message": "feat(api): add MCP validation tool",
127
+ "repo_path": "/path/to/repo"
128
+ }
129
+ ```
130
+
131
+ Validate the current repository branch using an explicit config file:
132
+
133
+ ```json
134
+ {
135
+ "repo_path": "/path/to/repo",
136
+ "config_path": ".github/commit-check.toml"
137
+ }
138
+ ```
139
+
140
+ Validate the full repository state:
141
+
142
+ ```json
143
+ {
144
+ "repo_path": "/path/to/repo",
145
+ "include_message": true,
146
+ "include_branch": true,
147
+ "include_author": true
148
+ }
149
+ ```
150
+
151
+ Inspect the final merged rules that will be applied:
152
+
153
+ ```json
154
+ {
155
+ "repo_path": "/path/to/repo",
156
+ "config": {
157
+ "commit": {
158
+ "require_body": true
159
+ }
160
+ }
161
+ }
162
+ ```
163
+
164
+ ## Repository-Aware Validation
165
+
166
+ `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:
167
+
168
+ - `repo_path` — run git-based validations against a specific repository
169
+ - `config_path` — point to an explicit TOML config file; relative paths are resolved from `repo_path`
170
+ - `config` — apply ad-hoc overrides on top of defaults and repo config
171
+
172
+ Typical patterns:
173
+
174
+ - Validate an explicit message with a repository's rules
175
+ - Validate the current repository state without passing message/branch/author values manually
176
+ - Inspect which rules are actually enabled after config merging
177
+
178
+ Example payload for a repository-wide validation:
179
+
180
+ ```json
181
+ {
182
+ "repo_path": "/path/to/repo",
183
+ "include_message": true,
184
+ "include_branch": true,
185
+ "include_author": true
186
+ }
187
+ ```
188
+
189
+ Config precedence is:
190
+
191
+ 1. `commit-check` built-in defaults
192
+ 2. repository config loaded from `repo_path`
193
+ 3. `config_path` when explicitly provided
194
+ 4. inline `config` overrides passed to the tool
@@ -19,7 +19,8 @@ dynamic = ["version"]
19
19
 
20
20
  [project.optional-dependencies]
21
21
  dev = [
22
- "pytest>=9.0.0,<10"
22
+ "pytest>=9.0.0,<10",
23
+ "pytest-cov>=6.0.0,<7"
23
24
  ]
24
25
 
25
26
  [project.scripts]
@@ -0,0 +1,210 @@
1
+ Metadata-Version: 2.4
2
+ Name: commit-check-mcp
3
+ Version: 0.1.2
4
+ Summary: MCP server exposing commit-check validation tools
5
+ Author: commit-check
6
+ License: MIT
7
+ Requires-Python: >=3.10
8
+ Description-Content-Type: text/markdown
9
+ License-File: LICENSE
10
+ Requires-Dist: commit-check<3,>=2.5.0
11
+ Requires-Dist: mcp<2,>=1.27.0
12
+ Provides-Extra: dev
13
+ Requires-Dist: pytest<10,>=9.0.0; extra == "dev"
14
+ Requires-Dist: pytest-cov<7,>=6.0.0; extra == "dev"
15
+ Dynamic: license-file
16
+
17
+ # commit-check-mcp
18
+
19
+ [![PyPI version](https://img.shields.io/pypi/v/commit-check-mcp)](https://pypi.org/project/commit-check-mcp/)
20
+ [![Python versions](https://img.shields.io/pypi/pyversions/commit-check-mcp)](https://pypi.org/project/commit-check-mcp/)
21
+ [![Build](https://github.com/commit-check/commit-check-mcp/actions/workflows/main.yml/badge.svg)](https://github.com/commit-check/commit-check-mcp/actions/workflows/main.yml)
22
+ [![Coverage](https://codecov.io/gh/commit-check/commit-check-mcp/graph/badge.svg)](https://codecov.io/gh/commit-check/commit-check-mcp)
23
+ [![MCP server](https://img.shields.io/badge/MCP-server-0A7B83)](https://modelcontextprotocol.io/)
24
+
25
+ Model Context Protocol (MCP) server for [commit-check](https://github.com/commit-check/commit-check).
26
+
27
+ `commit-check-mcp` exposes `commit-check` as local MCP tools so an MCP client can validate commit messages, branch names, author info, and repository state.
28
+
29
+ ## Features
30
+
31
+ This MCP server exposes commit-check validations as MCP tools:
32
+
33
+ - `server_health` — returns server/sdk versions
34
+ - `validate_commit_message` — validates a commit message
35
+ - `validate_branch_name` — validates a branch name or the current repo branch
36
+ - `validate_author_info` — validates author name/email or the repo's git author config
37
+ - `validate_commit_context` — runs combined checks in one call
38
+ - `validate_repository_state` — validates latest commit, current branch, and author state for a repo
39
+ - `describe_validation_rules` — returns the effective config and enabled rules after merging defaults and repo config
40
+
41
+ All validation tools return the same structured commit-check result shape:
42
+
43
+ ```json
44
+ {
45
+ "status": "pass|fail",
46
+ "checks": [
47
+ {
48
+ "check": "message",
49
+ "status": "pass|fail",
50
+ "value": "...",
51
+ "error": "...",
52
+ "suggest": "..."
53
+ }
54
+ ]
55
+ }
56
+ ```
57
+
58
+ ## Installation
59
+
60
+ ```bash
61
+ pip install commit-check-mcp
62
+ ```
63
+
64
+ This installs the `commit-check-mcp` CLI entrypoint.
65
+
66
+ For local development from this repository:
67
+
68
+ ```bash
69
+ pip install -e .
70
+ ```
71
+
72
+ ## Use With An MCP Client
73
+
74
+ 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.
75
+
76
+ Generic MCP client config:
77
+
78
+ ```json
79
+ {
80
+ "mcpServers": {
81
+ "commit-check": {
82
+ "command": "commit-check-mcp"
83
+ }
84
+ }
85
+ }
86
+ ```
87
+
88
+ If the client needs the full path to the executable, first locate it:
89
+
90
+ ```bash
91
+ which commit-check-mcp
92
+ ```
93
+
94
+ Then use that absolute path in the client config.
95
+
96
+ Example using an absolute path:
97
+
98
+ ```json
99
+ {
100
+ "mcpServers": {
101
+ "commit-check": {
102
+ "command": "/absolute/path/to/commit-check-mcp"
103
+ }
104
+ }
105
+ }
106
+ ```
107
+
108
+ For local development from this repository, that absolute path may point to something like `.venv/bin/commit-check-mcp`.
109
+
110
+ ## Run Manually
111
+
112
+ ```bash
113
+ commit-check-mcp
114
+ ```
115
+
116
+ The server uses stdio transport, which is the recommended MCP default for local tool integrations.
117
+
118
+ ## Tool Usage
119
+
120
+ After the client starts the server, it will expose these tools:
121
+
122
+ - `server_health`: returns server, SDK, and dependency versions
123
+ - `validate_commit_message(message, config?, repo_path?, config_path?)`
124
+ - `validate_branch_name(branch?, config?, repo_path?, config_path?)`
125
+ - `validate_author_info(author_name?, author_email?, config?, repo_path?, config_path?)`
126
+ - `validate_commit_context(message?, branch?, author_name?, author_email?, config?, repo_path?, config_path?)`
127
+ - `validate_repository_state(repo_path?, config?, config_path?, include_message?, include_branch?, include_author?)`
128
+ - `describe_validation_rules(config?, repo_path?, config_path?)`
129
+
130
+ The common optional arguments are:
131
+
132
+ - `repo_path`: repository directory to validate against
133
+ - `config_path`: explicit TOML config file; relative paths resolve from `repo_path`
134
+ - `config`: ad-hoc config overrides merged on top of defaults and repo config
135
+
136
+ ## Common Examples
137
+
138
+ Validate a commit message using repo-local rules:
139
+
140
+ ```json
141
+ {
142
+ "message": "feat(api): add MCP validation tool",
143
+ "repo_path": "/path/to/repo"
144
+ }
145
+ ```
146
+
147
+ Validate the current repository branch using an explicit config file:
148
+
149
+ ```json
150
+ {
151
+ "repo_path": "/path/to/repo",
152
+ "config_path": ".github/commit-check.toml"
153
+ }
154
+ ```
155
+
156
+ Validate the full repository state:
157
+
158
+ ```json
159
+ {
160
+ "repo_path": "/path/to/repo",
161
+ "include_message": true,
162
+ "include_branch": true,
163
+ "include_author": true
164
+ }
165
+ ```
166
+
167
+ Inspect the final merged rules that will be applied:
168
+
169
+ ```json
170
+ {
171
+ "repo_path": "/path/to/repo",
172
+ "config": {
173
+ "commit": {
174
+ "require_body": true
175
+ }
176
+ }
177
+ }
178
+ ```
179
+
180
+ ## Repository-Aware Validation
181
+
182
+ `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:
183
+
184
+ - `repo_path` — run git-based validations against a specific repository
185
+ - `config_path` — point to an explicit TOML config file; relative paths are resolved from `repo_path`
186
+ - `config` — apply ad-hoc overrides on top of defaults and repo config
187
+
188
+ Typical patterns:
189
+
190
+ - Validate an explicit message with a repository's rules
191
+ - Validate the current repository state without passing message/branch/author values manually
192
+ - Inspect which rules are actually enabled after config merging
193
+
194
+ Example payload for a repository-wide validation:
195
+
196
+ ```json
197
+ {
198
+ "repo_path": "/path/to/repo",
199
+ "include_message": true,
200
+ "include_branch": true,
201
+ "include_author": true
202
+ }
203
+ ```
204
+
205
+ Config precedence is:
206
+
207
+ 1. `commit-check` built-in defaults
208
+ 2. repository config loaded from `repo_path`
209
+ 3. `config_path` when explicitly provided
210
+ 4. inline `config` overrides passed to the tool
@@ -3,3 +3,4 @@ mcp<2,>=1.27.0
3
3
 
4
4
  [dev]
5
5
  pytest<10,>=9.0.0
6
+ pytest-cov<7,>=6.0.0
@@ -1,22 +0,0 @@
1
- name: PR Autolabeler
2
-
3
- on:
4
- pull_request_target:
5
- types:
6
- - opened
7
- - reopened
8
- - synchronize
9
- - edited
10
-
11
- permissions:
12
- contents: read
13
- pull-requests: write
14
-
15
- jobs:
16
- labeler:
17
- runs-on: ubuntu-24.04
18
- steps:
19
- - uses: actions/labeler@v5
20
- with:
21
- repo-token: ${{ secrets.GITHUB_TOKEN }}
22
- sync-labels: true
@@ -1,86 +0,0 @@
1
- Metadata-Version: 2.4
2
- Name: commit-check-mcp
3
- Version: 0.1.1.post1.dev1
4
- Summary: MCP server exposing commit-check validation tools
5
- Author: commit-check
6
- License: MIT
7
- Requires-Python: >=3.10
8
- Description-Content-Type: text/markdown
9
- License-File: LICENSE
10
- Requires-Dist: commit-check<3,>=2.5.0
11
- Requires-Dist: mcp<2,>=1.27.0
12
- Provides-Extra: dev
13
- Requires-Dist: pytest<10,>=9.0.0; extra == "dev"
14
- Dynamic: license-file
15
-
16
- # commit-check-mcp
17
-
18
- Model Context Protocol (MCP) server for [commit-check](https://github.com/commit-check/commit-check).
19
-
20
- ## Features
21
-
22
- This MCP server exposes commit-check validations as MCP tools:
23
-
24
- - `server_health` — returns server/sdk versions
25
- - `validate_commit_message` — validates a commit message
26
- - `validate_branch_name` — validates a branch name or the current repo branch
27
- - `validate_author_info` — validates author name/email or the repo's git author config
28
- - `validate_commit_context` — runs combined checks in one call
29
- - `validate_repository_state` — validates latest commit, current branch, and author state for a repo
30
- - `describe_validation_rules` — returns the effective config and enabled rules after merging defaults and repo config
31
-
32
- All validation tools return the same structured commit-check result shape:
33
-
34
- ```json
35
- {
36
- "status": "pass|fail",
37
- "checks": [
38
- {
39
- "check": "message",
40
- "status": "pass|fail",
41
- "value": "...",
42
- "error": "...",
43
- "suggest": "..."
44
- }
45
- ]
46
- }
47
- ```
48
-
49
- ## Install
50
-
51
- ```bash
52
- pip install -e .
53
- ```
54
-
55
- ## Run
56
-
57
- ```bash
58
- commit-check-mcp
59
- ```
60
-
61
- The server runs over stdio transport (recommended MCP default for local tool integrations).
62
-
63
- ## Repository-Aware Validation
64
-
65
- `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:
66
-
67
- - `repo_path` — run git-based validations against a specific repository
68
- - `config_path` — point to an explicit TOML config file; relative paths are resolved from `repo_path`
69
- - `config` — apply ad-hoc overrides on top of defaults and repo config
70
-
71
- Typical patterns:
72
-
73
- - Validate an explicit message with a repository's rules
74
- - Validate the current repository state without passing message/branch/author values manually
75
- - Inspect which rules are actually enabled after config merging
76
-
77
- Example payload for a repository-wide validation:
78
-
79
- ```json
80
- {
81
- "repo_path": "/path/to/repo",
82
- "include_message": true,
83
- "include_branch": true,
84
- "include_author": true
85
- }
86
- ```
@@ -1,71 +0,0 @@
1
- # commit-check-mcp
2
-
3
- Model Context Protocol (MCP) server for [commit-check](https://github.com/commit-check/commit-check).
4
-
5
- ## Features
6
-
7
- This MCP server exposes commit-check validations as MCP tools:
8
-
9
- - `server_health` — returns server/sdk versions
10
- - `validate_commit_message` — validates a commit message
11
- - `validate_branch_name` — validates a branch name or the current repo branch
12
- - `validate_author_info` — validates author name/email or the repo's git author config
13
- - `validate_commit_context` — runs combined checks in one call
14
- - `validate_repository_state` — validates latest commit, current branch, and author state for a repo
15
- - `describe_validation_rules` — returns the effective config and enabled rules after merging defaults and repo config
16
-
17
- All validation tools return the same structured commit-check result shape:
18
-
19
- ```json
20
- {
21
- "status": "pass|fail",
22
- "checks": [
23
- {
24
- "check": "message",
25
- "status": "pass|fail",
26
- "value": "...",
27
- "error": "...",
28
- "suggest": "..."
29
- }
30
- ]
31
- }
32
- ```
33
-
34
- ## Install
35
-
36
- ```bash
37
- pip install -e .
38
- ```
39
-
40
- ## Run
41
-
42
- ```bash
43
- commit-check-mcp
44
- ```
45
-
46
- The server runs over stdio transport (recommended MCP default for local tool integrations).
47
-
48
- ## Repository-Aware Validation
49
-
50
- `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:
51
-
52
- - `repo_path` — run git-based validations against a specific repository
53
- - `config_path` — point to an explicit TOML config file; relative paths are resolved from `repo_path`
54
- - `config` — apply ad-hoc overrides on top of defaults and repo config
55
-
56
- Typical patterns:
57
-
58
- - Validate an explicit message with a repository's rules
59
- - Validate the current repository state without passing message/branch/author values manually
60
- - Inspect which rules are actually enabled after config merging
61
-
62
- Example payload for a repository-wide validation:
63
-
64
- ```json
65
- {
66
- "repo_path": "/path/to/repo",
67
- "include_message": true,
68
- "include_branch": true,
69
- "include_author": true
70
- }
71
- ```
@@ -1,86 +0,0 @@
1
- Metadata-Version: 2.4
2
- Name: commit-check-mcp
3
- Version: 0.1.1.post1.dev1
4
- Summary: MCP server exposing commit-check validation tools
5
- Author: commit-check
6
- License: MIT
7
- Requires-Python: >=3.10
8
- Description-Content-Type: text/markdown
9
- License-File: LICENSE
10
- Requires-Dist: commit-check<3,>=2.5.0
11
- Requires-Dist: mcp<2,>=1.27.0
12
- Provides-Extra: dev
13
- Requires-Dist: pytest<10,>=9.0.0; extra == "dev"
14
- Dynamic: license-file
15
-
16
- # commit-check-mcp
17
-
18
- Model Context Protocol (MCP) server for [commit-check](https://github.com/commit-check/commit-check).
19
-
20
- ## Features
21
-
22
- This MCP server exposes commit-check validations as MCP tools:
23
-
24
- - `server_health` — returns server/sdk versions
25
- - `validate_commit_message` — validates a commit message
26
- - `validate_branch_name` — validates a branch name or the current repo branch
27
- - `validate_author_info` — validates author name/email or the repo's git author config
28
- - `validate_commit_context` — runs combined checks in one call
29
- - `validate_repository_state` — validates latest commit, current branch, and author state for a repo
30
- - `describe_validation_rules` — returns the effective config and enabled rules after merging defaults and repo config
31
-
32
- All validation tools return the same structured commit-check result shape:
33
-
34
- ```json
35
- {
36
- "status": "pass|fail",
37
- "checks": [
38
- {
39
- "check": "message",
40
- "status": "pass|fail",
41
- "value": "...",
42
- "error": "...",
43
- "suggest": "..."
44
- }
45
- ]
46
- }
47
- ```
48
-
49
- ## Install
50
-
51
- ```bash
52
- pip install -e .
53
- ```
54
-
55
- ## Run
56
-
57
- ```bash
58
- commit-check-mcp
59
- ```
60
-
61
- The server runs over stdio transport (recommended MCP default for local tool integrations).
62
-
63
- ## Repository-Aware Validation
64
-
65
- `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:
66
-
67
- - `repo_path` — run git-based validations against a specific repository
68
- - `config_path` — point to an explicit TOML config file; relative paths are resolved from `repo_path`
69
- - `config` — apply ad-hoc overrides on top of defaults and repo config
70
-
71
- Typical patterns:
72
-
73
- - Validate an explicit message with a repository's rules
74
- - Validate the current repository state without passing message/branch/author values manually
75
- - Inspect which rules are actually enabled after config merging
76
-
77
- Example payload for a repository-wide validation:
78
-
79
- ```json
80
- {
81
- "repo_path": "/path/to/repo",
82
- "include_message": true,
83
- "include_branch": true,
84
- "include_author": true
85
- }
86
- ```