Skip to main content
Glama
Arcia125

Git Workflow Automation MCP Server

by Arcia125

git_commit_and_push

Commit staged changes to Git with a message and push to remote repository. Supports file selection, branch management, and preview mode.

Instructions

Commit staged changes and push to remote repository

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNoArray of file paths to commit (empty for all changes)
commitMessageYesCommit message (use conventional commit format)
branchNoBranch name to create/switch to (optional)
workingDirNoWorking directory path (defaults to current directory)
dryRunNoPreview changes without executing

Implementation Reference

  • The main handler function that executes the git commit and push logic. Uses simple-git to check repo, handle branches, add files, commit with message, and push to origin.
    async function commitAndPush(
      files: string[],
      commitMessage: string,
      branch?: string,
      workingDir?: string,
      dryRun: boolean = false
    ): Promise<WorkflowResult> {
      try {
        const git = getGit(workingDir);
    
        if (dryRun) {
          return {
            success: true,
            message: "Dry run: Would commit and push changes",
            details: {
              files,
              commitMessage,
              branch,
              workingDir
            }
          };
        }
    
        // Check if we're in a git repository
        const isRepo = await git.checkIsRepo();
        if (!isRepo) {
          return {
            success: false,
            message: "Failed to commit and push",
            error: "Not a Git repository"
          };
        }
    
        // Get current status
        const status = await git.status();
    
        // Create branch if specified and doesn't exist
        if (branch) {
          try {
            await git.checkoutBranch(branch, 'HEAD');
          } catch (error) {
            // Branch might already exist, try to switch to it
            try {
              await git.checkout(branch);
            } catch (switchError) {
              return {
                success: false,
                message: "Failed to commit and push",
                error: `Failed to create or switch to branch ${branch}: ${switchError}`
              };
            }
          }
        }
    
        // Add specified files
        if (files.length > 0) {
          await git.add(files);
        } else {
          // Add all modified files if no specific files provided
          await git.add('.');
        }
    
        // Commit changes
        const commitResult = await git.commit(commitMessage);
    
        // Push changes
        const currentBranch = await git.revparse(['--abbrev-ref', 'HEAD']);
        await git.push('origin', currentBranch);
    
        return {
          success: true,
          message: "Successfully committed and pushed changes",
          details: {
            commit: commitResult.commit,
            branch: currentBranch,
            files: commitResult.summary.changes,
            insertions: commitResult.summary.insertions,
            deletions: commitResult.summary.deletions
          }
        };
      } catch (error: any) {
        return {
          success: false,
          message: "Failed to commit and push",
          error: error.message
        };
      }
    }
  • Input schema definition for the git_commit_and_push tool, specifying parameters like files, commitMessage (required), branch, workingDir, and dryRun.
    inputSchema: {
      type: "object",
      properties: {
        files: {
          type: "array",
          items: { type: "string" },
          description: "Array of file paths to commit (empty for all changes)"
        },
        commitMessage: {
          type: "string",
          description: "Commit message (use conventional commit format)"
        },
        branch: {
          type: "string",
          description: "Branch name to create/switch to (optional)"
        },
        workingDir: {
          type: "string",
          description: "Working directory path (defaults to current directory)"
        },
        dryRun: {
          type: "boolean",
          description: "Preview changes without executing",
          default: false
        }
      },
      required: ["commitMessage"]
    }
  • src/index.ts:585-593 (registration)
    Registration in the tool dispatcher switch statement, mapping the tool name to the commitAndPush handler function call.
    case "git_commit_and_push":
      result = await commitAndPush(
        (args?.files as string[]) || [],
        args?.commitMessage as string,
        args?.branch as string,
        args?.workingDir as string,
        (args?.dryRun as boolean) || false
      );
      break;
  • src/index.ts:419-450 (registration)
    Tool registration in the ListTools response, including name, description, and input schema.
    {
      name: "git_commit_and_push",
      description: "Commit staged changes and push to remote repository",
      inputSchema: {
        type: "object",
        properties: {
          files: {
            type: "array",
            items: { type: "string" },
            description: "Array of file paths to commit (empty for all changes)"
          },
          commitMessage: {
            type: "string",
            description: "Commit message (use conventional commit format)"
          },
          branch: {
            type: "string",
            description: "Branch name to create/switch to (optional)"
          },
          workingDir: {
            type: "string",
            description: "Working directory path (defaults to current directory)"
          },
          dryRun: {
            type: "boolean",
            description: "Preview changes without executing",
            default: false
          }
        },
        required: ["commitMessage"]
      }
    },
  • Helper function to get a SimpleGit instance for the specified working directory, used in the handler.
    function getGit(workingDir?: string): SimpleGit {
      return simpleGit(workingDir || process.cwd());
    }
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. It mentions the action ('commit and push') but fails to describe critical traits such as permission requirements, potential side effects (e.g., overwriting remote changes), error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.

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 a single, efficient sentence with zero waste. It front-loads the core purpose ('commit staged changes and push to remote repository') without unnecessary elaboration, making it highly concise and well-structured.

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 (a mutation operation with 5 parameters), lack of annotations, and no output schema, the description is incomplete. It omits behavioral details, usage context, and output expectations, leaving significant gaps for an AI agent to understand and invoke the tool correctly.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide usage examples). Baseline 3 is appropriate when the schema handles parameter documentation effectively.

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

Purpose4/5

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

The description clearly states the action ('commit and push') and resource ('staged changes to remote repository'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'complete_git_workflow' or 'create_pull_request', which might handle similar git operations.

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?

The description provides no guidance on when to use this tool versus alternatives like 'complete_git_workflow' or 'create_pull_request'. It lacks context about prerequisites (e.g., staged changes), exclusions, or comparisons with sibling tools, leaving usage decisions ambiguous.

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/Arcia125/git-workflow-mcp-server'

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