Which integrations are available for this server?

Provides Docker support for containerized deployment of the Git MCP server with ready-to-use Docker images. Provides comprehensive Git repository management capabilities including cloning, status checks, pulling, pushing, committing, branch operations, history viewing, staging files, repository initialization, and remote repository management. Server is implemented in Node.js, allowing for execution of Git operations through a Model Context Protocol interface with proper error handling and validation. Implements type-safe command execution for Git operations with structured input validation. Uses Zod for schema validation of Git operation commands, ensuring type safety and proper input validation.

How do I use GIT 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 MCP Server clone https://github.com/example/project.git to my local folder" 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 MCP Server

by markheramis

Overview Schema Related Servers Score Discussions

JavaScript

GIT MCP Server

Node.js server implementing Model Context Protocol (MCP) for git operations.

Features

Git repository management through MCP protocol
Support for common Git operations
Type-safe command execution with Zod schema validation
Robust error handling with detailed git error messages
Comprehensive test suite covering all operations

Related MCP server: git-mcp-server

API

The server provides the following Git operations:

git_clone

Clone a git repository to a local directory.

{
    repository: string;    // Git repository URL to clone
    directory?: string;    // Target directory for the repository
    branch?: string;       // Branch to checkout
}

git_status

Get the status of a git repository, showing changed files and branch information.

{
    repository_path: string;  // Path to the git repository
}

git_pull

Pull changes from a remote repository into your local repository.

{
    repository_path: string;  // Path to the git repository
    remote?: string;         // Remote name
    branch?: string;         // Branch name
}

git_push

Push local changes to a remote repository.

{
    repository_path: string;  // Path to the git repository
    remote?: string;         // Remote name
    branch?: string;         // Branch name
}

git_commit

Commit changes to the repository with a message.

{
    repository_path: string;  // Path to the git repository
    message: string;         // Commit message
    add_all?: boolean;       // Add all files before committing
}

git_checkout

Checkout a branch or specific commit.

{
    repository_path: string;  // Path to the git repository
    branch: string;          // Branch or commit to checkout
    create?: boolean;        // Create new branch if it does not exist
}

git_log

Show commit history.

{
    repository_path: string;  // Path to the git repository
    count?: number;          // Number of commits to show
}

git_branch

List all branches in the repository.

{
    repository_path: string;  // Path to the git repository
    show_remote?: boolean;   // Show remote branches as well
}

git_add

Add files to the staging area.

{
    repository_path: string;  // Path to the git repository
    files: string[];         // Files to add to the staging area
}

git_init

Initialize a new git repository.

{
    repository_path: string;  // Path for the new git repository
    bare?: boolean;          // Create a bare repository
}

git_remote

Manage remote repositories.

{
    repository_path: string;  // Path to the git repository
    action: 'add' | 'remove' | 'set-url' | 'list';  // Action to perform on remote
    name?: string;           // Name of the remote
    url?: string;            // URL of the remote repository
}

Error Handling

The server provides robust error handling for git operations:

All git commands are executed with proper error capturing
Error messages are cleaned and formatted for improved readability
Specific git error patterns are detected and extracted from command output
Each tool returns structured error responses with isError: true flag
Errors include descriptive messages that match standard git error formats

Installation

npm install
npm run build

Usage

The server can be run using:

npm start

Or directly using the built executable:

./dist/index.js

Testing

The project includes a comprehensive test suite that verifies all git operations work correctly. To run the tests:

npm test

The tests:

Create a temporary git repository
Test the full git workflow (clone, branch, add, commit, etc.)
Verify proper error handling for invalid operations
Clean up resources after test execution

For continuous test development, you can also use:

npm run test:watch

Docker

A Docker image is available for easy deployment:

docker build -t mcp-git .
docker run mcp-git

Development

npm run dev  # Start development mode with watch
npm run build  # Build the project

Using with Cursor AI Chat

For detailed instructions on using this Git MCP server with Cursor's AI assistant, please see using with cursor.

License

MIT

Available Tools

11 tools

git_addD

ParametersJSON Schema

Name	Required	Description	Default
`repository_path`	Yes	Path to the git repository
`files`	Yes	Files to add to the staging area

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_branchD

ParametersJSON Schema

Name	Required	Description	Default
`repository_path`	Yes	Path to the git repository
`show_remote`	No	Show remote branches as well

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_checkoutD

ParametersJSON Schema

Name	Required	Description
`repository_path`	Yes	Path to the git repository
`branch`	Yes	Branch or commit to checkout
`create`	No	Create new branch if it does not exist

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_cloneD

ParametersJSON Schema

Name	Required	Description
`repository`	Yes	Git repository URL to clone
`directory`	No	Target directory for the repository
`branch`	No	Branch to checkout

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_commitD

ParametersJSON Schema

Name	Required	Description
`repository_path`	Yes	Path to the git repository
`message`	Yes	Commit message
`add_all`	No	Add all files before committing

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_initD

ParametersJSON Schema

Name	Required	Description	Default
`repository_path`	Yes	Path for the new git repository
`bare`	No	Create a bare repository

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_logD

ParametersJSON Schema

Name	Required	Description	Default
`repository_path`	Yes	Path to the git repository
`count`	No	Number of commits to show

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_pullD

ParametersJSON Schema

Name	Required	Description
`repository_path`	Yes	Path to the git repository
`remote`	No	Remote name
`branch`	No	Branch name

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_pushD

ParametersJSON Schema

Name	Required	Description
`repository_path`	Yes	Path to the git repository
`remote`	No	Remote name
`branch`	No	Branch name

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_remoteD

ParametersJSON Schema

Name	Required	Description
`repository_path`	Yes	Path to the git repository
`action`	Yes	Action to perform on remote
`name`	No	Name of the remote
`url`	No	URL of the remote repository

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git_statusD

ParametersJSON Schema

Name	Required	Description	Default
`repository_path`	Yes	Path to the git repository

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

11 tool updatesAug 15, 2025
- First observedgit_add
- First observedgit_branch
- First observedgit_checkout
- First observedgit_clone
- First observedgit_commit
- First observedgit_init
- First observedgit_log
- First observedgit_pull
- First observedgit_push
- First observedgit_remote
- First observedgit_status

Install Server

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

TDQS

C2.1/5.0

Disambiguation5/5

Every tool corresponds to a distinct Git command with well-known, non-overlapping purposes in version control workflows. The lack of descriptions doesn't hinder disambiguation since these are standard Git operations that agents can reliably differentiate based on common knowledge.

Naming Consistency5/5

All tool names follow a perfectly consistent 'git_' prefix with the exact Git command name in lowercase, adhering to a uniform snake_case pattern throughout. This predictability makes it easy for agents to understand and use the toolset without confusion.

Tool Count5/5

With 11 tools, this server covers essential Git operations for basic repository management, which is well-scoped and typical for a Git-focused MCP server. Each tool represents a core Git command that earns its place in the set, avoiding bloat or thin coverage.

Completeness4/5

The toolset provides strong coverage of fundamental Git workflows, including repository setup (init, clone), changes (add, commit, status), branching (branch, checkout), and synchronization (pull, push, remote). Minor gaps exist, such as missing tools for advanced operations like git merge, git rebase, or git stash, but core functionality is well-covered for most agent tasks.

Resources

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
Gluecron B
com.gluecron
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Version Control CI/CD & DevOps Code Analysis
622

Related MCP Servers

git MCP serverofficial
Version Control Developer Tools
modelcontextprotocol
A
license
B
quality
A
maintenance
A Model Context Protocol server for Git repository interaction and automation. This server provides tools to read, search, and manipulate Git repositories via Large Language Models.
Updated 3 days ago (2026-09-03 01:42 UTC)
12
90,042
MIT
git-mcp-server
Developer Tools Version Control
cyanheads
A
license
A
quality
C
maintenance
A Model Context Protocol server that enables Large Language Models to interact with Git repositories through a robust API, supporting operations like repository initialization, cloning, file staging, committing, and branch management.
Updated 12 days ago (2026-08-24 21:58 UTC)
28
7,389
239
Apache 2.0
MCP Git Server
Version Control Developer Tools
martinsky999
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables LLMs to interact with Git repositories, providing tools to read, search, and manipulate Git repositories through commands like status, diff, commit, and branch management.
Updated a year ago (2025-05-28 06:22 UTC)
12
MIT
GitHub MCP Server
Version Control Developer Tools
archish9
A
license
A
quality
D
maintenance
A Model Context Protocol server that provides Git version control operations as structured tools for AI coding agents. It enables LLMs to programmatically manage repositories through actions like committing changes, rolling back code, and comparing diffs.
Updated 7 months ago (2026-02-13 09:59 UTC)
10
Apache 2.0

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

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

GIT MCP Server

Features

API

git_clone

git_status

git_pull

git_push

git_commit

git_checkout

git_log

git_branch

git_add

git_init

git_remote

Error Handling

Installation

Usage

Testing

Docker

Development

Using with Cursor AI Chat

License

Available Tools

Tool Schema Changelog

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

git MCP serverofficial

Latest Blog Posts

MCP directory API