Verleihe deinem KI-Coding-Agenten Superkräfte über die Git-Historie.
gitlog-mcp ist ein Model Context Protocol (MCP)-Server, der es KI-Agenten (Claude Code, Cursor, Windsurf und jedem MCP-Client) ermöglicht zu verstehen, was sich in einem Repository geändert hat — automatisch Changelogs zu generieren, Commits zu analysieren, Blame zuzuweisen und Release-Notes zu entwerfen.
„Was hat sich in diesem Repository geändert?“ ist die Frage, die jeder KI-Agent falsch beantwortet. Das hier behebt es.
KI-Coding-Agenten sind großartig darin, Code zu schreiben, aber berüchtigt schlecht darin, die Historie einer Codebasis zu kennen. Sie halluzinieren Changelogs, weisen Blame falsch zu und raten bei Release-Notes. gitlog-mcp gibt ihnen ein zuverlässiges, strukturiertes Fenster in git log — damit ihre Antworten auf dem basieren, was tatsächlich passiert ist, und nicht erfunden sind.
Related MCP server: Git Insight MCP
📝 Auto-Changelog — generiere einen sauberen, gruppierten Changelog aus jedem Tag/Commit-Bereich
🔎 Commit-Analyse — erkläre warum eine Änderung passiert ist, nicht nur was geändert wurde
👤 Blame-Zuordnung — wer hat was und wann berührt (mit Kontext)
🏷️ Release-Notes — erstelle Release-Notes aus Tag-zu-Tag-Diffs
📊 Repository-Gesundheit — Commit-Häufigkeit, Top-Mitwirkende, Änderungshotspots
🧱 Keine Laufzeitabhängigkeiten — reine Python-Standardbibliothek + das MCP-SDK, eine Datei
# 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)Möchtest du auch das lokale Web-Dashboard? Es ist ein optionales Extra, standardmäßig nicht installiert:
pip install "gitlog-mcp[ui]". Das einfachepip install gitlog-mcpbleibt genauso abhängigkeitsfrei wie immer.
Installation aus dem Quellcode (für Mitwirkende):
git clone https://github.com/ManiaSacha/gitlog-mcp.git && cd gitlog-mcp && pip install -e .— siehe CONTRIBUTING.md für Details.
{
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}.cursor/mcp.json){
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}{
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}Möchtest du die Tools direkt ausprobieren, bevor du einen Agenten anschließt? Der MCP Inspector bietet eine Benutzeroberfläche, um jedes Tool von Hand aufzurufen:
npx @modelcontextprotocol/inspector gitlog-mcp --repo .„Generiere einen Changelog von allem, was sich zwischen
v1.2.0undv1.3.0geändert hat.“
„Wer hat diese fehlerhafte Zeile in
src/parser.pyeingeführt und warum?“
„Erstelle Release-Notes für die nächste Version basierend auf den letzten Commits.“
Tool | Beschreibung |
| Gruppierter Changelog für einen Commit/Tag-Bereich |
| Erklärt die Absicht und Auswirkung eines bestimmten Commits |
| Zeilenweise Zuordnung für eine Datei |
| Erstellt Release-Notes zwischen zwei Tags |
| Zusammenfassung der Mitwirkenden + Änderungen |
| Finde Commits nach Nachricht/Autor/Datum |
Bevorzugst du einen Browser gegenüber einem Terminal? gitlog-mcp-ui bietet ein kleines lokales Dashboard auf Basis des gleichen Git-lesenden Codes, den die MCP-Tools verwenden – gleiche Daten, menschenlesbar.
pip install "gitlog-mcp[ui]"
gitlog-mcp-ui --repo /path/to/repoDies gibt eine URL aus (standardmäßig http://127.0.0.1:8765) — öffne sie in deinem Browser; der Server öffnet sie nicht für dich.
Ansicht | Was angezeigt wird |
Changelog | Bereichsauswahl für Commits ( |
Repository-Gesundheit | Mitwirkendenstatistiken, Commit-Gesamtsummen |
Blame | Datei- und zeilenweise Zuordnung |
Schreibgeschützt — keine Schreibaktionen irgendwo. Nur lokal durch Konstruktion: bindet nur an 127.0.0.1 (es gibt kein --host-Flag, kann also nicht einmal versehentlich im Netzwerk ausgesetzt werden), und validiert zusätzlich den Host-Header jeder Anfrage, um die DNS-Rebinding-Lücke zu schließen, die eine Loopback-Bindung allein nicht abdeckt. Keine Authentifizierung erforderlich, da nichts außer deinem eigenen Rechner darauf zugreifen kann.
Es ist ein optionales Extra (pip install gitlog-mcp[ui]), standardmäßig nicht installiert. Der Kernserver von gitlog-mcp hat null Laufzeitabhängigkeiten außer dem MCP-SDK, Punkt — das Dashboard ändert das nicht. Es ist http.server aus der Standardbibliothek, kein Framework, keine eigenen zusätzlichen Abhängigkeiten.
gitlog-mcp (single file, ~300 lines)
├── FastMCP server (stdio transport)
├── GitRunner — thin wrapper over `git` CLI
└── Tools — each maps to a git subcommand + parsingBewusst klein. Du kannst das Ganze an einem Nachmittag durchlesen — das ist ein Feature.
Pull-Requests sind willkommen. Nur kleine, fokussierte, gut getestete Änderungen. Siehe CONTRIBUTING.md.
Freigabeprozess und Versionierung sind in RELEASING.md dokumentiert.
--repo-Automatikerkennung aus dem aktuellen Arbeitsverzeichnis
Strukturierte JSON-Ausgabe für alle Tools
GitHub/GitLab-Remote-Integration
Tests + CI-Badge
MIT © 2026 — im Offenen gebaut, für die Open-Source-Community.
Star dieses Repository, wenn du möchtest, dass KI-Agenten aufhören, deinen Changelog zu halluzinieren. ⭐
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.
