Skip to main content
Glama
jolfr

Commit Helper MCP

by jolfr

preview_git_commit

Preview git commit operations in dry-run mode to validate messages and review files before committing changes to a repository.

Instructions

Preview git commit operation without executing (dry-run mode).

Args: message: Commit message to preview repo_path: Path to git repository stage_all: Whether to stage all changes before commit (not implemented yet) sign_off: Whether to add sign-off to commit (default: True)

Returns: Dict containing: - message: The commit message - is_valid: Whether message passes validation - files_to_commit: List of files that would be committed - dry_run: Always True for this tool - repository_status: Current repository state

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYes
repo_pathYes
stage_allNo
sign_offNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function for the 'preview_git_commit' MCP tool. It performs a dry-run preview of a git commit operation using the CommitzenService, including validation and status reporting.
    @mcp.tool()
    @handle_errors(log_errors=True)
    def preview_git_commit(
        message: str, repo_path: str, stage_all: bool = False, sign_off: bool = True
    ) -> Dict[str, Any]:
        """
        Preview git commit operation without executing (dry-run mode).
    
        Args:
            message: Commit message to preview
            repo_path: Path to git repository
            stage_all: Whether to stage all changes before commit (not implemented yet)
            sign_off: Whether to add sign-off to commit (default: True)
    
        Returns:
            Dict containing:
            - message: The commit message
            - is_valid: Whether message passes validation
            - files_to_commit: List of files that would be committed
            - dry_run: Always True for this tool
            - repository_status: Current repository state
        """
        # For backward compatibility with tests expecting git_enabled field
        try:
            # Initialize service for the specified repository
            try:
                target_service = CommitzenService(repo_path=repo_path)
            except Exception as e:
                return {
                    "git_enabled": False,
                    "error": f"Failed to initialize service for repository '{repo_path}': {e}",
                    "message": message,
                    "dry_run": True,
                    "repository_path": repo_path,
                }
    
            if not target_service.git_enabled:
                return {
                    "git_enabled": False,
                    "error": "Git operations not available - not in a git repository",
                    "message": message,
                    "dry_run": True,
                    "repository_path": repo_path,
                }
    
            # Get preview from service
            preview_result = target_service.preview_commit_operation(
                message, sign_off=sign_off
            )
    
            if "error" in preview_result:
                return {
                    "git_enabled": True,
                    "error": preview_result["error"],
                    "message": message,
                    "dry_run": True,
                    "repository_path": repo_path,
                }
    
            git_preview = preview_result.get("git_preview", {})
    
            return {
                "git_enabled": True,
                "message": message,
                "is_valid": preview_result.get("is_valid", False),
                "files_to_commit": git_preview.get("staged_files", []),
                "staged_files_count": git_preview.get("staged_files_count", 0),
                "would_execute": git_preview.get("would_execute", False),
                "dry_run": True,
                "repository_status": git_preview,
                "repository_path": git_preview.get("repository_path"),
                "success": True,
            }
    
        except Exception as e:
            logger.error(f"Failed to preview git commit: {e}")
            return {
                "git_enabled": False,
                "error": str(e),
                "message": message,
                "dry_run": True,
                "repository_path": repo_path,
                "success": False,
            }
  • Import of git_tools module in mcp_server.py, which registers the preview_git_commit tool via its @mcp.tool() decorator.
    from .server import git_tools
  • Explicit export of preview_git_commit in __all__ list in mcp_server.py for backward compatibility.
    "preview_git_commit",
    "execute_git_commit",
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 clearly discloses key behavioral traits: it's a non-executing preview ('dry-run mode'), mentions that 'stage_all' is 'not implemented yet', and describes the return structure. This adds valuable context beyond basic functionality, though it could detail more about validation rules or error handling.

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 well-structured and front-loaded with the core purpose in the first sentence. It efficiently uses bullet points for Args and Returns, with each sentence adding clear value—no wasted words. The format enhances readability and quick comprehension.

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 moderate complexity, no annotations, and an output schema that details return values, the description is complete enough. It covers purpose, parameters, and behavioral context (e.g., dry-run, unimplemented feature), aligning well with the structured data to provide a holistic understanding without redundancy.

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 description coverage is 0%, so the description must compensate. It adds meaningful semantics for all parameters: explains 'message' as the commit message, 'repo_path' as the repository path, notes 'stage_all' is not implemented, and clarifies 'sign_off' default and purpose. This goes beyond the schema's basic titles, though it could provide more on parameter interactions or constraints.

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 specific action: 'Preview git commit operation without executing (dry-run mode).' It explicitly distinguishes this from actual execution tools like 'execute_git_commit' among siblings, making the purpose distinct and unambiguous.

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 implies usage context by specifying it's a 'dry-run mode' for previewing commits, which suggests it should be used before actual commits. However, it does not explicitly state when to use this tool versus alternatives like 'execute_git_commit' or other sibling tools, leaving some guidance implicit rather than explicit.

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

Install Server

Other Tools

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/jolfr/commit-helper-mcp'

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