Allows browsing and analyzing git commit history, including commit messages, diffs, authorship, and timelines to understand code/configuration changes.
Click on "Deploy 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-log-mcp show commit history for the auth module since last week"
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.
FastMCP server exposing a single typed tool, git_log. Use this tool to
investigate when a code/configuration change happened and infer why it happened
from commit history. Choose it when you need commit timelines, authorship
context, or intent signals from commit messages and diffs for a specific module
or identifier. It is not for repository file content reads or branch
manipulation; it is for history analysis and change attribution.
From the project root, run:
uv syncThen configure your MCP client to use the full path to .venv/bin/git-log-mcp.
Example Roo Code MCP configuration:
{
"mcpServers": {
"git-log": {
"command": "/full/path/to/.venv/bin/git-log-mcp"
}
}
}Related MCP server: GitHub MCP Server
Run tests:
pytest -qUse this tool to investigate when a code/configuration change happened and infer why it happened from commit history. Choose it when you need commit timelines, authorship context, or intent signals from commit messages and diffs for a specific module or identifier. It is not for repository file content reads or branch manipulation; it is for history analysis and change attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| rev | No | Revision selector or range, such as HEAD, main..feature, or A...B. Use this to narrow history to the branch, comparison window, or ancestry span relevant to your investigation before adding deeper filters. | HEAD |
| grep | No | Commit-message regex filters used to match intent cues such as ticket IDs, feature terms, bug labels, or 'revert'. Use this after path scoping to infer why changes happened; if results are still noisy, add author or date limits, then refine regex specificity. | |
| skip | No | Number of matching commits to skip before returning results. Use this for pagination when reviewing long histories in batches without changing your filter strategy. | |
| paths | No | Pathspec list (files, directories, or glob patterns) used to scope commits to relevant code areas. Use this first to reduce noise; if results are noisy, add or tighten paths (for example `src/service/**` or `*.py`) before applying grep or diff filters. | |
| since | No | Lower date bound (newer than) for commit traversal. Use this to focus on known release windows or incident periods after applying path/message filters. | |
| until | No | Upper date bound (older than) for commit traversal. Use this with since to bracket a time window when narrowing investigations to specific milestones. | |
| author | No | Author name/email pattern matched against commit identity metadata. Use this when ownership is known or suspected and you need to isolate one contributor after path/message filtering. | |
| all_match | No | Require all identity/message filters to match instead of allowing partial matches. Use this to tighten precision when combining author and grep filters that otherwise return overly broad results. | |
| grep_diff | No | Pickaxe regex filter that finds commits whose added/removed lines match a structural code pattern. Use this when you know shape changes (signature edits, condition rewrites, renames) but not an exact token, and pair it with paths for precision. | |
| max_count | No | Maximum number of commits to return. Use smaller values for iterative investigation loops and increase only after filters are well scoped. | |
| repo_path | No | Path to the git repository to query. Use this to point history analysis at the correct project root when your current working directory is not the target repo. | . |
| with_patch | No | Include the patch/diff for each listed commit. Enabling this increases output volume; use it when you need to inspect the actual code changes in commits. It is also useful for viewing changes in a single commit when paired with rev and max_count=1. To reduce output size, limit scope with paths and, whenever possible, pickaxe filters (search_string/grep_diff). | |
| fixed_strings | No | Treats grep patterns as literal strings rather than regex. Use this for exact tokens (for example a ticket key) when regex interpretation adds accidental matches. | |
| search_string | No | Pickaxe string filter that returns commits where the occurrence count of the exact text changed in the diff. Use this to track introduction/removal of a stable identifier after scoping by paths; if too broad, add date/author filters. | |
| extended_regexp | No | Enables POSIX extended regex behavior for message grep patterns. Use this when grep patterns need richer regex constructs beyond basic matching semantics. | |
| regexp_ignore_case | No | Controls whether message grep matching ignores case differences. Use true for exploratory searches across inconsistent commit message style, and disable it when exact case carries meaning. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It communicates that the tool is analytical and history-focused, and it explicitly rules out content reads and branch manipulation, signaling a read-only investigation posture. It does not explicitly state 'does not modify the repository,' but the framing of 'history analysis and change attribution' plus the negatives makes the behavioral profile largely transparent.
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 two sentences with no filler. The primary action and purpose are front-loaded, the selection criteria appear in the second sentence, and the exclusion is stated immediately afterward. Every clause earns its place.
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?
Despite having 16 parameters and no sibling tools, the description provides a complete high-level orientation: what the tool does, what signals it returns, when to use it, and what it is not for. The input schema covers all parameter details and the output schema exists, so nothing needed for correct selection and invocation is missing.
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 tool description itself contains no parameter-specific guidance; all parameter semantics live in the input schema, which has 100% coverage and rich per-parameter usage notes. Per the rubric baseline, when schema coverage is high the description is not expected to repeat parameter details, so a 3 is appropriate.
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 opens with a specific verb-plus-resource framing: 'investigate when a code/configuration change happened and infer why it happened from commit history.' It also enumerates the concrete signals it provides — commit timelines, authorship context, and intent signals — and closes by distinguishing itself from file content reads and branch manipulation. This makes the tool's identity unmistakable even without sibling tools listed.
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 explicitly states when to choose the tool ('Choose it when you need commit timelines, authorship context, or intent signals') and when not to choose it ('It is not for repository file content reads or branch manipulation'). This gives an agent clear selection criteria and exclusions with no inference required.
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.0git_logScored across 1 tool
With only a single tool, there is no possibility of confusion between tools. The description explicitly distinguishes it from file reads and branch manipulation, making its purpose clear.
The single tool name `git_log` follows a clean, conventional snake_case pattern that aligns with the server's purpose. Consistency is trivially maintained with one tool.
One tool is slightly under the typical 3-15 range, but for a narrowly scoped git-log server, it is reasonable and not excessive. The tool's flexibility helps compensate for the thin count.
The tool covers the core need of commit history analysis and change attribution, including messages and diffs. Minor gaps exist for operations like blame or range-specific logs, but the description implies the tool can handle broad historical queries.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Generate answers & visualizations from your engineering data to track software development health.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
