Git 저장소 상호작용 및 자동화를 위한 Model Context Protocol 서버입니다. 이 서버는 대규모 언어 모델(LLM)을 통해 Git 저장소를 읽고, 검색하고, 조작할 수 있는 도구를 제공합니다.
mcp-server-git은 현재 초기 개발 단계에 있습니다. 서버를 지속적으로 개발하고 개선함에 따라 기능과 사용 가능한 도구는 변경되거나 확장될 수 있습니다.
git_status
작업 트리 상태를 표시합니다.
입력:
repo_path (문자열): Git 저장소 경로
반환: 작업 디렉토리의 현재 상태를 텍스트로 출력
git_diff_unstaged
아직 스테이징되지 않은 작업 디렉토리의 변경 사항을 표시합니다.
입력:
repo_path (문자열): Git 저장소 경로
context_lines (숫자, 선택 사항): 표시할 컨텍스트 라인 수 (기본값: 3)
반환: 스테이징되지 않은 변경 사항의 diff 출력
git_diff_staged
커밋을 위해 스테이징된 변경 사항을 표시합니다.
입력:
repo_path (문자열): Git 저장소 경로
context_lines (숫자, 선택 사항): 표시할 컨텍스트 라인 수 (기본값: 3)
반환: 스테이징된 변경 사항의 diff 출력
git_diff
브랜치 또는 커밋 간의 차이점을 표시합니다.
입력:
repo_path (문자열): Git 저장소 경로
target (문자열): 비교할 대상 브랜치 또는 커밋
context_lines (숫자, 선택 사항): 표시할 컨텍스트 라인 수 (기본값: 3)
반환: 현재 상태와 대상을 비교한 diff 출력
git_commit
저장소에 변경 사항을 기록합니다.
입력:
repo_path (문자열): Git 저장소 경로
message (문자열): 커밋 메시지
반환: 새 커밋 해시가 포함된 확인 메시지
git_add
파일 내용을 스테이징 영역에 추가합니다.
입력:
repo_path (문자열): Git 저장소 경로
files (문자열[]): 스테이징할 파일 경로 배열
반환: 스테이징된 파일 확인 메시지
git_reset
모든 스테이징된 변경 사항을 스테이징 해제합니다.
입력:
repo_path (문자열): Git 저장소 경로
반환: 리셋 작업 확인 메시지
git_log
선택적 날짜 필터링과 함께 커밋 로그를 표시합니다.
입력:
repo_path (문자열): Git 저장소 경로
max_count (숫자, 선택 사항): 표시할 최대 커밋 수 (기본값: 10)
start_timestamp (문자열, 선택 사항): 커밋 필터링을 위한 시작 타임스탬프. ISO 8601 형식(예: '2024-01-15T14:30:25'), 상대 날짜(예: '2 weeks ago', 'yesterday'), 또는 절대 날짜(예: '2024-01-15', 'Jan 15 2024')를 허용합니다.
end_timestamp (문자열, 선택 사항): 커밋 필터링을 위한 종료 타임스탬프. ISO 8601 형식, 상대 날짜, 또는 절대 날짜를 허용합니다.
반환: 해시, 작성자, 날짜, 메시지가 포함된 커밋 항목 배열
git_create_branch
새 브랜치를 생성합니다.
입력:
repo_path (문자열): Git 저장소 경로
branch_name (문자열): 새 브랜치 이름
base_branch (문자열, 선택 사항): 생성 기준이 될 베이스 브랜치 (기본값은 현재 브랜치)
반환: 브랜치 생성 확인 메시지
git_checkout
브랜치를 전환합니다.
입력:
repo_path (문자열): Git 저장소 경로
branch_name (문자열): 체크아웃할 브랜치 이름
반환: 브랜치 전환 확인 메시지
git_show
커밋 내용을 표시합니다.
입력:
repo_path (문자열): Git 저장소 경로
revision (문자열): 표시할 리비전(커밋 해시, 브랜치 이름, 태그)
반환: 지정된 커밋의 내용
git_branch
Git 브랜치 목록을 표시합니다.
입력:
repo_path (문자열): Git 저장소 경로
branch_type (문자열): 로컬 브랜치('local'), 원격 브랜치('remote'), 또는 모든 브랜치('all') 중 선택
contains (문자열, 선택 사항): 브랜치가 포함해야 하는 커밋 SHA. 커밋 SHA가 지정되지 않은 경우 이 매개변수에 아무것도 전달하지 마십시오.
not_contains (문자열, 선택 사항): 브랜치가 포함하지 않아야 하는 커밋 SHA. 커밋 SHA가 지정되지 않은 경우 이 매개변수에 아무것도 전달하지 마십시오.
반환: 브랜치 목록
Related MCP server: GitHub Tools MCP Server
uv를 사용할 때는 별도의 설치가 필요하지 않습니다. uvx를 사용하여 mcp-server-git을 직접 실행합니다.
또는 pip를 통해 mcp-server-git을 설치할 수 있습니다:
pip install mcp-server-git설치 후 다음 명령어로 스크립트로 실행할 수 있습니다:
python -m mcp_server_gitclaude_desktop_config.json에 다음을 추가하세요:
"mcpServers": {
"git": {
"command": "uvx",
"args": ["mcp-server-git", "--repository", "path/to/git/repo"]
}
}참고: '/Users/username'을 이 도구에서 액세스할 수 있도록 하려는 경로로 바꾸세요.
"mcpServers": {
"git": {
"command": "docker",
"args": ["run", "--rm", "-i", "--mount", "type=bind,src=/Users/username,dst=/Users/username", "mcp/git"]
}
}"mcpServers": {
"git": {
"command": "python",
"args": ["-m", "mcp_server_git", "--repository", "path/to/git/repo"]
}
}빠른 설치를 위해 아래의 원클릭 설치 버튼 중 하나를 사용하세요...
수동 설치의 경우, 다음 방법 중 하나를 사용하여 MCP 서버를 구성할 수 있습니다:
방법 1: 사용자 구성 (권장)
사용자 수준 MCP 구성 파일에 구성을 추가합니다. 명령 팔레트(Ctrl + Shift + P)를 열고 MCP: Open User Configuration을 실행합니다. 그러면 사용자 mcp.json 파일이 열리며, 여기서 서버 구성을 추가할 수 있습니다.
방법 2: 작업 영역 구성
또는 작업 영역의 .vscode/mcp.json 파일에 구성을 추가할 수 있습니다. 이렇게 하면 다른 사람들과 구성을 공유할 수 있습니다.
VS Code의 MCP 구성에 대한 자세한 내용은 공식 VS Code MCP 문서를 참조하세요.
{
"servers": {
"git": {
"command": "uvx",
"args": ["mcp-server-git"]
}
}
}Docker 설치의 경우:
{
"mcp": {
"servers": {
"git": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"--mount", "type=bind,src=${workspaceFolder},dst=/workspace",
"mcp/git"
]
}
}
}
}Zed의 settings.json에 추가하세요:
"context_servers": [
"mcp-server-git": {
"command": {
"path": "uvx",
"args": ["mcp-server-git"]
}
}
],"context_servers": {
"mcp-server-git": {
"command": {
"path": "python",
"args": ["-m", "mcp_server_git"]
}
}
},Zencoder 메뉴(...)로 이동합니다.
드롭다운 메뉴에서 Agent Tools를 선택합니다.
Add Custom MCP를 클릭합니다.
이름(예: git)과 아래의 서버 구성을 추가하고 Install 버튼을 누르세요.
{
"command": "uvx",
"args": ["mcp-server-git", "--repository", "path/to/git/repo"]
}MCP 인스펙터를 사용하여 서버를 디버깅할 수 있습니다. uvx 설치의 경우:
npx @modelcontextprotocol/inspector uvx mcp-server-git또는 특정 디렉토리에 패키지를 설치했거나 개발 중인 경우:
cd path/to/servers/src/git
npx @modelcontextprotocol/inspector uv run mcp-server-gittail -n 20 -f ~/Library/Logs/Claude/mcp*.log를 실행하면 서버 로그가 표시되어 문제를 디버깅하는 데 도움이 될 수 있습니다.
로컬 개발을 수행하는 경우 변경 사항을 테스트하는 두 가지 방법이 있습니다:
MCP 인스펙터를 실행하여 변경 사항을 테스트합니다. 실행 지침은 디버깅을 참조하세요.
Claude 데스크톱 앱을 사용하여 테스트합니다. claude_desktop_config.json에 다음을 추가하세요:
{
"mcpServers": {
"git": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"--mount", "type=bind,src=/Users/username/Desktop,dst=/projects/Desktop",
"--mount", "type=bind,src=/path/to/other/allowed/dir,dst=/projects/other/allowed/dir,ro",
"--mount", "type=bind,src=/path/to/file.txt,dst=/projects/path/to/file.txt",
"mcp/git"
]
}
}
}{
"mcpServers": {
"git": {
"command": "uv",
"args": [
"--directory",
"/<path to mcp-servers>/mcp-servers/src/git",
"run",
"mcp-server-git"
]
}
}
}Docker 빌드:
cd src/git
docker build -t mcp/git .이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다. 이는 MIT 라이선스의 약관에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있음을 의미합니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.
Adds file contents to the staging area
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| repo_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering safety. The description adds no extra behavioral context beyond what annotations provide, such as behavior with non-existent files or overwriting staging.
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 sentence, making it very concise. However, it lacks structure; integrating parameter explanations or usage context would improve it without sacrificing brevity.
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 simplicity, the description is incomplete: no info on output, error handling, or parameter details. Context signals show no output schema, so the description shoulders more responsibility, which it fails to meet.
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 0%, yet the description does not explain the two required parameters (repo_path, files). The agent has no context on file path formats, glob patterns, or required directory specifications.
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 'Adds file contents to the staging area' uses a specific verb and resource, clearly distinguishing it from sibling tools like git_commit (which commits staged changes) or git_branch (branch management).
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?
No guidance on when to use this tool versus alternatives, such as using it before git_commit or how to add specific files. The description does not mention prerequisites, typical workflow, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Git branches
| Name | Required | Description | Default |
|---|---|---|---|
| contains | No | The commit sha that branch should contain. Do not pass anything to this param if no commit sha is specified | |
| repo_path | Yes | The path to the Git repository. | |
| branch_type | Yes | Whether to list local branches ('local'), remote branches ('remote') or all branches('all'). | |
| not_contains | No | The commit sha that branch should NOT contain. Do not pass anything to this param if no commit sha is specified |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering the safety profile. The description adds no extra behavioral details (e.g., output format, ordering). Adequate but not enhanced.
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?
Extremely concise (one sentence) and front-loaded. Efficient for a simple list operation, though slightly under-specified.
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?
With no output schema and a simple list operation, the description is adequate but doesn't specify return format. Annotations cover safety, and sibling context helps, but completeness is minimal.
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 fully documents all four parameters. The description does not add any additional meaning beyond what's in the schema.
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 'List Git branches' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes itself from siblings like git_create_branch (create) and git_checkout (switch).
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?
No guidance on when to use this tool versus alternatives (e.g., git_create_branch for creation, git_checkout for switching). The description lacks context on scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switches branches
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| branch_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. Description adds no behavioral context beyond annotation, such as effects of uncommitted changes or merge conflicts. For a branching operation, this is a gap.
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?
Extremely brief (two words), which could be considered concise, but lacks structure and substance. It is front-loaded but arguably under-specified.
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 context (2 params, no output schema, simple but with side effects), the description is incomplete. It does not address what happens when switching branches (e.g., uncommitted changes, conflicts) or return value.
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 0%, and description does not explain parameters. Despite 'repo_path' and 'branch_name' being somewhat self-explanatory, the description fails to add meaning beyond the schema, which itself lacks descriptions. Baseline for low coverage requires compensation; here it is absent.
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?
Description clearly states 'Switches branches', a specific verb and resource. However, it does not differentiate from sibling tools like 'git_branch' (which likely lists/create/delete branches) or 'git_create_branch', but the action is distinct enough. Score 4 for clarity but lacking sibling differentiation.
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?
No guidance on when to use this tool versus alternatives like 'git_create_branch' or 'git_branch'. No exclusions, prerequisites, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records changes to the repository
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| repo_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies mutation (records changes) but offers no further behavioral details such as requiring staged changes, side effects, or commit creation. With no annotations providing behavioral info, the description is insufficient.
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 single sentence is concise but lacks structure. It could be improved by adding a brief explanation of parameters and usage context without becoming verbose.
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 tool with two parameters and no output schema, the description omits critical details like parameter meanings and prerequisites (e.g., staged changes). It is incomplete.
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 0%, yet the description does not explain either parameter (repo_path, message). It adds no meaning beyond the schema field names.
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 'Records changes to the repository' is vague and does not differentiate git_commit from siblings like git_add, which also records changes. It fails to specify that it creates a permanent snapshot with a message, and the verb 'records' is too generic.
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?
No guidance on when to use this tool versus alternatives (e.g., git_add for staging, git_reset for undoing). The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new branch from an optional base branch
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| base_branch | No | ||
| branch_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate not read-only and not destructive. The description adds no extra behavioral context, such as error behavior if branch already exists or default base branch behavior.
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?
Single sentence is very concise with no wasted words. Could benefit from a slightly more structured format, but remains efficient.
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 tool, the description covers the basic purpose but lacks details on default behavior (e.g., what branch is created from if base_branch is null) and error handling. Without an output schema, more explanation of return values would help.
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 coverage is 0%, but description only clarifies the optional base_branch parameter. repo_path and branch_name are not elaborated beyond their names. The description adds minimal value over the schema.
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 it creates a new branch from an optional base branch, which distinguishes it from siblings like git_branch (listing) and git_checkout (switching). However, it could be more specific about what 'from' means, e.g., 'based on current HEAD if base_branch is omitted'.
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?
No guidance on when to use this tool versus alternatives like git_branch or git_checkout. No when-not or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows differences between branches or commits
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| repo_path | Yes | ||
| context_lines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral context beyond what annotations already provide (readOnly, non-destructive, idempotent). It is acceptable but offers no extra transparency about edge cases or performance.
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 only one sentence, making it concise. However, it lacks essential details, so the brevity harms completeness rather than being a virtue.
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 presence of sibling tools and three parameters, the description is too minimal. It omits parameter explanations, usage context, and output expectations, making it incomplete for effective tool selection.
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 0%, and the description does not explain any parameter (repo_path, target, context_lines). The agent gets no help understanding the meaning or format of parameters.
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 it shows differences between branches or commits, matching the tool's name. However, it does not differentiate from the sibling tools git_diff_staged and git_diff_unstaged, which are more specific variants.
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?
No guidance is provided on when to use this tool over its siblings (e.g., git_diff_staged, git_diff_unstaged). The agent is left to infer usage without explicit when-to or when-not-to directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows changes that are staged for commit
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| context_lines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true and destructiveHint: false, so the safety profile is clear. The description adds no behavioral context beyond 'shows changes', omitting details like requirement of repo_path or default context_lines behavior. With annotations covering safety, the bar is lower, but the description still fails to add useful 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 concise sentence with no unnecessary wording. However, it could include additional relevant details (e.g., parameter explanations) without becoming overly verbose, so it is appropriately sized but not optimally informative.
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 tool with no output schema and 0% schema description coverage, the description is incomplete. It does not specify that the output is a diff format, nor does it explain the context_lines parameter's effect. While the tool is simple, the lack of completeness could lead to agent confusion without additional context.
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 0%, yet the description does not explain any parameter meaning. The parameter names (repo_path, context_lines) are somewhat self-explanatory, but the description adds no additional semantics, such as the purpose of context_lines or how repo_path is used. The description should compensate for the schema coverage gap but fails.
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?
Description clearly states 'Shows changes that are staged for commit', using specific verb 'Shows' and resource 'changes that are staged'. This effectively distinguishes it from siblings like 'git_diff_unstaged' (for unstaged changes) and 'git_diff' (likely for all changes).
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?
No explicit when-to-use or when-not-to-use guidance is provided. However, the tool name and description imply it is for reviewing staged changes before commit, and the sibling tool names suggest alternatives. Usage context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows changes in the working directory that are not yet staged
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| context_lines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds no further behavioral context, but is consistent with annotations.
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 concise sentence that communicates the primary purpose. It is front-loaded but could incorporate more information without becoming verbose.
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 simplicity of the tool and existing annotations, the description is minimally adequate. However, it lacks parameter explanations and usage guidance, which would improve completeness for an agent.
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?
With 0% schema description coverage, the description should explain the parameters. It does not mention repo_path or context_lines, relying solely on parameter names and titles. This is insufficient for correct invocation.
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 'Shows changes in the working directory that are not yet staged' uses a specific verb ('Shows') and resource ('changes') and clearly distinguishes from siblings like 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives like git_diff or git_diff_staged. The purpose is implied by the tool name, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows the commit logs
| Name | Required | Description | Default |
|---|---|---|---|
| max_count | No | ||
| repo_path | Yes | ||
| end_timestamp | No | End timestamp for filtering commits. Accepts: ISO 8601 format (e.g., '2024-01-15T14:30:25'), relative dates (e.g., '2 weeks ago', 'yesterday'), or absolute dates (e.g., '2024-01-15', 'Jan 15 2024') | |
| start_timestamp | No | Start timestamp for filtering commits. Accepts: ISO 8601 format (e.g., '2024-01-15T14:30:25'), relative dates (e.g., '2 weeks ago', 'yesterday'), or absolute dates (e.g., '2024-01-15', 'Jan 15 2024') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral information beyond the tool's basic purpose, such as whether it returns a list or respects truncation.
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 short sentence, which is concise but omits necessary details. It is not verbose, but could be more informative without losing conciseness.
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 log tool with four parameters and no output schema, the description should explain return values (e.g., list of commits with hash, message). It does not mention output format or the effect of timestamp filters, making it incomplete.
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 50% (two of four parameters have descriptions). The tool description does not add meaning to the parameters, e.g., that repo_path is required or that max_count limits output. It relies solely on the schema for parameter details.
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 'Shows the commit logs' clearly states the verb and resource, and it distinguishes from siblings like git_diff or git_show by focusing on the log. However, it is very brief and does not mention filtering or scope.
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?
No guidance is provided on when to use this tool vs alternatives such as git_show for individual commits or git_diff for changes. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unstages all staged changes
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which already signal mutation and potential data loss. The description confirms it unstages all changes but adds no further behavioral context, such as working directory being unaffected.
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, straightforward sentence with no extraneous information, which is appropriate for a simple tool. However, it might be too brief to be fully useful.
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 simplicity and single parameter, the description is moderately complete. It covers the core action but misses parameter details and fails to mention that only staged changes are affected, not working tree modifications.
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?
With 0% schema description coverage, the description does not explain the required 'repo_path' parameter. The agent receives no guidance on how to specify the repository path or any expected format.
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 specific verb 'unstages' and the resource 'all staged changes', which distinguishes it from sibling tools like git_add (stages) or git_diff_staged (shows staged diffs).
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, nor any context about prerequisites or post-conditions. It simply states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows the contents of a commit
| Name | Required | Description | Default |
|---|---|---|---|
| revision | Yes | ||
| repo_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds minimal behavioral context beyond 'shows', not elaborating on what 'contents' entails (e.g., diff, metadata).
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, concise sentence of 6 words with no filler. It is front-loaded but may sacrifice detail for brevity.
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?
Despite the tool's simplicity, the description omits parameter explanations, return format (no output schema), and usage context. It provides the core purpose but is insufficient for correct invocation.
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 0%, with no parameter descriptions in the schema. The description does not mention repo_path or revision, leaving their purpose and format entirely unexplained.
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 'Shows the contents of a commit' clearly states a specific verb and resource (contents of a commit). It differentiates from siblings like git_log (list commits) and git_diff (differences), though it doesn't explicitly contrast them.
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?
No guidance on when to use this tool versus siblings such as git_diff or git_log. The description does not mention prerequisites or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows the working tree status
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, fully covering safety and idempotency. The description adds no behavioral context beyond this, such as what specific information is shown or how it handles edge cases. It neither contradicts nor significantly extends 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core purpose efficiently, though it sacrifices detail for brevity.
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 lack of an output schema, the description should explain what the tool returns (e.g., list of changes, file states). It does not, leaving the agent to infer the output format. The description is insufficient for a tool that likely produces structured output, even with helpful annotations.
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 single parameter 'repo_path' lacks a description in both the schema (0% coverage) and the tool description. The description does not explain what repo_path is, its format, or how to specify it (e.g., absolute vs relative path). This is a significant gap given the parameter is required.
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 'Shows the working tree status' uses a specific verb ('Shows') and resource ('working tree status'), clearly distinguishing it from sibling tools like git_diff (which show diffs) or git_log (which shows history).
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 implies that the tool is used to inspect the current state of the working tree, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., git_diff, git_log) or when not to use it. The usage context is implied by the tool name and description but not elaborated.
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.
v1.0.0git_addgit_branchgit_checkoutgit_commitgit_create_branchgit_diffgit_diff_stagedgit_diff_unstagedgit_loggit_resetgit_showgit_statusEach tool targets a distinct Git operation: staging, committing, branching, diffing, logging, etc. The three diff variants are clearly separated by scope (general, staged, unstaged). No two tools have overlapping purposes.
All tools follow the 'git_<action>' pattern with lowercase snake_case. Verbs are clear and consistent (add, branch, checkout, commit, create_branch, diff, etc.), with no mixing of conventions.
12 tools cover the core local Git workflow without being excessive. The number is well-scoped for a focused Git assistant, allowing agents to perform common tasks without overwhelming options.
The set covers staging, committing, branching, and diffing, but lacks essential operations like merge, rebase, remote actions (push/pull/fetch), branch deletion, and repository initialization. These gaps limit the workflow to basic local operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that gives your AI access to the source code and docs of all public github repos
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
A Model Context Protocol server for Wix AI tools
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/modelcontextprotocol/git'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
