A
licenseA
qualityB
maintenanceA local Git intelligence MCP server that provides deep repository analytics including hotspots, temporal coupling, knowledge maps, churn analysis, and risk scoring for AI agents.
12
12
MIT
Git Forensics MCP
by davidorex
The Git Forensics MCP server is a specialized tool for deep analysis of git repositories with these capabilities:
Branch Overview: Provides insights into branch states, relationships, commit information, and statistical summaries of branch activities
Time Period Analysis: Analyzes development activity within specific date ranges, categorizes commits (feature, fix, refactor, docs), and generates activity summaries
File Changes Analysis: Tracks changes to specific files across branches, identifies potential conflicts, assesses risks, and recommends review order based on risk levels
Merge Recommendations: Determines optimal merge strategies, evaluates conflict risks, identifies code hotspots, and provides step-by-step merge guidance
All outputs are provided in JSON format for further integration.
Provides deep git repository analysis tools for investigating branch relationships, development patterns, file changes, and merge strategies without requiring GitHub or other git hosting services.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Git Forensics MCPanalyze file changes in src/ for main and feature branches"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Git Forensics MCP
A specialized Model Context Protocol (MCP) server for deep git repository investigation and analysis. This forensics tool provides detailed insights into repository history, branch relationships, and development patterns, focusing solely on git repository analysis rather than general GitHub or git operations.
Features
The server provides four main analysis tools:
Branch Overview (
get_branch_overview)Provides high-level overview of branch states and relationships
Analyzes last commits, commit counts, and merge bases
Generates statistical summaries of branch activities
Time Period Analysis (
analyze_time_period)Analyzes detailed development activity in specific time periods
Categorizes commits (feature, fix, refactor, docs, other)
Provides activity summaries with commit patterns
File Changes Analysis (
analyze_file_changes)Tracks changes to specific files across branches
Identifies potential conflict areas
Provides risk assessment for file modifications
Generates recommended review order based on risk levels
Merge Recommendations (
get_merge_recommendations)Determines optimal merge strategies
Assesses conflict risks
Identifies code hotspots
Provides step-by-step merge guidance
Related MCP server: git-intel
Input Parameters
Each tool requires specific parameters:
repoPath: Path to the git repositorybranches: Array of branch names to analyzeoutputPath: Path where analysis results will be writtenAdditional tool-specific parameters:
timeRange: Start and end dates for period analysisfiles: Array of file paths for file change analysis
Output Format
All tools output JSON files containing:
Detailed analysis results
Summary statistics
Risk assessments (where applicable)
Recommendations based on analysis
Technical Details
Built with TypeScript
Uses MCP SDK for server implementation
Executes git commands through child processes
Provides error handling and validation
Runs on stdio transport
Dependencies
@modelcontextprotocol/sdk
Node.js
Git (must be installed and accessible)
Usage
The server runs as an MCP service and can be integrated with any MCP-compatible client. All analysis results are written to specified output files in JSON format.
Contributing and License
This project is licensed under the Apache License, Version 2.0 - see the LICENSE.txt file for details.
Collaboration Welcome
Forks and contributions welcome.
All contributions will be under the Apache License 2.0. This permissive license allows you to:
Use the code commercially
Modify and distribute the code
Create derivative works
Include in other projects
Copyright 2025. Licensed under the Apache License, Version 2.0; you may not use this project except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Available Tools
4 toolsanalyze_file_changesC
Analyze changes to specific files across branches
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to git repository | |
| branches | Yes | Branches to analyze | |
| files | Yes | Files to analyze | |
| outputPath | Yes | Path to write analysis output |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states what the tool does at a high level. It doesn't explain what 'analyze' entails (e.g., type of analysis, output format, whether it writes to disk, performance implications, or error handling), leaving significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of analyzing file changes across branches (a non-trivial operation), no annotations, and no output schema, the description is insufficient. It lacks details on what the analysis produces, how results are formatted, or any behavioral traits, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any additional meaning or context about the parameters beyond what's in the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('analyze changes') and target ('specific files across branches'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'analyze_time_period' or 'get_branch_overview', which might also involve analysis operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'analyze_time_period' or 'get_branch_overview'. There's no mention of prerequisites, exclusions, or comparative contexts, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_time_periodC
Analyze detailed development activity in a specific time period
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to git repository | |
| branches | Yes | Branches to analyze | |
| timeRange | Yes | ||
| outputPath | Yes | Path to write analysis output |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'analyzes' activity, implying a read-only operation, but doesn't clarify if it writes output (as suggested by the 'outputPath' parameter), requires specific permissions, has rate limits, or what the analysis entails. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool with 4 parameters (including a nested object), the description is incomplete. It doesn't explain what 'analyze' means in practice, what the output contains, or how it differs from siblings, leaving significant gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 out of 4 parameters have descriptions), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the format of 'timeRange' or the nature of 'outputPath'. It doesn't compensate for the 25% gap in coverage for the nested 'timeRange' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'analyze' and the resource 'detailed development activity in a specific time period', which is specific enough to understand the tool's function. However, it doesn't explicitly differentiate from sibling tools like 'analyze_file_changes' or 'get_branch_overview', which might also analyze development activity but with different scopes or methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'analyze_file_changes' or 'get_branch_overview'. It mentions analyzing 'detailed development activity' but doesn't specify what that entails or when this tool is preferred over others, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_branch_overviewC
Get high-level overview of branch states and relationships
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to git repository | |
| branches | Yes | Branches to analyze | |
| outputPath | Yes | Path to write analysis output |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get' and 'write analysis output' (via outputPath), implying read and write operations, but doesn't specify if this is safe, requires permissions, or has side effects like file creation. Critical details like error handling or output format are missing, leaving gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy to grasp quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a git analysis tool with three parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'high-level overview' entails, how output is formatted, or any behavioral traits like file writing implications. This leaves significant gaps for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (repoPath, branches, outputPath) with clear descriptions. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('high-level overview of branch states and relationships'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'analyze_file_changes' or 'get_merge_recommendations', which also seem to analyze git repositories but focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lacks context about prerequisites, such as needing a valid git repository, or exclusions, like not handling specific branch states. It doesn't reference sibling tools or suggest scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_merge_recommendationsC
Get detailed merge strategy recommendations
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to git repository | |
| branches | Yes | Branches to analyze | |
| outputPath | Yes | Path to write analysis output |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Get detailed merge strategy recommendations' but doesn't specify what 'detailed' entails, whether it's read-only or has side effects, if it requires specific permissions, or how it handles errors. For a tool with 3 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for its purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'merge strategy recommendations' include, how results are returned or written to outputPath, or any behavioral traits. For a tool that likely involves analysis and output generation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the parameters (repoPath, branches, outputPath). The description doesn't add any meaning beyond the schema, such as explaining how branches are analyzed or what format the output uses. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed merge strategy recommendations', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'analyze_file_changes' or 'get_branch_overview', which might also involve repository analysis. The purpose is specific but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'analyze_file_changes' or 'analyze_time_period'. There's no mention of prerequisites, context, or exclusions. It's a basic statement of function without usage context.
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. Dates show when Glama detected each change.
4 tool updates
- First observed
analyze_file_changes - First observed
analyze_time_period - First observed
get_branch_overview - First observed
get_merge_recommendations
TDQS
B3.3/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: analyze_file_changes focuses on file-level changes, analyze_time_period covers time-based activity, get_branch_overview provides branch states, and get_merge_recommendations handles merge strategies. The descriptions make it easy to differentiate between them.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (analyze_file_changes, analyze_time_period, get_branch_overview, get_merge_recommendations) with clear, descriptive names. There are no deviations in naming conventions.
Tool Count4/5
With 4 tools, the count is reasonable for a Git forensics server, though it feels slightly minimal. Each tool appears to serve a distinct function, but the scope might benefit from a few more tools for broader coverage without being excessive.
Completeness3/5
The tools cover analysis and recommendations well, but there are notable gaps for a Git forensics domain, such as missing CRUD operations (e.g., no tools for creating or modifying data) and limited coverage of common forensic tasks like commit history analysis or user activity tracking. Agents might need workarounds for some scenarios.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A MCP server built for developers enabling Git based project management with project and personal…
Create, deploy, and operate MCP servers directly from your GitHub repositories.
MCP Server for JFrog, providing tools for development and artifact management.
Related MCP Servers
- AlicenseAqualityCmaintenanceA local Git intelligence MCP server that provides deep repository analytics including hotspots, churn, knowledge maps, and risk scoring, all computed from commit history without data leaving your machine.12MIT
- AlicenseNot gradedqualityCmaintenanceA production-grade MCP server for local git repositories that provides tools for code search, git history analysis, complexity metrics, test discovery, and dependency management.MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that gives AI assistants deep understanding of your local Git repositories, providing instant repo overviews, change summaries, blame analysis, changelogs, branch health checks, and history search.62MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidorex/git-forensics-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server