MCP Git Status Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| git-statusB | Get the current git status of the repository |
| git-logB | Get recent git commit history |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The 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.