Loading ToolBench
An extension to visualize Git logs and commit history with animations using a Webview. Leverages an MCP (Model Context Protocol) server and language model tools for enhanced interaction and visualization features like visualize_git_log, get_git_log, and highlight_commit.
GitViz MCP provides 4 tools with explicit input schemas and descriptions visible in package.json. Tool naming follows verb_noun convention (get_*, visualize_*, highlight_*) which is clear and appropriate. All tools have descriptions ranging from 106-446 characters, within the ideal 10-1024 range. However, descriptions are longer than necessary and include example values that could be reused by LLMs. Input schemas are properly typed JSON Schema objects. A key weakness: output schemas are completely undocumented, there is no specification of what these tools return, preventing agents from planning downstream chaining. Error handling and recovery guidance are absent. Tool composition is reasonable (single responsibility per tool), but the 'get_git_prompt' tool is unusual, it returns a prompt template rather than performing a Git operation, which creates semantic inconsistency with the other three domain tools.
This tool retrieves the git log for a file path by resolving its repository. Each commit includes the short hash (%h), author name (%an), relative date (%ar), commit message (%s), references/tags (%d), and parent hashes (%p). Example output: `a1b2c3d (Alice) (3 days ago) (Initial commit) (HEAD -> main) []` Use this tool whenever you need to fetch or analyze the git commit history of any file or folder.
This tool retrieves the Git-GPT prompt template which contains specialized instructions for handling Git-related tasks. When facing Git-related questions or issues, call this tool first to enhance your capabilities with Git-specific guidance. The prompt includes best practices for explaining Git commands, visualizing operations, and providing beginner-friendly assistance. Use this tool before attempting to solve complex Git problems to ensure you're following the recommended workflow and communication style for Git assistance.
This tool highlights a commit node in the log tree using its full or short hash. It should be used when you want to visually focus on a specific commit after log analysis, search, or user interaction. Example: highlight the commit `a1b2c3d`.
This tool is used to visualize how the Git history changes after a specific Git operation(e.g., merge, rebase, cherry-pick). It helps illustrate the structural differences between the commit tree before and after the operation. To use this tool, provide two Git log histories: - `beforeOperationLog`: Git history before the operation. This can be obtained using the `get_git_log` tool, or it can be generated manually. - `afterOperationLog`: Git history after the operation, including the commits from `beforeOperationLog` plus any new or rewritten commits. Each commit should follow the format: short hash (%h) which must be a hexadecimal string containing only [0-9a-f], author name (%an), relative date (%ar), commit message (%s), references/tags (%d), and parent hashes (%p). Example: beforeOperationLog: 76ddb32 (Alice) (2 weeks ago) (Initial commit) [] afterOperationLog: 1f4a8f3 (Jimmy) (11 days ago) (feat: add api) [76ddb32] 76ddb32 (Alice) (2 weeks ago) (Initial commit) [] Use this tool to help users understand how a Git operation transform the commit tree.
Output schemas are completely undocumented. No specification of what get_git_log, visualize_git_log, highlight_commit, or get_git_prompt return. LLMs cannot plan downstream tool calls or extract fields for chaining without knowing the response structure.
Descriptions include example values ('a1b2c3d', '76ddb32', 'Alice', 'Jimmy') that LLMs tend to reuse literally rather than adapt to context. Should replace with formal constraints (enums, patterns) or remove entirely.
'get_git_prompt' is semantically inconsistent with the other three tools. It does not perform a Git operation; it returns a prompt template for LLM guidance. This mixing of concerns (domain tools + meta-guidance tools) creates ambiguity for tool selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
No error handling guidance. Tools lack descriptions of failure modes, retryability, or recovery steps. An LLM receiving a malformed log format or invalid hash has no guidance on what to do next.
The 'visualize_git_log' description states 'short hash (%h) which must be a hexadecimal string containing only [0-9a-f]' but this constraint is not enforced in the beforeOperationLog or afterOperationLog parameters, no regex pattern or format specifier in the schema.