Dale superpoderes a tu agente de codificación de IA sobre el historial de git.
gitlog-mcp es un servidor del Protocolo de Contexto de Modelo (MCP) que permite a los agentes de IA (Claude Code, Cursor, Windsurf y cualquier cliente MCP) entender qué cambió en un repositorio — generar automáticamente registros de cambios, analizar confirmaciones, atribuir culpas y redactar notas de lanzamiento.
"¿Qué cambió en este repo?" es la pregunta que todo agente de IA responde mal. Esto lo corrige.
Los agentes de codificación de IA son excelentes para escribir código, pero notoriamente malos para conocer la historia de una base de código. Alucinan registros de cambios, atribuyen culpas incorrectamente y adivinan las notas de lanzamiento. gitlog-mcp les proporciona una ventana confiable y estructurada al git log — para que sus respuestas se basen en lo que realmente sucedió, no en lo inventado.
Related MCP server: Git Insight MCP
📝 Registro de cambios automático — genera un registro de cambios limpio y agrupado desde cualquier rango de etiqueta/confirmación
🔎 Análisis de confirmaciones — explica por qué ocurrió un cambio, no solo qué cambió
👤 Atribución de culpas — quién tocó qué y cuándo (con contexto)
🏷️ Notas de lanzamiento — redacta notas de lanzamiento a partir de diferencias entre etiquetas
📊 Salud del repositorio — frecuencia de confirmaciones, principales contribuidores, puntos críticos de cambio
🧱 Cero dependencias en tiempo de ejecución — solo stdlib de Python + el SDK de MCP, un archivo
# 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)¿Quieres también el panel web local? Es un extra opcional, no instalado por defecto:
pip install "gitlog-mcp[ui]". La instalación simplepip install gitlog-mcpsigue siendo tan libre de dependencias como siempre.
Instalando desde el código fuente (para contribuidores):
git clone https://github.com/ManiaSacha/gitlog-mcp.git && cd gitlog-mcp && pip install -e .— consulta CONTRIBUTING.md para más detalles.
{
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}.cursor/mcp.json){
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}{
"mcpServers": {
"gitlog": {
"command": "gitlog-mcp",
"args": ["--repo", "."]
}
}
}¿Quieres probar las herramientas directamente antes de conectar un agente? El MCP Inspector te proporciona una interfaz para llamar a cada herramienta manualmente:
npx @modelcontextprotocol/inspector gitlog-mcp --repo ."Genera un registro de cambios de todo lo que cambió entre
v1.2.0yv1.3.0."
"¿Quién introdujo esta línea problemática en
src/parser.pyy por qué?"
"Redacta notas de lanzamiento para la próxima versión basadas en las confirmaciones recientes."
Herramienta | Descripción |
| Registro de cambios agrupado para un rango de etiqueta/confirmación |
| Explica la intención y el impacto de una confirmación específica |
| Atribución a nivel de línea para un archivo |
| Redacta notas de lanzamiento entre dos etiquetas |
| Resumen de contribuidores y cambios |
| Encuentra confirmaciones por mensaje/autor/fecha |
¿Prefieres un navegador a una terminal? gitlog-mcp-ui sirve un pequeño panel local sobre el mismo código de lectura de git que usan las herramientas MCP — mismos datos, legibles para humanos.
pip install "gitlog-mcp[ui]"
gitlog-mcp-ui --repo /path/to/repoEsto imprime una URL (http://127.0.0.1:8765 por defecto) — ábrela en tu navegador; no se abrirá automáticamente.
Vista | Qué muestra |
Registro de cambios | Selector de rango de confirmaciones ( |
Salud del repositorio | Estadísticas de contribuidores, totales de confirmaciones |
Culpa | Atribución por archivo y por línea |
Solo lectura — no hay acciones de escritura en ningún lado. Solo local por construcción: se vincula únicamente a 127.0.0.1 (no hay una bandera --host, por lo que no puede exponerse a la red ni siquiera por accidente), y también valida el encabezado Host de cada solicitud, cerrando la brecha de reenlace de DNS que un simple enlace de bucle invertido no cubre. No se necesita autenticación, porque nada más que tu propia máquina puede alcanzarlo.
Es un extra opcional (pip install gitlog-mcp[ui]), no instalado por defecto. El servidor central gitlog-mcp tiene cero dependencias en tiempo de ejecución más allá del SDK de MCP, punto final — el panel no cambia eso. Es http.server de la stdlib, sin framework, sin dependencias adicionales propias.
gitlog-mcp (single file, ~300 lines)
├── FastMCP server (stdio transport)
├── GitRunner — thin wrapper over `git` CLI
└── Tools — each maps to a git subcommand + parsingDeliberadamente pequeño. Puedes leerlo todo en una tarde — eso es una característica.
Se aceptan solicitudes de extracción. Solo cambios pequeños, enfocados y bien probados. Consulta CONTRIBUTING.md.
El proceso de lanzamiento y el versionado están documentados en RELEASING.md.
Detección automática de --repo desde el directorio de trabajo actual
Salida JSON estructurada para todas las herramientas
Integración remota con GitHub/GitLab
Pruebas + insignia de CI
MIT © 2026 — construido en abierto, para la comunidad de código abierto.
Marca este repositorio con una estrella si quieres que los agentes de IA dejen de alucinar tu registro de cambios. ⭐
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.
