Skip to main content
Glama
MementoRC

MCP Git Server

by MementoRC

git_checkout

Switch to a specified branch in a Git repository by providing the repo path and branch name. Enables efficient branch management and context switching for streamlined development workflows.

Instructions

Switches branches

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
branch_nameYes
repo_pathYes

Implementation Reference

  • Core handler function that performs git checkout: switches to local branch if exists, or creates tracking branch from remote if available.
    def git_checkout(repo: Repo, branch_name: str) -> str:
        """Switch to a branch"""
        try:
            # Check if branch exists locally
            local_branches = [branch.name for branch in repo.branches]
    
            if branch_name in local_branches:
                # Switch to local branch
                repo.git.checkout(branch_name)
                return f"✅ Switched to branch '{branch_name}'"
            else:
                # Check if branch exists on remote
                try:
                    remote_branches = [
                        ref.name.split("/")[-1] for ref in repo.remote().refs
                    ]
                    if branch_name in remote_branches:
                        # Create local tracking branch
                        repo.git.checkout("-b", branch_name, f"origin/{branch_name}")
                        return f"✅ Created and switched to branch '{branch_name}' (tracking origin/{branch_name})"
                    else:
                        return f"❌ Branch '{branch_name}' not found locally or on remote"
                except Exception:
                    return f"❌ Branch '{branch_name}' not found"
    
        except GitCommandError as e:
            return f"❌ Checkout failed: {str(e)}"
        except Exception as e:
            return f"❌ Checkout error: {str(e)}"
  • Pydantic schema/model defining input parameters: repo_path and branch_name.
    class GitCheckout(BaseModel):
        repo_path: str
        branch_name: str
  • Tool registration in the git handlers dictionary, wrapping the core git_checkout function with error handling and repo creation.
    "git_checkout": self._create_git_handler(
        git_checkout, requires_repo=True, extra_args=["branch_name"]
    ),
  • Tool definition registration in the central ToolRegistry with schema and metadata.
    ToolDefinition(
        name=GitTools.CHECKOUT,
        category=ToolCategory.GIT,
        description="Switch branches",
        schema=GitCheckout,
        handler=placeholder_handler,
        requires_repo=True,
    ),
  • Protected wrapper that adds repository binding validation before calling the core git_checkout.
    async def protected_git_checkout(self, repo_path: str, branch_name: str) -> str:
        """Git checkout with repository binding protection."""
        validated_path = await self._validate_and_prepare_operation(repo_path)
        repo = Repo(validated_path)
        return git_checkout(repo, branch_name)
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Switches branches' implies a mutation operation, but it doesn't disclose critical traits like whether it requires a clean working directory, what happens to uncommitted changes, or if it can create new branches. This leaves significant gaps in understanding the tool's behavior and risks.

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 extremely concise with just two words, front-loaded and zero waste. Every word earns its place, making it efficient for quick scanning, though this brevity contributes to gaps in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (mutation operation with 2 parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on behavior, parameters, and output, failing to provide enough context for safe and effective use.

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

Parameters2/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 for undocumented parameters. It adds no meaning beyond the schema—it doesn't explain what 'branch_name' and 'repo_path' represent, their formats, or constraints. For a tool with 2 parameters and no schema descriptions, this is inadequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Switches branches' states a clear verb ('switches') and resource ('branches'), but it's vague about scope and doesn't differentiate from siblings like git_create_branch or git_reset. It doesn't specify if this only switches existing branches or can create new ones, leaving the purpose somewhat ambiguous.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing branch), exclusions (e.g., not for creating branches), or compare to siblings like git_create_branch for branch creation or git_reset for undoing changes. Usage is implied but not explicitly stated.

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

Related 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/MementoRC/mcp-git'

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