git-commit-aider MCP Server
Servidor MCP git-commit-aider
Realice confirmaciones de Git en nombre de la IA, para que pueda realizar un seguimiento de la contribución de la IA en su base de código.
Este es un servidor MCP basado en TypeScript que proporciona una herramienta para confirmar cambios programados en un repositorio Git mientras agrega "(aider)" al nombre del confirmador.
Características
Este servidor MCP proporciona solo una herramienta:
commit_staged – Confirma los cambios programados con un mensaje específico.
Toma
message(cadena, obligatorio) como mensaje de confirmación.Toma
cwd(cadena, opcional) para especificar el directorio de trabajo para el comando git.Añade "(aider)" al nombre del confirmador automáticamente.
Lee el nombre del confirmador y el correo electrónico de las variables de entorno (
GIT_COMMITTER_NAME,GIT_COMMITTER_EMAIL) si están configuradas; de lo contrario, recurre agit config user.nameygit config user.email.
Con esta herramienta instalada en tu editor de código, puedes indicarle a la IA algo como:
Confirma los cambios por mí
Esto suele suceder después de que la IA ha realizado algunos cambios en su base de código, por lo que a menudo la IA puede proporcionar un buen mensaje de confirmación desde el contexto.
Las confirmaciones con "(aider)" se pueden detectar con el comando aider --stats , que le mostrará la contribución de IA en su base de código.
Related MCP server: Git Polite
Instalación
Para utilizar este servidor, agregue su configuración a su archivo de configuración MCP.
{
"mcpServers": {
"git-commit-aider": {
"command": "npx",
"args": ["mcp-git-commit-aider"]
}
}
}La información del confirmador se recupera de:
Variables de entorno
GIT_COMMITTER_NAMEyGIT_COMMITTER_EMAIL, que siguen la convención de git .Salida de los comandos
git config user.nameygit config user.email.
Desarrollo
Instalar dependencias:
npm installConstruir el servidor:
npm run buildPara desarrollo con reconstrucción automática:
npm run watchConfiguración de MCP de ejemplo:
{
"mcpServers": {
"git-commit-aider": {
"command": "node",
"args": [
"/path/to/git-commit-aider/build/index.js"
]
}
}
}(Reemplace /path/to/git-commit-aider con la ruta real a este directorio del servidor).
Depuración
Dado que los servidores MCP se comunican a través de stdio, la depuración puede ser complicada. Recomendamos usar el Inspector MCP , disponible como script de paquete:
npm run inspectorEl Inspector proporcionará una URL para acceder a las herramientas de depuración en su navegador.
Available Tools
1 toolcommit_stagedA
Commit staged changes with a specific message, appending "(aider)" to the committer name.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The commit message. | |
| cwd | No | Optional: The working directory for the git command (defaults to the workspace root). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the committer name is modified, which is a behavioral side effect. However, without annotations, the description carries the full burden. It could be more explicit about the exact impact (e.g., 'the commit author will be altered'), but the provided detail is adequate for a simple operation.
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?
Single sentence that is front-loaded and contains no wasted words. Every word earns its place, efficiently conveying the core behavior.
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?
For a simple git commit tool with no output schema, the description covers the main action and a notable side effect. However, it omits details like success confirmation or error behavior. Given low complexity, it is nearly complete.
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 coverage is 100% and the description does not add meaning beyond the schema. Both parameters (message and cwd) are already described in the schema, so the description adds no extra context.
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?
Clearly states the tool commits staged changes with a message, and specifies a unique behavioral tweak (appending '(aider)' to committer name). The verb and resource are explicit, and with no sibling tools, differentiation is not needed.
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 tool versus alternatives, such as other git commands. Since there are no siblings, the guidance is less critical, but still absent; no prerequisites or limitations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
commit_staged
TDQS
Scored across 1 tool
With only one tool, there is no ambiguity. The tool 'commit_staged' has a clear and distinct purpose.
The single tool follows a consistent verb_noun pattern ('commit_staged'), so naming is trivially consistent.
The server has only one tool, which feels thin for a git commit aider. A typical scope would include staging, status, and other related operations.
The tool surface is severely incomplete. It only offers commit_staged, missing essential operations like staging, status, branching, or commit management, which will likely cause agent failures.
Maintenance
Related MCP Connectors
Edit your Overleaf LaTeX projects from Claude and ChatGPT; every change is a real Git commit.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Pre-commit code quality guardian. Detects semantic drift in AI-generated code.
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to interact with local Git repositories for operations like status, commits, branching, and diffs, plus GitHub API integration for managing pull requests when authenticated.-
- AlicenseAqualityCmaintenanceEnables AI agents to intelligently organize Git changes into clean, focused commits with autopilot mode or surgical line-by-line staging precision. Supports partial staging of untracked files and handles large diffs with smart truncation.51MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to create conventional Git commits, update changelogs, and optionally push changes to remote repositories.22MIT
- FlicenseBqualityDmaintenanceEnables AI-powered code editing and development tasks through natural language conversations with Claude, using Aider's capabilities for improving code, adding features, fixing bugs, refactoring, and checking status.51-