mcp-server-git

by yinghuohuichao

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.2
Disambiguation4/5
Most tools map to distinct Git operations, but git_diff, git_diff_staged, and git_diff_unstaged overlap enough that an agent could select the wrong one without careful attention. The descriptions help separate them, but the boundary between general diff and specific diff variants creates slight ambiguity.
Naming Consistency5/5
All tools follow a consistent git_ prefix with familiar Git command names, making the set predictable and easy to navigate. Verb and noun forms align with standard Git vocabulary, so there is no stylistic mixing or confusing variation.
Tool Count5/5
Twelve tools is well-scoped for a Git server, covering common local repository workflows without unnecessary bloat. Each tool addresses a concrete Git operation, and the count feels appropriate rather than sparse or excessive.
Completeness4/5
The toolset covers the core local Git workflow: status, diff, add, commit, branch, checkout, log, and show. Minor gaps like branch deletion or merge are missing, but agents can perform essential repository inspection and commit tasks without dead ends.
Average 3.1/5 across 12 of 12 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide no strong behavioral signal. The description adds only 'records changes', which implies mutation but does not disclose side effects such as creating a permanent commit, requiring user identity, or being a one-way local operation. No additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is under-specified rather than concise. It simply paraphrases the tool name and omits essential context, adding little value beyond the name itself.
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 git commit operation, understanding that only staged changes are committed is crucial, but the description ignores this entirely. It also does not mention that repo_path must be a valid local repository or that a message is required, leaving important operational context missing.
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?
Input schema description coverage is 0%, and the description gives no meaning for repo_path or message. While the parameter names are somewhat self-explanatory, the description fails to clarify that message is the commit message and repo_path is the target repository, so it does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Records changes to the repository' provides a verb and resource, broadly distinguishing it from siblings like git_status (shows state) or git_diff (shows differences). However, it is vague and does not explicitly mention committing, staged changes, or creating a snapshot, so it relies on the tool name for clarity.
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 offers no guidance on when to use this tool versus alternatives. It does not mention that changes must first be staged with git_add, nor does it contrast with git_reset or git_status, leaving the agent without selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with readOnlyHint, idempotentHint, and destructiveHint=false, but it adds no behavioral context beyond what the annotations already state. It does not mention default truncation, output characteristics, or repository-scope behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than appropriately concise. A single five-word phrase is not enough structure for a tool with four parameters and several closely related sibling tools.
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?
With no output schema and no sibling differentiation, the description leaves the agent to infer what the logs contain and when this tool is appropriate. The annotations cover safety, but the description alone does not make the tool's usage context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%; end_timestamp and start_timestamp are documented, but repo_path and max_count are not. The tool description itself provides no parameter meaning, so it does not compensate for the undocumented parameters.
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 uses a specific verb and resource ('Shows the commit logs'), so an agent can understand the basic operation. It does not differentiate from siblings like git_show or provide scope, but the action and resource are clear.
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?
No guidance is given about when to use git_log instead of sibling tools such as git_show, git_diff, or git_status. There are no conditions, exclusions, or alternative pointers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=false, so the operation is known to be non-read-only, but the description adds no new behavioral context. It does not disclose that switching branches can fail with uncommitted changes, can alter the working directory, or may be rejected by Git in certain states. The description carries the burden and fails to provide this information.
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 extremely concise, with no wasted words, and the core action is front-loaded. While it sacrifices richer context, the two-word phrase is efficient and directly states the primary purpose.
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?
This is a state-changing Git operation with no output schema and annotations that only provide false hints. The description is under-specified: it lacks prerequisites, failure conditions, parameter semantics, and any indication of side effects. An agent would not know that checkout may be interrupted by local modifications or that the working tree is affected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description was expected to compensate for undocumented parameters. It does not mention repo_path or branch_name at all, and the schema itself only provides type and title, no descriptive text. The parameter names are self-explanatory, but the description adds no meaning beyond the schema.
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 states a specific action ('switches') and resource (branches), making it clear this tool changes the current branch. It is distinguishable from siblings like git_create_branch or git_branch, though it does not explicitly name alternatives or address checkout's broader file-level behavior.
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?
No guidance is provided on when to use this tool versus alternatives such as git_create_branch or git_reset. There is no mention of prerequisites, scenarios, or caveats like needing a clean working tree, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the operation is not read-only, not idempotent, and not destructive, which is consistent with creation. However, the description adds little beyond that: it does not clarify whether the new branch is checked out, what the default base is when base_branch is null, or what happens if the branch already exists. These are meaningful behavioral traits an agent would need to know.
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, front-loaded sentence with no wasted words. It states the core action and the key variant (optional base branch) efficiently.
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 simple creation tool with no output schema and minimal annotations, the description is incomplete. It fails to specify the default base behavior or whether the branch becomes the current branch, both of which are relevant to correct invocation and subsequent git operations. The presence of git_checkout as a sibling makes this omission more noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions the optional base branch. It provides no additional meaning for repo_path or branch_name beyond their titles. The phrase 'optional base branch' adds little because the schema already marks base_branch as optional with a default of null.
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 is clear and specific: it creates a new branch and mentions the optional base branch. It distinguishes this tool from most siblings (status, diff, add, commit, reset, checkout, show, log) because it uniquely creates a branch, but it does not explicitly differentiate from git_branch, which could also have a create mode.
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?
No guidance is provided about when to use this tool versus git_branch or git_checkout. There is no mention of prerequisites, such as being in a Git repository, or exclusions like 'this does not switch branches'. The description implies use for creating branches but offers no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the operation itself, such as output format, error behavior, or requirements like a valid repository.
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?
One short sentence with no superfluous words. The core action is front-loaded and nothing needs to be trimmed.
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?
With no output schema, the description should indicate what 'contents' means or what the return value looks like, but it does not. It also omits practical details such as revision format or that repo_path must be a valid Git repository.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain repo_path or acceptable revision formats. It only weakly implies that revision identifies a commit; the parameter names themselves carry most of the meaning.
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?
States a clear verb and resource ('Shows the contents of a commit'), which broadly distinguishes it from status/diff/branch tools. However, 'contents' is ambiguous (patch vs snapshot) and there is no explicit differentiation from siblings like git_log or git_diff.
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?
No guidance on when to use this tool versus alternatives such as git_log or git_diff. The description provides no context for tool selection and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile — the description need not restate this. The description adds the semantic scope (differences between branches or commits) but doesn't disclose what the output format looks like (e.g., unified diff, patch text) or mention the default of 3 context lines shown by the parameter default. That gap is modest, so a 3 is fair.
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 with no filler or repetition. It isn't front-loaded with a redundant restatement of the tool name. It earns a 4 for being appropriately sized, though a second sentence clarifying the target parameter would push it higher.
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?
This is a read-only tool with a trivial annotation profile, so no output schema is needed, but the description still leaves gaps. It doesn't specify valid 'target' formats (branch name vs. commit hash vs. range like 'main..dev'), doesn't say what the output looks like, and doesn't mention the context_lines behavior. For a three-parameter tool with zero schema documentation of those parameters, that is an incomplete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter semantics — and it fails to do so. The description mentions 'differences between branches or commits', which loosely maps to 'target', but says nothing about what 'target' should contain (a branch name, a commit hash, or a range), what 'repo_path' is, or what the optional 'context_lines' controls (number of surrounding lines shown in the diff). With all three parameters undocumented in the schema, the description would need to explain at least 'target' to earn a 3; it only gestures at it.
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 'Shows differences between branches or commits' provides a clear verb ('shows'), a specific resource ('differences between branches or commits'), and is unambiguous about what the tool does. It doesn't explicitly differentiate from sibling tools, but the resource is specific enough to distinguish it from common alternatives like git_log or git_show.
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 gives no guidance on when to use this tool versus alternatives. It doesn't state whether to use it for uncommitted working-directory changes, staged changes, or particular diff formats, nor does it mention branches/commits as alternative scopes. An agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds minimal context by specifying the resource ('working tree status') but does not reveal any additional behavioral traits such as whether it includes staged, unstaged, or untracked files, or any limitations. The description is consistent with annotations, so no contradiction.
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, well-formed sentence that delivers the core purpose without any wasted words. It is front-loaded and immediately understandable, making it an excellent example of conciseness.
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 low complexity (one parameter, no output schema) and the presence of annotations that cover the safety profile, the description is minimally adequate. However, it is missing useful context such as what exactly the status includes (e.g., branch, staged, unstaged, untracked files) and how repo_path should be specified. An agent could call the tool correctly but might lack expectations about the returned output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention or explain the 'repo_path' parameter. Although the parameter name and title 'Repo Path' are somewhat self-explanatory, the description fails to compensate for the lack of schema documentation, leaving the agent without guidance on how the path should be formatted or validated.
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 uses a specific verb ('Shows') and resource ('working tree status'), clearly indicating what the tool does. While it does not explicitly differentiate itself from sibling tools, 'working tree status' is a distinct concept that separates it from git_diff and git_log, making the purpose unambiguous.
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 does not mention git_diff for viewing changes, git_log for history, or any conditions that would make git_status the preferred choice. The usage context is only implied by the tool name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety and mutation profile is known. The description does not add behavioral context beyond restating the core operation; it does not mention reversible staging semantics, overwriting previously staged content, or any interesting 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 short sentence that front-loads the core verb and object. There is no filler, redundant wording, or unnecessary detail.
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?
For a simple two-parameter, idempotent git tool, the description is minimally viable. However, it lacks usage guidance, does not clarify repo_path semantics, and offers no information about edge cases such as empty file lists or non-existent files. With no output schema, the agent has to infer the expected call behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It faintly suggests that 'files' refers to content being staged, but it says nothing about repo_path or how file paths should be specified (absolute, relative, globs, etc.). This leaves significant parameter ambiguity.
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 states a specific verb ('Adds') and resource ('file contents to the staging area'), making the tool's purpose unmistakable. It is clearly distinct from siblings like git_status, git_diff, git_commit, and git_reset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to stage file contents), but it provides no explicit guidance about when not to use it or which sibling tool might be a better alternative. There is no mention of prerequisites such as an initialized repository or that files must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructive and idempotent behavior. The description adds the scope of the operation ('all staged changes') but does not clarify side effects such as whether working-tree changes or commit history are affected. It does not contradict the 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 a single concise sentence with no wasted words. It front-loads the core behavior immediately and is easy for an agent to parse.
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?
For a simple one-parameter git operation, the description covers the action and scope. The annotations cover destructive and idempotent behavior, so the remaining gaps, such as output format and non-effect on working tree, are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage and the description does not explain repo_path. Although repo_path is a single self-explanatory parameter, the description adds no meaning about its format, required location, or default behavior, so it does not compensate for the low schema coverage.
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?
Description uses a specific verb and resource: 'Unstages all staged changes'. It clearly tells the agent exactly what the tool does and distinguishes it from siblings like git_add, git_status, and git_diff_staged.
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?
No guidance is given about when to use this tool versus alternatives. There is no mention of when not to use it, what prerequisites apply, or how it compares to git_checkout, git_commit, or git_add.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds no behavioral context beyond stating the listing operation, and it does not contradict the 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 four words, front-loads the action, and contains no filler. Every word contributes to meaning.
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?
For a low-complexity read-only listing tool, the terse description combined with complete schema documentation and safety annotations is largely sufficient. It does not describe return values, but the absence of an output schema is mitigated by the obvious nature of a branch listing.
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 input schema fully documents repo_path, branch_type, contains, and not_contains. The description does not add parameter-level detail, which is acceptable given the schema's completeness.
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 names a specific verb and resource: 'List Git branches'. It is clearly distinct from sibling operations like git_create_branch, git_checkout, and git_status, so an agent can select it as the listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for enumeration of branches but offers no explicit when-to-use guidance or exclusions, such as using git_create_branch instead when creation is intended. For a simple listing tool this is acceptable, but the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the staging scope, which is useful, but does not disclose any other behavior such as output format or behavior when there are no staged changes.
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?
One short sentence with no filler. The core meaning is front-loaded and every word contributes. The description earns its place without redundancy.
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?
The tool is simple and annotations cover its read-only, non-destructive nature. However, with no output schema, the description does not clarify output format, empty-diff behavior, or the optional context_lines parameter. It is minimally viable but leaves some invocation-relevant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate, but it does not mention repo_path or context_lines at all. The parameter names and titles are reasonably self-explanatory, but the description itself adds no meaning beyond the schema.
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 uses a specific verb and resource: 'Shows changes that are staged for commit.' The term 'staged' clearly distinguishes this from siblings like git_diff_unstaged and git_status, so an agent can identify the right tool without opening schemas.
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 provides clear context: use this when you want staged changes. It does not explicitly name alternatives or state when not to use it, but 'staged for commit' gives an unambiguous selection signal against the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the unstaged-scope detail, but does not disclose output format, error behavior, or how it handles an empty diff. This is consistent with annotations and provides modest value.
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, front-loaded sentence with no filler or redundant detail. It states the core behavior clearly and economically, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only git operation, the description is minimally viable: it communicates scope and is consistent with annotations. However, it leaves parameter semantics and output format entirely to inference, and it could usefully mention that the output is a diff between the working tree and the index.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention either repo_path or context_lines, and schema description coverage is 0%. The parameter names and types are somewhat self-explanatory, especially repo_path, but context_lines' meaning (number of context lines around each diff hunk) is left implicit and the description adds no parameter-level guidance.
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 uses a specific verb ('Shows') and a precise resource ('changes in the working directory that are not yet staged'), which clearly differentiates this tool from its sibling git_diff_staged. An agent can immediately understand both what the tool does and what scope it covers.
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 phrase 'not yet staged' provides clear context for when this tool is appropriate: when an agent needs to inspect working-tree changes that have not been added to the index. However, it does not explicitly name alternatives or state when not to use it, though the sibling list makes the comparison available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-git MCP server](https://glama.ai/mcp/servers/yinghuohuichao/mcp-server-git/badges/card.svg)](https://glama.ai/mcp/servers/yinghuohuichao/mcp-server-git)

Score Badge

Copy to your README.md:

[![mcp-server-git MCP server](https://glama.ai/mcp/servers/yinghuohuichao/mcp-server-git/badges/score.svg)](https://glama.ai/mcp/servers/yinghuohuichao/mcp-server-git)

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

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