AI 코딩 에이전트에 git 기록에 대한 초능력을 부여하세요.
gitlog-mcp는 Model Context Protocol (MCP) 서버로, AI 에이전트(Claude Code, Cursor, Windsurf 및 모든 MCP 클라이언트)가 리포지토리에서 변경된 내용을 이해할 수 있게 해줍니다. — 자동으로 체인지로그 생성, 커밋 분석, 비난(blame) 추적, 릴리스 노트 작성.
"이 리포지토리에서 무엇이 변경되었나요?"는 모든 AI 에이전트가 틀리는 질문입니다. 이 도구가 해결합니다.
AI 코딩 에이전트는 코드 작성에는 뛰어나지만 코드베이스의 기록을 아는 데는 유명할 정도로 취약합니다. 체인지로그를 환각(hallucinate)하고, 비난(blame)을 잘못 추정하며, 릴리스 노트를 추측합니다. gitlog-mcp는 이들에게 git log에 대한 신뢰할 수 있고 구조화된 창을 제공하여, 답변이 허구가 아닌 실제 발생한 내용에 기반하도록 합니다.
Related MCP server: Git Insight MCP
📝 자동 체인지로그 — 모든 태그/커밋 범위에서 깔끔하고 그룹화된 체인지로그 생성
🔎 커밋 분석 — 변경된 내용뿐 아니라 왜 변경이 발생했는지 설명
👤 비난(blame) 추적 — 누가 무엇을, 언제 수정했는지 (컨텍스트 포함)
🏷️ 릴리스 노트 — 태그 간 차이에서 릴리스 노트 초안 작성
📊 리포지토리 건강 — 커밋 빈도, 주요 기여자, 변경 핫스팟
🧱 런타임 의존성 제로 — 순수 Python 표준 라이브러리 + MCP SDK, 단일 파일
# 1. Install from PyPI
pip install gitlog-mcp
# 2. Run standalone (for testing) — defaults to the current directory
gitlog-mcp
gitlog-mcp --repo /path/to/your/repo
# 3. Or add directly to your agent's MCP config (see below)로컬 웹 대시보드도 원하시나요? 선택적 추가 기능이며 기본 설치에 포함되지 않습니다:
pip install "gitlog-mcp[ui]". 일반pip install gitlog-mcp는 그대로 의존성 제로를 유지합니다.
소스에서 설치(기여자용):
git clone https://github.com/ManiaSacha/gitlog-mcp.git && cd gitlog-mcp && pip install -e .— 자세한 내용은 CONTRIBUTING.md를 참조하세요.
{
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}.cursor/mcp.json){
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}{
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}에이전트를 연결하기 전에 도구를 직접 사용해보고 싶으신가요? MCP Inspector는 각 도구를 수동으로 호출할 수 있는 UI를 제공합니다:
npx @modelcontextprotocol/inspector gitlog-mcp --repo ."
v1.2.0과v1.3.0사이의 모든 변경사항에 대한 체인지로그를 생성해줘."
"누가
src/parser.py의 이 버그 있는 줄을 도입했고 왜 그랬지?"
"최근 커밋을 기반으로 다음 버전의 릴리스 노트 초안을 작성해줘."
도구 | 설명 |
| 커밋/태그 범위에 대한 그룹화된 체인지로그 |
| 특정 커밋의 의도와 영향을 설명 |
| 파일에 대한 라인 수준의 비난(blame) 추적 |
| 두 태그 사이의 릴리스 노트 초안 작성 |
| 기여자 + 변경 요약 |
| 메시지/작성자/날짜로 커밋 검색 |
터미널보다 브라우저를 선호하시나요? gitlog-mcp-ui는 MCP 도구가 사용하는 동일한 git 읽기 코드 위에 작은 로컬 대시보드를 제공합니다 — 동일한 데이터, 사람이 읽을 수 있는 형식.
pip install "gitlog-mcp[ui]"
gitlog-mcp-ui --repo /path/to/repo이 명령은 URL(http://127.0.0.1:8765 기본값)을 출력합니다 — 브라우저에서 열면 됩니다; 자동으로 열리지 않습니다.
보기 | 표시 내용 |
체인지로그 | 커밋 범위 선택기 ( |
리포지토리 건강 | 기여자 통계, 커밋 총계 |
비난(blame) | 파일별, 라인별 추적 |
읽기 전용 — 어디에도 쓰기 작업이 없습니다. 설계 상 로컬 전용: 127.0.0.1에만 바인딩되며(--host 플래그가 없어 우발적으로도 네트워크에 노출될 수 없음), 모든 요청의 Host 헤더도 검증하여 루프백 바인드만으로는 막을 수 없는 DNS-리바인딩 갭을 닫습니다. 인증이 필요하지 않습니다. 자신의 기기만 접근할 수 있기 때문입니다.
선택적 추가 기능(pip install gitlog-mcp[ui])이며 기본 설치에 포함되지 않습니다. 핵심 gitlog-mcp 서버는 MCP SDK 외에 런타임 의존성이 전혀 없습니다. 대시보드는 이를 변경하지 않습니다. 표준 라이브러리의 http.server를 사용하며, 프레임워크나 추가 의존성이 없습니다.
gitlog-mcp (single file, ~300 lines)
├── FastMCP server (stdio transport)
├── GitRunner — thin wrapper over `git` CLI
└── Tools — each maps to a git subcommand + parsing의도적으로 작습니다. 오후에 전체를 읽을 수 있습니다 — 그것이 기능입니다.
PR 환영합니다. 작고 집중적이며 잘 테스트된 변경만 부탁드립니다. CONTRIBUTING.md 참조.
릴리스 프로세스와 버전 관리에 대한 내용은 RELEASING.md에 문서화되어 있습니다.
--repo 현재 작업 디렉토리에서 자동 감지
모든 도구에 대한 구조화된 JSON 출력
GitHub/GitLab 원격 통합
테스트 + CI 배지
MIT © 2026 — 오픈 소스 커뮤니티를 위해 공개적으로 구축되었습니다.
AI 에이전트가 체인지로그를 환각하지 못하게 하려면 이 리포지토리에 별표를 눌러주세요. ⭐
Explain a specific commit's intent and impact.
| Name | Required | Description | Default |
|---|---|---|---|
| sha | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'explain intent and impact' without disclosing whether the analysis is AI-generated, static, or requires external calls. It does not state if the tool is read-only or if it has side effects. The description adds minimal behavioral context beyond the tool name.
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 of 6 words, which is efficient but at the cost of critical information. While it avoids redundancy, it does not earn its place because it omits parameter details and usage guidance. For a tool with one parameter and no annotations, a slightly longer but more informative description would be better.
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?
The tool has an output schema (not shown), so return values need not be described. However, with a single parameter and no parameter description, the description is incomplete. The agent can infer the parameter's purpose from the tool name, but the lack of any parameter guidance makes it minimally adequate. Sibling tools are listed but not referenced.
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 input schema has one parameter 'sha' with no description (0% schema coverage). The description does not mention this parameter, leaving the agent to infer that 'sha' is a commit hash. No format, examples, or constraints are provided. The description adds no value beyond the schema, which already lacks detail.
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 action ('explain') and the resource ('a specific commit'), and specifies the scope ('intent and impact'). It distinguishes from sibling tools like 'changelog' (list changes) and 'search_commits' (multiple commits) by focusing on a single commit's reasoning. However, it could explicitly mention the SHA parameter to reinforce the single-commit 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 versus alternatives. Siblings like 'blame_file' or 'repo_health' serve different purposes, but the description does not explicitly state when to prefer 'analyze_commit' over 'changelog' or 'search_commits' for understanding a commit. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Line-level attribution for a file (who, when, which commit).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure but only states the output content (who, when, which commit). It does not reveal constraints such as requiring a tracked file, performance implications, or whether the blame is for the latest commit only.
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 with no fluff. While concise, it is slightly under-specific (e.g., missing 'Returns blame information for each line'), but every word contributes to the core purpose.
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 (one required parameter and an output schema), the description is minimally adequate. However, it omits context such as the requirement that the file be part of a Git repository and could benefit from a brief note on expected input format.
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 schema has 0% description coverage and the single parameter 'path' is not elaborated in the description. The description adds no meaning beyond the schema, failing to specify that the path should be relative to the repository root or that the file must exist in the version history.
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 'Line-level attribution for a file (who, when, which commit)' clearly states the tool's purpose using a specific verb ('attribution') and resource ('file'). It distinguishes the tool from siblings like changelog and search_commits by focusing on per-line metadata.
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 or when not to use this tool versus alternatives. No conditions, prerequisites, or exclusions are mentioned, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a grouped changelog for a commit range (e.g. v1.2.0..v1.3.0).
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | HEAD~20 | |
| until | No | HEAD |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only indicates the output is 'grouped', but does not mention read-only nature, authentication needs, rate limits, or side effects. The agent gains little insight beyond the basic function.
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, well-front-loaded sentence with no waste. It efficiently conveys the core action. However, the brevity sacrifices necessary detail that could be added without much length.
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 two optional parameters and no annotations, the description is insufficient. Even with an output schema, the agent lacks usage guidelines and parameter semantics. The tool is simple, but the description leaves ambiguity about how to specify the range correctly.
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%, so the description must compensate. It mentions a commit range example ('v1.2.0..v1.3.0') which hints at the 'since' and 'until' parameters, but does not explicitly map them or explain their formats. The default values ('HEAD~20', 'HEAD') are not explained.
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 'generate' and the resource 'grouped changelog', and specifies the scope 'for a commit range' with an example format. However, it does not explicitly differentiate from siblings like release_notes, though the purpose is distinct.
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 vs. alternative sibling tools (e.g., release_notes, search_commits). The description implies usage for commit ranges but offers no exclusions or conditional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft release notes between two tags.
| Name | Required | Description | Default |
|---|---|---|---|
| to_tag | Yes | ||
| from_tag | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'Draft release notes', which is vague—does it create a file, output text, or modify something? No side effects, authentication needs, or rate limits are mentioned, making it insufficient for safe agent execution.
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 extremely concise (one sentence, six words), which is good for quick scanning. However, it sacrifices essential information—critical details about behavior, usage, and parameters are missing, so it is not 'appropriately sized' for the tool's context.
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 has two required parameters, no annotations, and an output schema (which could return draft content), the description is too brief. It fails to mention what the output contains, how it behaves, or any constraints, leaving the agent underinformed 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%, so the description must compensate. It implies that 'from_tag' and 'to_tag' define a range, but does not specify which is earlier/later or any format constraints. This minimal guidance leaves ambiguity about parameter ordering and expected values.
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 'Draft' and the resource 'release notes' with scope 'between two tags', making the purpose easy to grasp. However, it does not differentiate from the sibling tool 'changelog', which may have overlapping functionality, so a 5 is not justified.
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 versus alternatives like 'changelog' or 'search_commits'. There is no mention of prerequisites (e.g., tags must exist) or when not to use it, leaving the agent without contextual decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Contributor + churn summary for the repo.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full responsibility for disclosing behavioral traits. It only states 'Contributor + churn summary', implying a read operation, but does not mention safety, required permissions, rate limits, or any side effects. For a tool with zero annotation coverage, this is insufficient 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 extremely concise at one sentence, but it is vague and lacks structure. It does not front-load the most critical information (e.g., the verb or output format). While it wastes no words, it could be more informative without increasing length significantly (e.g., 'Retrieves a summary of contributor activity and churn metrics for the repository').
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?
The tool has no parameters and an output schema (existence noted), so the description does not need to detail return values. However, 'Contributor + churn summary' is vague—it does not specify the time period, metrics included, or how the summary is structured. For a tool with simple inputs, this level of completeness is minimally adequate but could be improved.
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 input schema has no parameters, so schema description coverage is 100% by default. The description does not need to add parameter meaning, and the baseline for 0 parameters is 4. The description is neutral—it does not contradict or enhance parameter semantics, but it is not required to.
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 'Contributor + churn summary for the repo.' clearly indicates the tool returns a summary of contributor and churn metrics. It uses a specific resource (repo) and implies a retrieval action, which distinguishes it from siblings like 'changelog' or 'analyze_commit' that focus on individual commits or logs. However, it lacks a verb (e.g., 'get' or 'retrieve') and does not explicitly contrast with siblings, slightly reducing clarity.
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 versus sibling tools like 'changelog', 'analyze_commit', 'blame_file', 'release_notes', or 'search_commits'. The description does not mention context, prerequisites, or alternatives. Without any usage instructions, the agent must infer applicability from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find commits by message, author, or date.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states it can search by message, author, or date, but does not clarify how the 'query' parameter is interpreted (e.g., does it accept regex, multiple terms, or date formats?). It also does not mention potential side effects (none expected) or pagination 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?
The description is a single short sentence, which is concise. However, it is too brief to cover the necessary details for a tool with no annotations and low schema coverage, making it feel underspecified rather than optimally concise.
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 has one required parameter with no schema description, no annotations, and an output schema (details not shown), the description is incomplete. It does not explain the expected format of the 'query' parameter, the return structure, or any limitations. With sibling tools like 'analyze_commit' and 'blame_file', more context is needed to differentiate usage.
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%, so the description must compensate. It mentions that commits can be found by message, author, or date, but does not explain how to encode these in the single 'query' parameter (e.g., using prefixes like 'author:'). This leaves the agent guessing how to use the parameter effectively.
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 tool finds commits and specifies the search dimensions (message, author, or date). It distinguishes itself from sibling tools like 'changelog' or 'analyze_commit' by indicating a general search capability, though it could be more explicit about the 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?
The description provides no guidance on when to use this tool versus siblings like 'analyze_commit' (for detailed analysis) or 'changelog' (for release notes). It does not mention limitations, such as whether the search is across a repository or workspace, or what happens if no results are found.
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.
v0.1.3analyze_commitblame_filechangelogrelease_notesrepo_healthsearch_commitsScored across 6 tools
Most tools have distinct purposes: changelog vs. release_notes share overlap in generating summaries from commit ranges/tags, which could cause confusion. However, the others are clearly separated.
All tool names use a consistent verb_noun pattern (changelog is a noun but functions as a verb, minor deviation). Names are clear and predictable.
6 tools is well-scoped for a Git log/analysis server, covering key operations without bloat.
Covers commit analysis, search, blame, release notes, and health metrics. A possible gap is direct diff retrieval between commits, but core workflows are well-supported.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Repo intel for AI coding agents: overview, PRs, contributors, hot files, CI, deps. Remote MCP.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
