Provides read-only tools for exploring a local Git repository's history, including commit topology, branch lanes and merge edges, local and remote-tracking branch selection, commit metadata, file statistics, bounded patches, search highlighting across loaded commits, and incremental history loading.
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-graph Show the Git graph for this repository."
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.
An original, MIT-licensed local Git history explorer written in TypeScript and React. It uses the MCP SDK and MCP Apps UI standard. No code from mhutchie's VS Code extension is used.
Commit topology with branch lanes and merge edges
Local and remote-tracking branch selection
Search highlighting across loaded commits, authors, and hashes
Commit metadata, file statistics, and bounded patches
Incremental history loading and a responsive layout
Read-only Git tools over stdio, plus an optional local browser preview
Related MCP server: repo-context
Requires Node.js 22+ and Git.
npm ci
npm run check
npm run build
npm test
GIT_GRAPH_REPO=/absolute/path/to/repository npm run previewOpen http://127.0.0.1:4317. The preview binds only to loopback. It rejects API calls from other origins. No Git fetches, writes, hosted service, accounts, telemetry, or model API keys are used.
codex mcp add git-graph --env GIT_GRAPH_REPO=/absolute/path/to/repository -- node /absolute/path/to/codex-git-graph/dist/server.jsStart a new chat after registering the server. Ask: "Show the Git graph for this repository." The tools also work in clients that cannot render the UI. Set GIT_GRAPH_REPO explicitly when the client does not launch the server from the target repository.
plugins/git-graph/ contains the compatibility manifest, MCP configuration, bundled server/UI, and skill. npm run build regenerates its dist/ directory. The server bundle includes its runtime dependencies.
codex plugin marketplace add /absolute/path/to/codex-git-graph
codex plugin add git-graph@git-graph-localThe bundled MCP launches from its installed plugin directory. Pass the target checkout as the repository argument to git_history; the UI passes that repository to subsequent tools. Ask: "Show the Git graph for /absolute/path/to/repository." Local marketplace installation and the installed server bundle are verified. Native MCP Apps rendering in a fresh Codex chat remains unverified. The browser preview is a separate tested surface.
OpenAI's current packaging documentation requires a public HTTPS MCP endpoint for public submission, or separate support for local MCP servers. This local stdio prototype is not ready for directory submission. A hosted version would need an authenticated repository provider or an explicit local bridge; a hosted server cannot directly read a user's local checkout.
See https://developers.openai.com/plugins/build/plugins and https://developers.openai.com/plugins/build/chatgpt-ui.
Remote-tracking refs reflect local state and may be stale. Search highlights matches in loaded history rather than searching every commit. Pagination is offset-based; a changing repository can shift rows. Git operations have a 10-second timeout and an 8 MiB output limit. Patches above 100,000 characters are shortened; commands exceeding the output limit report an error. Merge details use Git's default merge diff presentation. The graph is an on-demand app view, not a permanent Codex sidebar extension.
npm test exercises a real merge fixture, pagination, custom remote branches, detached HEAD, invalid inputs, and an MCP stdio handshake/tool/resource integration. The MCP test uses GIT_GRAPH_TEST_REPO when supplied, otherwise creates an isolated repository fixture. Browser interaction verification covers commit details, branch selection, search highlighting, and loading more commits.
Read commit metadata, file statistics, and a bounded patch for a full Git hash.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | ||
| repository | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the burden is lower. The description adds one useful trait beyond annotations: the patch is 'bounded,' signaling size limits rather than a full diff, though it never says what the bound is or whether history can be truncated.
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?
A single front-loaded sentence with no filler; the verb and the returned artifacts come first. Every clause contributes information.
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?
With no output schema, the description usefully enumerates what comes back (metadata, stats, patch), which is the right thing to summarize. It falls short on the undocumented repository parameter and the absent guidance about when to prefer git_history.
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?
Schema description coverage is 0%, so the description must carry parameter meaning. 'A full Git hash' restates what the regex pattern already enforces and adds nothing, while the 'repository' parameter is never mentioned at all, leaving half the inputs unexplained.
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?
Names a specific verb (Read) and enumerates the resources returned: commit metadata, file statistics, and a bounded patch. The phrase 'for a full Git hash' signals this is a single-commit lookup, which implicitly separates it from git_history, though the sibling is never named.
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?
Usage is only implied: the agent can infer this is for inspecting one commit given a full hash, versus git_history for ranges or logs. There is no explicit when-to-use, when-not-to-use, or named alternative, leaving the agent to guess at the boundary with git_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a graph of local commits and branches. Does not modify the repository or contact remotes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| branch | No | ||
| offset | No | ||
| repository | No | Absolute path to the local Git checkout requested by the user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, and the sentence 'Does not modify the repository or contact remotes' largely restates those hints. It adds the mild clarifying detail that the graph covers local commits/branches only, but discloses nothing about pagination, branch scoping, or result shape.
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?
Two short, front-loaded sentences with no filler. The second sentence is partially redundant with the annotations, which costs it the top score, but the description remains tight.
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?
With no output schema, the description should say more about what the graph returns, and with three undocumented parameters it should at least sketch the paging/branch options. As written it covers the read-only nature and the local scope but leaves return format and parameter behavior unexplained.
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?
Schema description coverage is only 25% (repository is documented, limit/branch/offset are not), so the description must compensate and it does not mention any parameter. The limits on paging (limit max 300, offset) and the meaning of branch are left entirely to bare schema types.
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?
States a specific verb and resource: 'Show a graph of local commits and branches.' It is clearly distinguishable from the mutation sibling git_commit, though it never names the sibling to route the agent explicitly.
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?
Usage is only implied: an agent can infer this is for inspecting history rather than writing, and the 'local commits' scope hints at when it applies. There is no explicit when-to-use, when-not-to-use, or reference to git_commit as the alternative.
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_commitgit_historyScored across 2 tools
git_history shows a graph overview of commits and branches, while git_commit retrieves detailed metadata and patch for a specific hash. The two purposes are clearly different, though both operate on commit history and could be slightly confused by an agent skimming descriptions.
Both tools follow a consistent `git_` prefix with snake_case nouns: `git_history` and `git_commit`. The pattern is predictable and readable, with no mixed conventions.
Two tools is thin for a server focused on Git graph exploration, sitting at the borderline identified in the calibration. Additional tools for branch listing, searching, or diffing would make the set feel more complete without being excessive.
The server covers viewing the commit graph and inspecting a specific commit, but notable read-only operations are missing: branch/tag listing, searching or filtering history, file-level history, and showing diffs between arbitrary commits. These gaps limit deeper Git exploration workflows.
Repository knowledge graph MCP server for codebase understanding and debugging.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Query your team's AI coding history and act on HypAware recommendations from any MCP client.
Search, inspect and inject full source modules (code + AI rules + MCP) pinned to a Git commit.
