An MCP server that provides Git history insights to AI assistants
This Git Time Machine MCP server demonstrates solid foundational quality with clear tool definitions, well-structured schemas, and comprehensive parameter documentation. All 5 tools have explicit input/output schemas with proper type definitions and descriptions. Tool names follow verb_noun conventions appropriately (get_*, summarize_*). However, there are gaps in error handling guidance, output schema documentation completeness, and some parameter descriptions lack constraint details. The server is read-only (all tools marked READ_ONLY), which simplifies error handling but also means no destructive operations require confirmation patterns. Tool compositions are well-designed for chaining (e.g., get_commits_affecting + get_file_at_commit). Average tool description length ~120 chars (within the 10-1024 baseline), and all parameters have types and descriptions.
Get the full diff for a specific commit. Returns the complete diff and metadata for a specific commit
Get a list of commits that modified a file. Returns metadata for commits that affected the given file
Get a file as it existed at a specific commit. Returns the file content at the given commit
Get git blame information for a file. Returns line-by-line blame metadata showing who last modified each line
Summarize the differences between two commits. Compares two commits and produces a human-readable summary of the changes
Error handling lacks recovery guidance. Tool descriptions and schemas do not indicate what errors might occur (e.g., 'file not found', 'invalid commit SHA', 'path traversal attempted') or what the LLM should do next. This violates pattern:recovery-guide.
Output schemas are defined in models but not explicitly documented in tool descriptions. LLMs cannot determine the structure of responses without reading response type schemas. The BlameResponse, CommitDiffResponse, etc. are well-typed but the tool descriptions do not summarize what fields the LLM will receive.
Parameter descriptions lack constraint details. 'Path to the file' does not specify: must it be absolute or relative? Are symlinks followed? Is there a max path length? A max file size for get_file_at_commit? For 'limit' in get_commits_affecting, no min/max bounds are stated (0-1000?). This forces LLMs to guess and can cause invalid requests.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 53 | - | v1 |
No pagination documented for get_commits_affecting. If a file has thousands of commits, returning all of them could blow the context window. The 'limit' parameter exists but the tool description does not mention pagination strategy, what happens when limit is exceeded, or how to retrieve subsequent pages.
Tool descriptions do not explain when to use similar tools. E.g., when should an LLM call get_commit_diff vs summarize_diff? The difference is implied (full vs summary) but not stated. This forces the LLM to reason about trade-offs rather than having the tool purpose explicit.