赋予你的 AI 编程助手超强的 Git 历史理解能力。
gitlog-mcp 是一个基于模型上下文协议（MCP）的服务器，让 AI 助手（如 Claude Code、Cursor、Windsurf 以及任何 MCP 客户端）能够理解仓库中的变更历史——自动生成变更日志、分析提交、定位责任人并草拟发布说明。
“这个仓库发生了什么变化？”是所有 AI 助手都会答错的问题。这个工具解决了它。
AI 编程助手在编写代码方面很出色，但在了解代码库的历史方面却声名狼藉。它们会凭空编造变更日志、错误定位责任人并胡乱猜测发布说明。gitlog-mcp 为它们提供了一个可靠、结构化的 git log 窗口——让它们的答案基于实际发生的事情，而非臆想。
Related MCP server: Git Insight MCP
📝 自动变更日志 — 从任意标签/提交范围生成清晰分组的变更日志
🔎 提交分析 — 解释变更发生的原因，而不仅仅是内容
👤 责任定位 — 谁、在何时、修改了哪些内容（附上下文）
🏷️ 发布说明 — 根据标签间的差异草拟发布说明
📊 仓库健康度 — 提交频率、主要贡献者、代码变更热点
🧱 零运行时依赖 — 纯 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)想要本地 Web 仪表板吗？这是一个可选附加功能，默认不会安装：
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 提供了一个界面，让你可以手动调用每个工具：
npx @modelcontextprotocol/inspector gitlog-mcp --repo .“生成
v1.2.0到v1.3.0之间所有变更的变更日志。”
“谁引入了
src/parser.py中这一有问题的代码行，原因是什么？”
“根据最近的提交，为下一版本草拟发布说明。”
工具 | 描述 |
| 为提交/标签范围生成分组的变更日志 |
| 解释特定提交的意图和影响 |
| 针对文件的行级责任定位 |
| 在两个标签之间草拟发布说明 |
| 贡献者 + 变更量总结 |
| 按消息/作者/日期搜索提交 |
更喜欢浏览器而非终端？gitlog-mcp-ui 在 MCP 工具所使用的相同 Git 读取代码基础上，提供一个本地小型仪表板——相同的数据，人类可读的格式。
pip install "gitlog-mcp[ui]"
gitlog-mcp-ui --repo /path/to/repo这会打印一个 URL（默认是 http://127.0.0.1:8765）——在浏览器中打开它；它不会自动为你打开。
视图 | 显示内容 |
变更日志 | 提交范围选择器（ |
仓库健康度 | 贡献者统计、提交总数 |
责任定位 | 针对每个文件、每行的归属信息 |
只读——没有任何写入操作。设计上仅限本地访问：只绑定到 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.
