What can you do with this server?

This MCP server provides Git repository analysis tools for AI assistants, enabling diff generation, commit history extraction, and pull request description creation. Core Features: * Compare branches or commits - Get detailed diffs between HEAD and any ancestor branch or commit * Review staged changes - View differences between staged files and HEAD * Extract commit history - Retrieve commit messages between any ancestor and HEAD * Generate PR descriptions - Automatically create pull request descriptions based on diffs and commit history * Filter diff output - Exclude specific files and directories using pattern matching * Flexible output formats - View results in JSON or text format * Environment-based configuration - Configure repository path, excludes, and output format via environment variables * MCP integration - Works with MCP-compatible clients like Zed editor through standardized tools and commands

Which integrations are available for this server?

Provides tools for generating prompts based on Git repository content, including the ability to generate PR descriptions by comparing differences between branches or commits.

How do I use Git Prompts 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 Prompts MCP Server generate a PR description from my changes compared to main" 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.

en es ja ko zh

Git Prompts MCP Server

by ceshine

Overview Schema Related Servers Score Discussions

Python

Local

Git Prompts MCP Server

This repository provides a Model Context Protocol (MCP) server that offers several commands to generate prompts based on the Git repository's content.

Tests

Acknowledgements

This repository draws heavy inspiration from MarkItDown MCP server and the example Git MCP server.
The AGENTS.md was adapted from the example in this blog post: Getting Good Results from Claude Code.

Related MCP server: GitHub MCP Server

Usage

Prerequisites: Python 3.12+ and uv

As a MCP Server for Zed Editor

Add the following to your settings.json:

"context_servers": {
  "git_prompt_mcp": {
    "command": "uvx",
    "args": [
      "--from",
      "git+https://github.com/ceshine/git-prompts-mcp-server.git",
      "git-prompts-mcp-server",
      "/path/to/repo/", // parent folder of the .git directory
      "--excludes", // Exclude files and directories from diff results (the server uses pathlib.PurePath behind the scenes)
      "**/uv.lock",
      "--format", // format for diff results
      "json"  // options: json, text
    ],
    "env": {}
  }
}

As a Gemini CLI Extension

To enable the commands and tools provided by this server in your Gemini CLI:

Install the extension:
```
gemini extension install https://github.com/ceshine/git-prompts-mcp-server.git --auto-update
```
This command will install the git-prompts-mcp-server as a Gemini CLI extension, making its prompts and tools available for use.
Usage: Once installed, the prompts (e.g., /git-diff, /generate-pr-desc) and tools (e.g., git_diff, git_cached_diff) will be automatically available to your Gemini CLI sessions when run within a Git repository.

Important Caveat: This extension relies on the current working directory being part of a Git repository (i.e., containing a .git subfolder). If the Gemini CLI is not run from the root of a Git project, the extension's commands and tools may not function as expected.

Commands

The server responds to the following commands:

/git-diff <ancestor_branch_or_commit>: Populate the diff results between HEAD and the specified ancestor branch or commit.
/generate-pr-desc <ancestor_branch_or_commit>: Generate a pull request description based on the diff results and commit history between HEAD and the specified ancestor branch or commit.
/git-cached-diff: Populate the diff results for the staged changes and HEAD.
/git-commit-messages <ancestor_branch_or_commit>: Get commit messages between the ancestor and HEAD.
/generate-commit-message [num_commits]: Generate commit message based on the diff between the files in the staging area (the index) and the HEAD. Additionally, it points out any potential issues in the changes at the end of the output. num_commits defaults to 5. Set to 0 to exclude commit history.

Examples:

/generate-pr-desc main
/git-diff dev
/git-cached-diff
/git-commit-messages main
/generate-commit-message or /generate-commit-message 3

Tools

The server also provides the following tools for MCP-compatible clients:

git-diff: Get a diff between the HEAD and the ancestor branch or commit.
git-cached-diff: Get a diff between the files in the staging area (the index) and the HEAD.
git-unstaged-diff: Get a diff between the working tree and the staging area (equivalent to git diff).
git-commit-messages: Get commit messages between the ancestor and HEAD.

Environment Variables

The server can be configured with the following environment variables, which can be set in the env section of the Zed settings.json:

GIT_REPOSITORY: The path to the Git repository. This is automatically passed by Zed.
GIT_EXCLUDES: A comma-separated list of file patterns to exclude from the diff results (e.g., "*/uv.lock,*.log").
GIT_OUTPUT_FORMAT: The output format for the diff results. Can be json (default) or text.

Development

Clone this repository
Install dependencies: uv sync --frozen

Release Notes

0.3.4 (2026-03-24)

Added git-unstaged-diff MCP tool to expose working tree changes (equivalent to git diff), along with a corresponding tool-git-unstaged-diff CLI command.
Added git-prompts-mcp-cli installed script entry point in pyproject.toml, making the CLI directly invokable after installation without going through uv run python -m.

0.3.3 (2026-01-18)

Transitioned exclusion logic from fnmatch to pathlib.PurePath for more robust and idiomatic path matching, including a workaround for root-level file matching in older Python versions.
Added support for $1 placeholders in prompts to handle template-based workflows (e.g., OpenCode), with defaults provided for these cases.
Enhanced logging and observability across prompt and tool wrappers with more detailed debug and info-level messages.
Added a new test suite specifically for verifying path exclusion patterns.

0.3.2 (2026-01-02)

Updated FastMCP prompt argument type hints to use Annotated[..., Field(...)], so FastMCP correctly applies defaults when the client does not provide values for optional arguments.
Added a new CLI command prompt-generate-commit-message to generate commit messages via the /generate-commit-message prompt, with optional --num-commits.
Fixed a typo by renaming GIT_METHOD_COLLETION to GIT_METHOD_COLLECTION, and added logging plus validation to reject negative num_commits.

0.3.1 (2025-12-10)

Added a new prompt /generate-commit-message to generate commit messages based on staged changes and recent commit history. It also highlights potential issues in the changes.
Added gemini-extension.json to support direct installation as a Gemini CLI extension.
Added support for .pre-commit-config.yaml for development.

0.3.0 (2025-09-05)

Implemented the MCP tool version of the three MCP prompts: git-diff, generate-pr-desc, and git-cached-diff. This allows for a more integrated experience with MCP-compatible clients.
Added a new command /git-commit-messages to get commit messages between a specified ancestor and HEAD.

License

MIT License. See LICENSE for details.

Available Tools

3 tools

git-cached-diffA

Get a diff between the files in the staging area (the index) and the HEAD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but does not describe behavioral traits such as output format, error handling, or side effects. This is a significant gap for a tool with no 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, clear sentence that efficiently conveys the tool's purpose without unnecessary details. It is front-loaded and wastes no words, 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.

Completeness3/5

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

Given the tool has no parameters, an output schema exists, and no annotations, the description covers the basic purpose adequately. However, it lacks details on behavioral aspects like output format or usage context, which could be more complete despite the simplicity of the tool.

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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately does not discuss parameters, which is sufficient for a parameterless tool, earning a baseline score of 4.

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 ('Get a diff') and the resources involved ('files in the staging area (the index) and the HEAD'), making the purpose explicit. It distinguishes from sibling tools like git-diff by specifying the staging area vs. HEAD comparison, which is a precise scope.

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 specifying 'staging area (the index) vs. HEAD', which helps differentiate it from general git-diff. However, it does not explicitly state when to use this tool versus alternatives like git-diff or git-commit-messages, nor does it provide exclusions or prerequisites.

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

git-commit-messagesB

Get commit messages between the ancestor and HEAD

ParametersJSON Schema

Name	Required	Description	Default
`ancestor`	Yes	The ancestor commit hash or branch name

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves commit messages but doesn't describe key behaviors like whether it's read-only, safe to use, how it handles errors, or what the output format entails. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.

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 directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for the task, making it easy for an agent to parse quickly.

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 tool's low complexity (one parameter, no nested objects) and the presence of an output schema (which handles return values), the description is reasonably complete. However, it lacks behavioral details and usage guidelines, which are needed for full contextual understanding, especially with no annotations 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?

The input schema has 100% description coverage, fully documenting the 'ancestor' parameter. The description adds no additional meaning beyond the schema, such as examples or constraints, but since the schema is comprehensive, the baseline score of 3 is appropriate as it doesn't need to compensate for gaps.

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 tool's purpose with a specific verb ('Get') and resource ('commit messages'), and specifies the scope ('between the ancestor and HEAD'). However, it doesn't explicitly differentiate from sibling tools like git-cached-diff or git-diff, which might also involve commit history or comparisons.

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, such as the sibling tools git-cached-diff or git-diff. It mentions the scope but doesn't clarify use cases, prerequisites, or exclusions, leaving the agent to infer usage from context alone.

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

git-diffB

Get a diff between the HEAD and the ancestor branch or commit

ParametersJSON Schema

Name	Required	Description	Default
`ancestor`	Yes	The ancestor commit hash or branch name

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool gets a diff, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires Git repository access, error handling, output format details, or performance considerations. The description is minimal and lacks context beyond the basic action.

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, clear sentence that efficiently conveys the core functionality without unnecessary words. It's front-loaded and appropriately sized for the tool's purpose.

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

Completeness3/5

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

Given the tool's complexity (simple diff operation), high schema coverage, and presence of an output schema, the description is minimally adequate. However, with no annotations and lack of usage guidance, it leaves gaps in understanding the tool's full context and behavior.

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, with the 'ancestor' parameter well-documented. The description adds no additional meaning beyond the schema, such as examples or constraints, but since the schema is comprehensive, the baseline score of 3 is appropriate.

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 ('Get a diff') and the target ('between the HEAD and the ancestor branch or commit'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'git-cached-diff' or 'git-commit-messages', which might have overlapping or related functionality in a Git 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific contexts for usage, leaving the agent to infer based on tool names alone.

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

Install Server

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

TDQS

B3.3/5.0

Disambiguation3/5

The three tools have overlapping purposes focused on git diffs and commit history, which could cause confusion. git-cached-diff and git-diff both produce diffs but target different git states, while git-commit-messages retrieves commit messages. The descriptions help clarify the distinctions, but the domain overlap is significant.

Naming Consistency5/5

All tool names follow a consistent 'git-' prefix with hyphenated descriptive terms (cached-diff, commit-messages, diff). This pattern is predictable and readable throughout the set, with no deviations in style or convention.

Tool Count3/5

With only 3 tools, the server feels thin for a git-related domain, which typically involves more operations like status, log, branch, or push. While the tools cover specific diff and commit message scenarios, the scope appears limited and potentially incomplete for general git workflows.

Completeness2/5

For a git server, there are significant gaps in the tool surface. It lacks basic operations such as viewing status, checking out branches, pushing/pulling changes, or creating commits. The tools only cover diff and commit message retrieval, leaving most git workflows unsupported and likely to cause agent failures.

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

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
saidsef-mcp-github-pr-issue-analyser
ai.smithery
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
Version Control Developer Tools Project Management
26
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3

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 16 hours ago (2026-09-03 01:42 UTC)
12
90,042
MIT
GitHub MCP Server
Version Control Agent Orchestration
Jehan26
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI assistants like Claude to interact with GitHub repositories, issues, and pull requests.
Updated a year ago (2025-03-16 10:14 UTC)
17
MIT
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
MCP Git Server
Version Control Developer Tools
MementoRC
A
license
C
quality
B
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 operations.
Updated 14 days ago (2026-08-21 02:50 UTC)
22
4
MIT

Appeared in Searches

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/ceshine/git-prompts-mcp-server'

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

Git Prompts MCP Server

Acknowledgements

Usage

As a MCP Server for Zed Editor

As a Gemini CLI Extension

Commands

Tools

Environment Variables

Development

Release Notes

0.3.4 (2026-03-24)

0.3.3 (2026-01-18)

0.3.2 (2026-01-02)

0.3.1 (2025-12-10)

0.3.0 (2025-09-05)

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

git MCP serverofficial

GitHub MCP Server

MCP Git Server

MCP Git Server

Appeared in Searches

Latest Blog Posts

MCP directory API