This MCP server validates and formats Git commit messages and branch names per the Udacity Git Commit Message Style Guide.
Validate commit messages (validate_commit_message): checks a full message for compliance (type prefix, subject ≤50 chars, capitalization, no trailing period, blank line after subject, body wrap ≤72 chars). Returns validity status with lists of problems and warnings.
Format commit messages (format_commit_message): auto-composes a compliant message from type (feat, fix, docs, style, refactor, test, chore), subject, optional body, footer. Capitalizes subject, removes trailing period, wraps body at 72 chars.
Validate branch names (validate_branch_name): checks against type/kebab-case convention (e.g., feat/add-dark-mode), allows release/* with version descriptions, exempts base branches (main).
Access style guides: provides markdown resources for commit rules (udacity://commit-styleguide) and branch naming (udacity://branch-naming).
Integrate with Claude: add as an MCP server via claude mcp add or Claude Desktop config for automated checks and formatting.
Validates and formats git commit messages according to the Udacity Git Commit Message Style Guide.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-udacity-commit Validate this commit message: 'fixed the bug'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that validates and formats git commit messages according to the Udacity Git Commit Message Style Guide.
One line — paste it into your terminal:
claude mcp add udacity-commit -- npx -y mcp-udacity-commitFor Claude Desktop, add to claude_desktop_config.json:
{
"mcpServers": {
"udacity-commit": {
"command": "npx",
"args": ["-y", "mcp-udacity-commit"]
}
}
}git clone https://github.com/qwertymuzaffar/mcp-udacity-commit
cd mcp-udacity-commit
npm install
npm run build
claude mcp add udacity-commit -- node "$(pwd)/build/index.js"Related MCP server: Cursor Auto-Review MCP Server
Primitive | Name | Purpose |
Resource |
| The style-guide rules, as markdown |
Resource |
| The companion |
Tool |
| Checks a message against every rule (type, ≤50-char subject, capitalization, no trailing period, blank line, ≤72-char body wrap) |
Tool |
| Builds a compliant message from |
Tool |
| Checks a branch name against the companion |
format_commit_message turns loose parts into a compliant commit:
in: type=fix subject="prevent duplicate auth token refresh."
body="The refresh timer could fire twice under load, minting two tokens…"
footer="Resolves: #142"
out:
fix: Prevent duplicate auth token refresh
The refresh timer could fire twice under load, minting two tokens and
logging the user out. Serialize refreshes behind a single in-flight
promise so concurrent callers await the same request.
Resolves: #142validate_commit_message flags every violation:
"Fixed the login bug." → ❌ Not compliant.
• Subject must follow "type: Subject".
• Subject must not end with a period.validate_branch_name enforces the companion type/kebab-case convention:
"feat/add-dark-mode" → ✅ Compliant branch name.
"release/1.2.0" → ✅ Compliant branch name.
"Feature/Add_Dark_Mode" → ❌ Not compliant.
• Unknown type "Feature". Use one of: feat, fix, docs, style, refactor, test, chore, release.
• Description must be lowercase kebab-case. Got: "Add_Dark_Mode".
"main" → ✅ (base branch — feature-branch rules don't apply)npm install
npm run build # → build/index.js
npm run test:client # spawns the server and exercises the toolsMIT
Compose a compliant commit message from its parts. The subject is capitalized, a trailing period is removed, and the body is wrapped at 72 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | What & why; auto-wrapped at 72 chars | |
| type | Yes | ||
| footer | No | Issue refs, e.g. "Resolves: #123" | |
| subject | Yes | Imperative subject; auto-capitalized, trailing period removed |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| message | Yes | |
| problems | Yes | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses formatting behaviors (capitalization, period removal, body wrapping) but omits other behavioral details such as handling of missing optional fields, error conditions, or whether existing formatting is overridden. With no annotations, the description should cover more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no unnecessary words. It front-loads the main purpose and efficiently communicates the key formatting rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (likely describing the formatted string), the description need not cover returns. It adequately explains input formatting, though it could mention that type must be from the enum. Still, it is mostly complete for its simple task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by explaining that subject is auto-capitalized and trailing period removed, and body is auto-wrapped. Schema description coverage is 75%, so the baseline is 3; the extra semantics raise it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes a Udacity-style commit message from parts, specifying key formatting actions (capitalization, period removal, wrapping). It distinctively contrasts with the sibling validate_commit_message by focusing on composition rather than validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when or when-not to use this tool versus the sibling. The purpose is clear, but no alternatives or exclusions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a git branch name against the companion type/kebab-case convention (e.g. "feat/add-dark-mode"). Returns whether it is compliant plus any problems (violations) and warnings (hints). Base branches like main/master are exempt.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The branch name to check, e.g. "feat/add-dark-mode" |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| problems | Yes | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does a good job: it discloses the return format (compliant, problems, warnings) and the base branch exemption. It does not mention that this is a read-only operation, but the verb 'Check' and the nature of validation make that evident. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core verb and resource, and every sentence adds value. The example and return behavior are condensed effectively with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter validation tool with an output schema, the description covers purpose, compliance criteria, return contents, and exceptions. It doesn't spell out what 'kebab-case' means, but the example is sufficient. Overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for 'name', but the tool description adds extra meaning by explaining the convention and giving an example ('feat/add-dark-mode'), which helps the agent understand what values are appropriate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and a clear resource 'git branch name', and identifies the exact convention being validated. It naturally distinguishes itself from sibling tools that deal with commit messages (validate_commit_message, format_commit_message).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is the tool to use for branch name validation against the companion convention, and mentions base branch exceptions. However, it does not explicitly state when to avoid it or name alternative tools for similar tasks, though the sibling context makes the domain distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a commit message against the Udacity Git Commit Message Style Guide. Returns whether it is compliant plus any problems (violations) and warnings (hints).
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The full commit message to check |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| problems | Yes | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses returns: compliance status, problems (violations), warnings (hints). With no annotations, this is adequate but fails to mention side-effects (likely none) or response structure beyond vague categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, output schema exists), description adequately conveys purpose and returns. Missing explicit mention that output structure is defined by schema, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with description 'The full commit message to check'. Tool description adds no additional semantic detail beyond schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'check a commit message against the Udacity Git Commit Message Style Guide', specifying verb and resource. Sibling tool 'format_commit_message' suggests different operation, but no direct differentiation is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., format_commit_message). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.2validate_branch_namev1.0.2format_commit_messagevalidate_commit_messageEach tool targets a distinct aspect of commit conventions: branch name validation, commit message validation, and commit message formatting. There is no overlap in their purposes, making selection unambiguous.
All tool names follow the same verb_noun pattern: validate_branch_name, validate_commit_message, format_commit_message. This consistency makes the toolset predictable and easy to navigate.
With only 3 tools, the server is tightly scoped to its purpose of enforcing Udacity commit guidelines. Each tool earns its place, and the count is neither too thin nor overly heavy.
The server covers the full lifecycle of commit standard compliance: validating branch names, validating commit messages, and formatting commit messages. There are no obvious gaps in the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
A basic MCP server to operate on the Postman API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/qwertymuzaffar/mcp-udacity-commit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server