Skip to main content
Glama
theoklitosBam7

MCP Git Commit Generator

check_git_status

Check current Git repository status to identify staged, unstaged, and untracked files before committing changes.

Instructions

Check the current git repository status.

Args: repo_path: Optional path to the target git repository. If not provided, uses the current working directory.

Returns: Current git status including staged, unstaged, and untracked files

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repo_pathNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The primary handler function for the 'check_git_status' MCP tool. Decorated with @mcp.tool() for automatic registration. Validates repo, fetches git status and branch, parses changes, and formats a user-friendly summary of staged, unstaged, and untracked files.
    @mcp.tool()
    def check_git_status(repo_path: Optional[str] = None) -> str:
        """
        Check the current git repository status.
    
        Args:
            repo_path: Optional path to the target git repository. If not provided, uses the current working directory.
    
        Returns:
            Current git status including staged, unstaged, and untracked files
        """
        try:
            valid_repo_path = _get_valid_repo_path(repo_path)
            if not valid_repo_path:
                return f"Path '{repo_path or os.getcwd()}' is not a valid git repository."
            cwd = valid_repo_path
            # Get full git status
            status_result = subprocess.run(
                ["git", "status", "--porcelain"],
                capture_output=True,
                text=True,
                check=True,
                cwd=cwd,
            )
    
            # Get branch info
            branch_result = subprocess.run(
                ["git", "branch", "--show-current"],
                capture_output=True,
                text=True,
                check=True,
                cwd=cwd,
            )
    
            current_branch = branch_result.stdout.strip()
    
            if not status_result.stdout.strip():
                return f"Repository is clean on branch '{current_branch}'. No changes to commit."
    
            # Parse status using helper
            status_lines = [line for line in status_result.stdout.split("\n") if line]
            staged_files, unstaged_files, untracked_files = _parse_git_status_lines(
                status_lines
            )
    
            status_summary = f"Current branch: {current_branch}\n\n"
    
            if staged_files:
                status_summary += "Staged files (ready to commit):\n"
                status_summary += "\n".join(f"  {file}" for file in staged_files)
                status_summary += "\n\n"
    
            if unstaged_files:
                status_summary += "Unstaged files (need to be added):\n"
                status_summary += "\n".join(f"  {file}" for file in unstaged_files)
                status_summary += "\n\n"
    
            if untracked_files:
                status_summary += "Untracked files:\n"
                status_summary += "\n".join(f"  {file}" for file in untracked_files)
                status_summary += "\n\n"
    
            if staged_files:
                status_summary += "✓ Ready to generate commit message!"
            else:
                status_summary += (
                    "ℹ Stage some files with 'git add' to generate commit messages."
                )
    
            return status_summary
    
        except subprocess.CalledProcessError as e:
            error_msg = e.stderr or e.stdout or str(e)
            return f"Git command failed: {error_msg}"
        except FileNotFoundError:
            return "Git is not installed or not found in PATH"
        except OSError as e:
            return f"OS error occurred: {str(e)}"
  • Helper function to resolve and validate the git repository path from optional input or CWD. Used by check_git_status to ensure a valid repo before running git commands.
    def _get_valid_repo_path(repo_path: Optional[str]) -> Optional[str]:
        """
        Resolve and validate the git repository path.
        Returns the valid repo path if valid, otherwise None.
        """
        logger = logging.getLogger(__name__)
        # Resolve user tilde and symlinks to a canonical path
        resolved = (
            os.path.realpath(os.path.expanduser(repo_path)) if repo_path else os.getcwd()
        )
        logger.info("[get_valid_repo_path] Resolved repository path: %s", resolved)
        if not os.path.isdir(resolved) or not os.path.exists(
            os.path.join(resolved, ".git")
        ):
            return None
        return resolved
  • Parses a single line from 'git status --porcelain' output to categorize files as staged, unstaged, or untracked.
    def _parse_git_status_line(line):
        """
        Helper to parse a single git status line.
        Returns (staged_file, unstaged_file, untracked_file)
        """
        if len(line) < 3:
            return None, None, None
        staged_status = line[0]
        unstaged_status = line[1]
        filename = line[3:]
        if staged_status == "?" and unstaged_status == "?":
            return None, None, filename
        staged_file = filename if staged_status != " " else None
        unstaged_file = filename if unstaged_status != " " else None
        return staged_file, unstaged_file, None
  • Processes multiple git status lines, aggregating files into lists for staged, unstaged, and untracked categories using _parse_git_status_line.
    def _parse_git_status_lines(status_lines):
        staged_files = []
        unstaged_files = []
        untracked_files = []
        for line in status_lines:
            staged_file, unstaged_file, untracked_file = _parse_git_status_line(line)
            if staged_file:
                staged_files.append(staged_file)
            if unstaged_file:
                unstaged_files.append(unstaged_file)
            if untracked_file:
                untracked_files.append(untracked_file)
        return staged_files, unstaged_files, untracked_files
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it states what the tool returns, it doesn't mention potential errors (e.g., if repo_path is invalid), performance characteristics, or any side effects. The description is minimal beyond basic functionality.

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 perfectly structured with a clear purpose statement followed by well-organized Args and Returns sections. Every sentence earns its place, and information is front-loaded appropriately.

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 the simple nature of this read-only tool with one optional parameter and an output schema, the description is reasonably complete. It explains the parameter behavior and return content, though could benefit from more behavioral context about error cases or limitations.

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 description coverage, the description fully compensates by explaining the repo_path parameter's purpose and default behavior. It clarifies that the parameter is optional and specifies what happens when not provided, adding meaningful context beyond the bare 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 specific action ('Check') and resource ('current git repository status'), distinguishing it from the sibling tool 'generate_commit_message' which has a different purpose. It provides a complete picture of what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through the optional repo_path parameter, suggesting it can be used for any git repository. However, it doesn't explicitly state when to use this tool versus alternatives or provide any exclusion criteria.

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/theoklitosBam7/mcp-git-commit-generator'

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