Provides tools for checking git repository status and viewing recent commit history, enabling AI agents to understand the current state of version-controlled projects
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Git Status Server show me the git status of my current project"
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.
A Model Context Protocol (MCP) server that provides git status and log functionality. This server allows MCP clients (like Claude Desktop, Cline, etc.) to check git repository status and view recent commit history.
Git Status Tool: Get the current status of a git repository
Git Log Tool: View recent commit history
Error Handling: Graceful error handling for non-git directories and other issues
Directory Support: Optionally specify a directory path to check
Related MCP server: Git Workflow MCP Server
Clone or download this repository
Install dependencies:
npm installBuild the project:
npm run buildTest the server:
npm testThe server communicates via stdio (standard input/output) as per MCP protocol:
# Run the built version
npm start
# Or run in development mode with tsx
npm run devProject-specific configuration (recommended for this project):
Cursor is already configured for this project via .cursor/mcp.json.
Global configuration (to use in all projects): The server is also configured globally. After restarting Cursor, you can ask questions like:
"What's the git status of this repository?"
"Show me the last 5 commits"
"Check if there are any uncommitted changes"
Cursor will automatically use the git-status tools to answer your questions.
Manual configuration (if needed):
Create ~/.cursor/mcp.json with:
{
"mcpServers": {
"git-status": {
"command": "node",
"args": ["/Users/narayan/Developer/qoder/dist/index.js"],
"description": "Git status and log tools for repository management"
}
}
}Note: Replace the path with the actual path to your compiled server.
Add this server to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"git-status": {
"command": "node",
"args": ["/path/to/your/mcp-git-status-server/dist/index.js"],
"description": "Git status and log tools for repository management"
}
}
}Note: Replace /path/to/your/mcp-git-status-server with the actual path to your project directory.
A sample configuration file is included as claude-desktop-config.json for reference.
For other MCP clients, configure them to run this server as a subprocess with stdio transport.
Get the current git status of a repository.
Parameters:
directory (optional): Directory path to check. Defaults to current directory.
Example usage in MCP client: "Check the git status of my project"
View recent git commit history.
Parameters:
directory (optional): Directory path to check. Defaults to current directory.
count (optional): Number of recent commits to show. Defaults to 10.
Example usage in MCP client: "Show me the last 5 git commits"
Git Status for: /Users/username/my-project
Current branch: main
Status:
Working directory clean - no changes detected
Remotes:
origin https://github.com/username/my-project.git (fetch)
origin https://github.com/username/my-project.git (push)Git Status for: /Users/username/my-project
Current branch: feature-branch
Status:
M src/index.ts
A src/new-file.ts
?? untracked.txt
Remotes:
origin https://github.com/username/my-project.git (fetch)
origin https://github.com/username/my-project.git (push)Recent Git Commits (5 most recent):
abc1234 Add new feature implementation
def5678 Fix bug in status handling
ghi9012 Update documentation
jkl3456 Initial commitThe server gracefully handles common error scenarios:
Not a git repository: Provides clear error message
Git not installed: Indicates git is not available
Permission issues: Reports access problems
Invalid directory: Handles non-existent paths
npm run build: Compile TypeScript to JavaScript
npm run dev: Run in development mode with tsx
npm start: Run the compiled server
npm test: Build and validate the server functionality
├── src/
│ └── index.ts # Main server implementation
├── dist/ # Compiled JavaScript (generated)
├── validate-mcp.js # Validation script for testing
├── claude-desktop-config.json # Sample Claude Desktop configuration
├── package.json # Project configuration
├── tsconfig.json # TypeScript configuration
└── README.md # This fileThe project includes a comprehensive validation script (validate-mcp.js) that tests:
MCP protocol initialization
Tool discovery (tools/list)
Git status functionality
Git log functionality
Error handling for invalid tools
Run validation with:
npm testThe validation script will:
Build the project
Start the MCP server
Test all functionality
Report results
Clean up automatically
Node.js 18.x or higher
Git installed and available in PATH
TypeScript (for development)
MIT License
Fork the repository
Create a feature branch
Make your changes
Test thoroughly
Submit a pull request
Server not starting:
Check Node.js version (requires 18.x+)
Ensure all dependencies are installed: npm install
Build the project: npm run build
Git commands failing:
Verify git is installed: git --version
Ensure you're in a git repository
Check file permissions
MCP client not connecting:
Verify the path to the server executable in client configuration
Check that the server process can be started manually
Review client logs for connection errors
Get recent git commit history
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | Directory path to check git log (defaults to current directory) | |
| count | No | Number of recent commits to show (default: 10) |
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. 'Get recent git commit history' implies a read-only operation, but it doesn't specify output format, error conditions, or any behavioral traits like rate limits or side effects. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 appropriately sized and front-loaded, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a read operation with two parameters) and no output schema, the description is minimally complete. It states what the tool does but lacks details on output format or behavioral context. With no annotations and 100% schema coverage, it's adequate but has clear gaps in usage guidance and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. However, schema description coverage is 100%, with clear documentation for both parameters ('directory' and 'count'), including defaults. This meets the baseline score of 3, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent git commit history' clearly states the tool's function with a specific verb ('Get') and resource ('git commit history'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'git-status' (which likely shows working directory status rather than commit history), so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling tool 'git-status' or any other context for choosing between them, nor does it specify prerequisites or constraints. This leaves the agent with minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current git status of the repository
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | Directory path to check git status (defaults to current directory) |
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 states this is a read operation ('Get'), but doesn't mention whether it requires git repository initialization, what happens with non-git directories, error conditions, or output format. The description is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one optional parameter and no output schema, the description is minimally adequate. However, without annotations and with a sibling tool present, it should provide more context about differentiation and behavioral expectations to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single optional parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current git status of the repository'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'git-log', which likely shows commit history rather than current status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'git-log' or other git operations. It states what the tool does but offers no context about appropriate use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
git-loggit-statusThe two tools have clearly distinct purposes: git-log retrieves commit history, while git-status provides current repository state. There is no overlap or ambiguity between them.
Both tools follow a consistent 'git-' prefix with descriptive suffixes (log, status), using kebab-case throughout. The naming pattern is perfectly uniform.
With only 2 tools, the server feels thin for a Git status domain. While the tools cover basic status and log operations, typical Git workflows would benefit from additional tools (e.g., diff, branch, stash).
For a Git status server, the surface is significantly incomplete. It lacks tools for common Git operations like diff, branch status, remote status, or staging area inspection, which limits agent effectiveness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Git-backed platform for skills, tools, and context for AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/narayana-reddy-circles/mcp-git-status'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
