Which integrations are available for this server?

Provides automated Git workflow tools for committing staged changes, pushing to remote repositories, and managing branches with comprehensive error handling and rollback capabilities. Enables automated GitHub operations including creating pull requests, merging PRs with different merge strategies, and managing branch lifecycle with proper authentication handling through GitHub CLI.

How do I use Git Workflow Automation MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Git Workflow Automation MCP Server commit my changes with message 'fix: resolve login bug' and create a PR titled 'Bug Fix: Login Issue'" 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.

Git Workflow Automation MCP Server

by Arcia125

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

Git Workflow Automation MCP Server

A Model Context Protocol (MCP) server that provides automated Git workflow tools for committing, creating pull requests, and merging with proper GitHub authentication handling.

Features

Automated Git Operations: Commit, push, create PRs, and merge in one command
GitHub Authentication Handling: Automatically clears problematic environment tokens
Dry Run Support: Test operations before executing them
Conventional Commits: Supports proper commit message formatting
Branch Management: Automatic branch creation and switching
Error Handling: Comprehensive error reporting and rollback capabilities

Related MCP server: GitHub MCP Server

Available Tools

1. `git_commit_and_push`

Commits staged changes and pushes to remote repository.

Parameters:

files (array, optional): File paths to commit (empty for all changes)
commitMessage (string, required): Commit message (use conventional format)
branch (string, optional): Branch name to create/switch to
workingDir (string, optional): Working directory path
dryRun (boolean, optional): Preview without executing

Example:

use_mcp_tool("git-workflow", "git_commit_and_push", {
  "files": ["src/app.ts", "README.md"],
  "commitMessage": "feat: add new authentication system",
  "branch": "feature/auth-system",
  "dryRun": true
})

2. `create_pull_request`

Creates a GitHub pull request with proper authentication handling.

Parameters:

title (string, required): Pull request title
body (string, required): Pull request description
baseBranch (string, optional): Base branch (default: "main")
headBranch (string, optional): Head branch (defaults to current)
workingDir (string, optional): Working directory path
dryRun (boolean, optional): Preview without executing

Example:

use_mcp_tool("git-workflow", "create_pull_request", {
  "title": "Feature: User Authentication System",
  "body": "Implements comprehensive user authentication with JWT tokens and OAuth2 support",
  "baseBranch": "main",
  "headBranch": "feature/auth-system"
})

3. `merge_pull_request`

Merges a GitHub pull request.

Parameters:

prNumber (string, required): Pull request number
mergeMethod (string, optional): "merge", "squash", or "rebase" (default: "merge")
deleteBranch (boolean, optional): Delete branch after merge (default: true)
workingDir (string, optional): Working directory path
dryRun (boolean, optional): Preview without executing

Example:

use_mcp_tool("git-workflow", "merge_pull_request", {
  "prNumber": "42",
  "mergeMethod": "squash",
  "deleteBranch": true
})

4. `complete_git_workflow`

Executes the complete Git workflow: commit, push, create PR, and optionally merge.

Parameters:

files (array, optional): Files to commit
commitMessage (string, required): Commit message (conventional format)
prTitle (string, required): Pull request title
prBody (string, required): Pull request description
branch (string, optional): Feature branch name
baseBranch (string, optional): Base branch (default: "main")
autoMerge (boolean, optional): Automatically merge PR (default: false)
workingDir (string, optional): Working directory path
dryRun (boolean, optional): Preview without executing

Example:

use_mcp_tool("git-workflow", "complete_git_workflow", {
  "files": ["src/**/*.ts", "docs/**/*.md"],
  "commitMessage": "feat(auth): implement OAuth2 authentication",
  "prTitle": "Feature: OAuth2 Authentication System",
  "prBody": "Adds comprehensive OAuth2 authentication with Google and GitHub providers",
  "branch": "feature/oauth2-auth",
  "autoMerge": false,
  "dryRun": true
})

Installation

Quick Setup

Clone the Repository

git clone https://github.com/Arcia125/git-workflow-mcp-server.git
cd git-workflow-mcp-server

Install Dependencies
```
npm install
```
Build the Server
```
npm run build
```

Add to MCP Configuration

Add the server to your MCP client settings file:

{
  "mcpServers": {
    "git-workflow": {
      "command": "node",
      "args": ["/path/to/git-workflow-mcp-server/build/index.js"],
      "disabled": false,
      "alwaysAllow": [],
      "disabledTools": []
    }
  }
}

Alternative: NPM Global Install (Coming Soon)

Future versions will support global npm installation:

npm install -g git-workflow-mcp-server

Configuration Paths

Common MCP Settings Locations:

Roo-Code: %APPDATA%/Code - Insiders/User/globalStorage/rooveterinaryinc.roo-cline/settings/mcp_settings.json
Claude Desktop: %APPDATA%/Claude/claude_desktop_config.json
Other MCP Clients: Check your client's documentation for settings location

Verify Installation

Test the installation with a dry run:

use_mcp_tool("git-workflow", "git_commit_and_push", {
  "files": ["README.md"],
  "commitMessage": "test: verify MCP server installation",
  "dryRun": true
})

Prerequisites

Node.js installed
Git configured with remote repository
GitHub CLI (gh) installed and authenticated
Proper GitHub repository permissions

Authentication

The server automatically handles GitHub authentication issues by:

Clearing problematic environment tokens (GITHUB_TOKEN, GH_TOKEN)
Using PowerShell commands for reliable token management
Relying on GitHub CLI keyring authentication
Providing detailed error messages for authentication failures

Best Practices

1. Always Use Dry Run First

// Test the operation first
use_mcp_tool("git-workflow", "complete_git_workflow", {
  "commitMessage": "feat: add new feature",
  "prTitle": "New Feature",
  "prBody": "Description",
  "dryRun": true
})

// Then execute after confirmation
use_mcp_tool("git-workflow", "complete_git_workflow", {
  "commitMessage": "feat: add new feature",
  "prTitle": "New Feature",
  "prBody": "Description",
  "dryRun": false
})

2. Use Conventional Commits

// Good commit messages:
"feat(auth): add OAuth2 integration"
"fix(ui): resolve button alignment issue"
"docs(api): update endpoint documentation"
"refactor(utils): simplify date formatting"

3. Meaningful PR Titles and Descriptions

{
  "prTitle": "Feature: OAuth2 Authentication System",
  "prBody": "## Changes\n- Implements OAuth2 with Google/GitHub\n- Adds JWT token management\n- Updates user authentication flow\n\n## Testing\n- All auth tests pass\n- Manual testing completed"
}

Error Handling

The server provides comprehensive error handling:

Git Repository Errors: Validates repository state
Authentication Failures: Handles GitHub CLI auth issues
Network Issues: Provides clear error messages
Branch Conflicts: Manages branch creation/switching
Merge Conflicts: Reports merge issues clearly

Dependencies

@modelcontextprotocol/sdk: MCP server framework
simple-git: Git operations
axios: HTTP requests (if needed)
zod: Schema validation

Development

To modify the server:

Edit src/index.ts
Run npm run build
Restart your MCP client

Support

For issues or questions:

Check GitHub CLI authentication: gh auth status
Verify repository permissions
Review error messages for specific guidance
Test with dry run mode first

Version

Version 0.1.0 - Initial release with core Git workflow automation features.

Available Tools

4 tools

complete_git_workflowA

Execute complete Git workflow: commit, push, create PR, and optionally merge

ParametersJSON Schema

Name	Required	Description	Default
`files`	No	Files to commit
`commitMessage`	Yes	Commit message (conventional format)
`prTitle`	Yes	Pull request title
`prBody`	Yes	Pull request description
`branch`	No	Feature branch name
`baseBranch`	No	Base branch	main
`autoMerge`	No	Automatically merge PR after creation
`workingDir`	No	Working directory path
`dryRun`	No	Preview without executing

TDQS

A3.6/5.0

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. It mentions the sequence of actions (commit, push, create PR, optionally merge) but lacks details on permissions required, error handling, rate limits, or what happens in edge cases (e.g., merge conflicts). This is inadequate for a complex, multi-step tool with potential side effects.

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 that front-loads the core purpose ('Execute complete Git workflow') and lists key actions without unnecessary details. Every word earns its place, 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 (9 parameters, no annotations, no output schema, and multi-step operations), the description is insufficient. It lacks information on return values, error conditions, dependencies, or how it integrates with sibling tools, leaving significant gaps for an AI agent to understand and invoke it 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 already documents all 9 parameters thoroughly. The description adds no additional parameter semantics beyond implying the tool's overall workflow, which doesn't enhance understanding of individual parameters. Baseline 3 is appropriate as the schema does the heavy lifting.

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 tool's purpose with specific verbs (execute, commit, push, create, merge) and resources (Git workflow, PR). It distinguishes from sibling tools by combining multiple operations (commit, push, create PR, merge) that are handled separately by siblings like create_pull_request, git_commit_and_push, and merge_pull_request.

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 mentioning 'complete Git workflow' and 'optionally merge,' suggesting it's for end-to-end operations. However, it doesn't explicitly state when to use this tool versus the sibling tools (e.g., for batch workflows vs. individual steps), nor does it mention prerequisites or exclusions, leaving some ambiguity.

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

create_pull_requestC

Create a GitHub pull request with proper authentication handling

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Pull request title
`body`	Yes	Pull request description
`baseBranch`	No	Base branch (target)	main
`headBranch`	No	Head branch (source, defaults to current branch)
`workingDir`	No	Working directory path
`dryRun`	No	Preview without executing

TDQS

C2.9/5.0

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. It mentions 'proper authentication handling' which hints at auth requirements, but doesn't specify what those requirements are, whether this is a mutating operation, what happens on success/failure, or any rate limits. For a tool that creates GitHub pull requests (a significant write operation), this is inadequate behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point. It's appropriately sized for the tool's complexity, though it could potentially be more structured with additional context about the tool's role in the workflow.

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?

For a tool that creates GitHub pull requests (a significant mutating operation) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens on success/failure, authentication specifics, or how it relates to sibling tools. The mention of 'proper authentication handling' is insufficient given the complexity of the operation.

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?

The input schema has 100% description coverage, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 ('create') and resource ('GitHub pull request'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings like 'merge_pull_request' or explain how it fits within the broader git workflow context.

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 mentions 'proper authentication handling' which implies some context about authentication requirements, but provides no explicit guidance on when to use this tool versus alternatives like 'complete_git_workflow' or 'git_commit_and_push'. There's no mention of prerequisites, sequencing, or when-not-to-use scenarios.

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

git_commit_and_pushC

Commit staged changes and push to remote repository

ParametersJSON Schema

Name	Required	Description
`files`	No	Array of file paths to commit (empty for all changes)
`commitMessage`	Yes	Commit message (use conventional commit format)
`branch`	No	Branch name to create/switch to (optional)
`workingDir`	No	Working directory path (defaults to current directory)
`dryRun`	No	Preview changes without executing

TDQS

C2.9/5.0

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.

merge_pull_requestC

Merge a GitHub pull request

ParametersJSON Schema

Name	Required	Description	Default
`prNumber`	Yes	Pull request number
`mergeMethod`	No	Merge method	merge
`deleteBranch`	No	Delete branch after merge
`workingDir`	No	Working directory path
`dryRun`	No	Preview without executing

TDQS

C2.9/5.0

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. While 'Merge' implies a write/mutation operation, the description doesn't mention important behavioral aspects: whether this requires specific permissions, what happens on failure, if it's reversible, or any rate limits. The description is minimal and doesn't compensate for the lack of annotations.

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 maximally concise - a single sentence that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. It's appropriately sized for a tool with a clear, singular function.

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?

For a mutation tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what happens after merging, what the tool returns, error conditions, or important behavioral constraints. The combination of being a write operation with multiple parameters and no structured safety information requires more descriptive context than provided.

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 all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. This meets the baseline expectation when the schema does the heavy lifting, but doesn't provide extra context about parameter interactions or usage patterns.

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 'Merge a GitHub pull request' clearly states the verb ('Merge') and resource ('GitHub pull request'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'complete_git_workflow' or 'create_pull_request' - it's clear what it does but not how it's distinct from related 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. There's no mention of prerequisites (like having a pull request ready to merge), when not to use it (e.g., if there are merge conflicts), or how it relates to sibling tools like 'complete_git_workflow' which might encompass merging as part of a larger workflow.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesAug 15, 2025
- First observedcomplete_git_workflow
- First observedcreate_pull_request
- First observedgit_commit_and_push
- First observedmerge_pull_request

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0

Disambiguation2/5

Multiple tools have overlapping purposes that could cause confusion. The 'complete_git_workflow' tool appears to encompass functionality of both 'git_commit_and_push' and 'create_pull_request', making it unclear when to use which tool. While 'merge_pull_request' is distinct, the boundaries between the other three tools are poorly defined.

Naming Consistency3/5

The naming conventions are mixed with no clear pattern. 'complete_git_workflow' uses a descriptive phrase format, 'create_pull_request' and 'merge_pull_request' follow a verb_noun pattern, and 'git_commit_and_push' uses a compound verb format. While all names are readable, the inconsistency in structure creates a disjointed feel.

Tool Count2/5

With only 4 tools, this server feels significantly under-scoped for Git workflow automation. A proper Git workflow server would typically need tools for staging changes, checking status, branching, reviewing PRs, and handling conflicts. The current set is too thin to support comprehensive workflow automation.

Completeness2/5

There are significant gaps in the Git workflow coverage. Missing are essential operations like staging changes, creating/checking out branches, viewing repository status, reviewing/commenting on PRs, and handling merge conflicts. The server provides only endpoint operations without the supporting tools needed for a complete workflow.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

github
com.mcparmory
Manage repositories, users, releases, and automate GitHub workflows
Version Control CI/CD & DevOps Developer Tools
2
GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,723
ShipstarOAuth
ai.shipstar
Generate and publish changelogs, blog posts, release emails, and social posts from your commits.
Developer Tools CI/CD & DevOps Marketing
1
smithery-ai-github
ai.smithery
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Version Control Developer Tools CI/CD & DevOps
295

Related MCP Servers

Git Workflow MCP Server
Version Control Developer Tools
archis17
F
license
Not graded
quality
Not graded
maintenance
Enables AI assistants to interact with local Git repositories for operations like status, commits, branching, and diffs, plus GitHub API integration for managing pull requests when authenticated.
Updated 9 months ago (2025-11-26 09:44 UTC)
-
GitHub MCP Server
Version Control CI/CD & DevOps
maheshjagzap123
F
license
Not graded
quality
D
maintenance
Exposes GitHub actions as tools for creating branches, pushing files, opening and merging pull requests.
Updated 4 months ago (2026-05-14 10:31 UTC)
-
Git Commit MCP Server
Version Control Developer Tools
surajfale
A
license
A
quality
D
maintenance
Enables AI assistants to create conventional Git commits, update changelogs, and optionally push changes to remote repositories.
Updated 9 months ago (2025-11-23 22:03 UTC)
2
2
MIT
Git MCP Server
Version Control Developer Tools
rriesco
A
license
A
quality
C
maintenance
Enables local git operations including commit, branch, push, pull, status, and sync with conventional commit enforcement and branch naming conventions.
Updated 7 months ago (2026-02-01 18:37 UTC)
6
MIT

Appeared in Searches

DevOps tools and practices including CI/CD pipelines, GitOps, and DevSecOps

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

Git Workflow Automation MCP Server

Features

Available Tools

1. git_commit_and_push

2. create_pull_request

3. merge_pull_request

4. complete_git_workflow

Installation

Quick Setup

Alternative: NPM Global Install (Coming Soon)

Configuration Paths

Verify Installation

Prerequisites

Authentication

Best Practices

1. Always Use Dry Run First

2. Use Conventional Commits

3. Meaningful PR Titles and Descriptions

Error Handling

Dependencies

Development

Support

Version

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `git_commit_and_push`

2. `create_pull_request`

3. `merge_pull_request`

4. `complete_git_workflow`