Loading ToolBench

Reading the current corpus…

git-log-analysis MCP server · D · ToolBench

← Browse

git-log-analysis

github.com/gagip/git-log-analysis

A tool for extracting monthly Git logs, parsing commit history with diffs, and searching via CLI or MCP server

<=2025-11-25STDIO3 tools

53/100

Definition Quality66

Protocol Readiness47

Supportability36

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Three tools with complete schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. search_commits has good parameter coverage (6 params, all described), but list_projects and get_commit_changes lack depth. No output schemas documented, LLMs cannot plan downstream calls or extract structured data. Error handling is minimal (basic 'not found' messages). No tool annotations (readOnlyHint, etc.). Descriptions are adequate (100-200 chars) but lack WHEN/WHY guidance. Parameter constraints present (date format, minimum limit) but not comprehensive.

Tools (3)

get_commit_changesread onlysource verified63/100

Retrieves detailed change history for a specific commit. Uses the commit hash (full or at least 7 characters).

list_projectsread onlysource verified57/100

Returns the list of available projects and the commit count for each project.

search_commitsread onlysource verified77/100

Search Git commits. Finds keywords in commit messages or changed file paths. Can filter by date range and author.

Issues (5)

CRITICALtool ↗

No output schemas documented. LLMs cannot infer what fields search_commits, list_projects, or get_commit_changes return, forcing them to guess at downstream field names and breaking tool chaining.

search_commitslist_projectsget_commit_changes

HIGHtool-description ↗

list_projects has minimal description (47 chars). Does not explain WHEN to call it, what structure it reveals, or how to use results with search_commits. Lacks discovery guidance.

list_projects

MEDIUMtool ↗

No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All three tools are read-only and idempotent, but LLMs cannot infer this without explicit hints.

search_commitslist_projectsget_commit_changes

HIGHrecovery-guide ↗

Error handling is generic. 'Commit not found' and 'Error: <message>' provide no recovery guidance. Should suggest next steps: 'Commit hash not found. Try search_commits() to find the commit first.'

Recommendations

Document output schemas for all three tools. Example: search_commits returns {results: [{commit_hash, message, author, date, files_changed}], total_count, limit}. This enables LLMs to chain tools and extract the right fields.
Enhance list_projects description: 'Call this first to discover available projects before filtering search_commits by project name. Returns project names and commit counts to help you choose which projects to analyze.'
Add tool annotations to the Tool objects: readOnlyHint=true for all three tools (they only read git logs, never modify). This signals to LLMs that these are safe to call repeatedly.
Improve error messages with recovery guidance. E.g., get_commit_changes: 'Commit hash not found. Try search_commits(keyword=...) to find the commit, then use its hash here.'
Remove example dates from search_commits description. Replace 'Example: 2024-01-01' with a format constraint in the schema: 'format': 'date' (YYYY-MM-DD).

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

53/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	53	<=2025-11-25	v2