AIコーディングエージェントにgit履歴のスーパーパワーを与えます。
gitlog-mcpは、Model Context Protocol（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を使用すると、各ツールを手動で呼び出すUIが表示されます：
npx @modelcontextprotocol/inspector gitlog-mcp --repo .「
v1.2.0とv1.3.0の間で変更されたすべてのもののチェンジログを生成してください。」
「
src/parser.pyのこのバグの原因となった行を誰が導入し、なぜですか？」
「最近のコミットに基づいて、次のバージョンのリリースノートを草案してください。」
ツール | 説明 |
| コミット/タグ範囲のグループ化されたチェンジログ |
| 特定のコミットの意図と影響を説明 |
| ファイルの行レベルの属性 |
| 2つのタグ間のリリースノートを草案 |
| コントリビューター + チャーンの概要 |
| メッセージ/作成者/日付でコミットを検索 |
ターミナルよりもブラウザがお好みですか？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意図的に小さくしています。半日で全部読めます — それが特徴です。
プルリクエスト歓迎。小さく、焦点を絞り、十分にテストされた変更のみ。詳細は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.
