Semantic git queries via MCP. Beyond git log — answer who/what/when/why about any line, file, or branch.
Pairs with terminal-history-mcp and localhost-mcp. Together: what you ran, what's running, what you changed.
Devs ask these constantly; git answers poorly:
"Who last touched this function?" — git blame only gives lines, not authors-by-region
"What PR introduced this line?" — manual: blame → commit SHA → search GH
"Which files always change together?" — no built-in
"Show unmerged branches older than 30 days" — bash one-liner gymnastics
"What did I work on last week?" — manual log scrub
LLM agents need this context to make safe edits. Currently they git log -n 5 and miss everything.
Related MCP server: semamerge
npm install -g git-insight-mcpWire into Claude Code:
claude mcp add --scope user git-insight -- git-insight-mcpOr any MCP-compatible client. Runs as a stdio MCP server.
For PR / issue lookups, set a GitHub token:
export GH_TOKEN=ghp_...Without a token, the local-git tools still work. PR linkage is skipped.
Tool | Purpose |
| Group blame by author. Lines, commits, last-touched, primary owner. Optional line-range narrowing. |
| Find the PR that introduced a line (or commit). Parses merge messages first; falls back to GitHub API. |
| Files most often changed together with the input file. |
| List branches with ahead/behind, last commit, merged status, stale flag. |
| Standup helper: author's commits + files + ins/del in a window. |
| Full commit context: subject, body, files, PR, related issues. |
who_touched){
"file": "src/auth.ts",
"total_lines": 124,
"authors": [
{ "name": "alice", "email": "alice@x.com", "lines": 87, "commits": 12, "last_commit_date": "2026-04-12T10:33:01.000Z" },
{ "name": "bob", "email": "bob@x.com", "lines": 37, "commits": 4, "last_commit_date": "2026-01-03T18:14:55.000Z" }
],
"primary_owner": "alice"
}git-insight-mcp who-touched src/auth.ts
git-insight-mcp co-change src/auth.ts
git-insight-mcp branches
git-insight-mcp recent alice
git-insight-mcp commit a3e577e
git-insight-mcp intro-pr src/auth.ts:42
git-insight-mcp intro-pr a3e577e
git-insight-mcp # MCP stdio servergit clone https://github.com/HasanJahidul/git-insight-mcp.git
cd git-insight-mcp
npm install
npm run build
node dist/cli.js branchesGitHub only (no GitLab/Bitbucket yet).
co_change is O(window × files-per-commit) — defaults capped at 1000 commits.
Function-level blame is by line range, not AST. Renames not yet tracked.
GH API rate limit applies (5000/h authed). PR results uncached this version.
MIT
Read-only. Inventory of branches with ahead/behind counts versus the default branch, last commit date and author, merged status, and a stale flag (no commits in stale_days days). Use it to find unmerged, abandoned branches. The default branch itself is excluded from the list. Pure local git; no network. Returns { count, branches, default_branch_excluded }.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Path inside the target git repo. Defaults to the server's current working directory. | |
| remote | No | Inspect remote (`origin`) branches instead of local branches. Default false. | |
| stale_days | No | A branch with no commit newer than this many days is flagged `stale`. Default 30. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| branches | No | |
| default_branch_excluded | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it's 'Pure local git; no network' and that 'The default branch itself is excluded from the list.' It also outlines the return structure. No contradiction with annotations.
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?
Four sentences with no wasted words. The first sentence immediately conveys read-only nature and the key fields. Return format is given. Every sentence serves a purpose.
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 3 optional params and an output schema (implied by the return structure described), the description covers the key behavioral aspects: what it returns, default branch exclusion, network independence, and the stale flag logic. No gaps for an agent to invoke correctly.
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 coverage is 100%, so the schema already documents all three parameters. The description does not add significant extra meaning beyond what is in the schema descriptions (e.g., default for stale_days). Baseline of 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?
Description clearly states the tool provides an inventory of branches with ahead/behind counts, last commit date, author, merged status, and stale flag. It explicitly says 'Use it to find unmerged, abandoned branches,' which is a specific use case. The name 'branch_hygiene' is metaphorical but the description makes it concrete. Sibling tools like co_change or commit_context focus on different aspects, so this tool is well-differentiated.
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?
Description gives explicit guidance: 'Use it to find unmerged, abandoned branches.' It also states it's read-only and pure local git with no network. It does not explicitly mention when not to use or provide alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Files that historically change together with the input file — answers "if I edit X, what else should I check?". Mines up to window recent commits that touch file, counts how often each other file appears alongside it, and returns those above threshold, with the co-occurrence count and ratio (count / commits-touching-file), capped at limit. Pure local log mining; no network. Cost is O(window × files-per-commit) — keep window ≤ a few thousand on large repos.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Path inside the target git repo. Defaults to the server's current working directory. | |
| file | Yes | File path relative to the repo root to find co-changing files for. | |
| limit | No | Maximum number of co-changing files to return, highest count first. Default 20. | |
| window | No | How many recent commits touching `file` to mine. Default 1000. | |
| threshold | No | Minimum co-occurrence count for a file to be included. Default 3. |
| Name | Required | Description |
|---|---|---|
| file | No | |
| co_changed | No | |
| total_commits_touching | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds significant behavioral context: read-only, mines commits, cost O(window × files-per-commit), and parameter effects. No contradiction.
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 concise given the complexity, with a front-loaded summary of purpose. Every sentence adds value, but it could be slightly tighter.
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?
The description fully covers what the tool does, how it works, algorithm details, return values (co-occurrence count and ratio), performance cost, and parameter constraints. With an output schema present, it is complete.
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 coverage is 100% with descriptions. The description adds meaning by explaining how parameters (window, threshold, limit) affect the algorithm and providing default values contextually.
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 clearly states the tool finds files that historically change together with the input file, using commits and co-occurrence. It explicitly distinguishes from sibling tools by focusing on co-change analysis.
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 provides a use case ('if I edit X, what else should I check?') and notes it's local log mining with no network. It could explicitly mention when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Everything about one commit in a single call: subject, body, changed files with per-file insertions/deletions, totals, the linked PR (parsed from the merge message, or via the GitHub API when GH_TOKEN/GITHUB_TOKEN is set), and issue numbers referenced in the message (Fixes #N, Closes #N). Errors if the SHA does not resolve in cwd. May make one outbound GitHub API call for PR enrichment.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Path inside the target git repo. Defaults to the server's current working directory. | |
| sha | Yes | Commit SHA (full or abbreviated) or any revision `git` accepts, e.g. `HEAD`, `HEAD~3`, a tag. |
| Name | Required | Description |
|---|---|---|
| pr | No | |
| sha | No | |
| body | No | |
| date | No | |
| author | No | |
| subject | No | |
| deletions | No | |
| insertions | No | |
| files_changed | No | |
| related_issues | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds crucial context: it may make an outbound GitHub API call for PR enrichment and errors if SHA doesn't resolve. This goes beyond the annotations, though it doesn't detail the response format or all edge cases.
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?
Three sentences, front-loaded with the read-only nature, and efficiently enumerates returned data and special behaviors. Every sentence provides necessary information without redundancy.
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?
Given the presence of an output schema (unseen but flagged), the description covers everything needed: what the tool returns, when it errors, and potential external call. It is fully adequate for an agent to invoke the tool correctly.
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 coverage is 100%, so baseline is 3. The description adds value by explaining error behavior for the SHA parameter and implying the cwd default. It doesn't repeat schema but provides behavioral context that aids parameter understanding.
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 clearly states it retrieves detailed information about a single commit (subject, body, changed files, PR, issues). This verb+resource approach is specific and distinct from sibling tools like 'branch_hygiene' or 'recent_work', which focus on different aspects.
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 implies usage for getting a comprehensive commit summary but does not explicitly differentiate from siblings or state when not to use. It does mention an important behavioral constraint (external GitHub call) and error condition, providing some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Find the pull request that introduced a line or a commit. First resolves the line to a commit via git blame, then reads the local merge-commit message; if that has no PR reference and GH_TOKEN/GITHUB_TOKEN is set, falls back to the GitHub REST API. Without a token the local path still works; pr is null when nothing can be resolved (e.g. rebase-merged with no PR ref). Provide either commit, or both file and line. May make one outbound GitHub API call (subject to the 5000/h authed rate limit).
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Path inside the target git repo. Defaults to the server's current working directory. | |
| file | No | File path relative to the repo root. Requires `line`. | |
| line | No | 1-based line number in `file` to blame back to its introducing commit. | |
| commit | No | Commit SHA to look up directly. Use this instead of `file`/`line`. |
| Name | Required | Description |
|---|---|---|
| pr | No | PR details when resolved, else null. |
| author | No | |
| commit | No | |
| source | No | How the PR was resolved: `merge-message`, `github-api`, or `not-found`. |
| commit_date | No | |
| commit_message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description details the internal process: git blame, reading merge-commit messages, fallback to GitHub REST API, rate limits, and null result scenarios. This fully discloses behavioral traits.
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 comprehensive but somewhat lengthy. It is well-structured with the key point 'Read-only' up front, and each sentence adds value. Could be slightly more concise but still effective.
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?
Given the tool's complexity (two-step process with fallback) and that an output schema exists, the description covers all necessary behavioral and usage aspects without missing critical details.
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?
With 100% schema coverage, baseline is 3. The description adds meaning: explains that `file` and `line` are used together, `commit` is an alternative, and `cwd` defaults. It provides context beyond the schema definitions.
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 clearly states the tool finds the PR that introduced a line or commit. It specifies exact inputs (line/commit) and distinguishes from sibling tools like 'co_change' or 'branch_hygiene' by focusing on PR introduction.
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 explains when to use (when you need the introducing PR for a line or commit) and mentions token-dependent fallback behavior. However, it does not explicitly state when not to use or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Standup / changelog helper: one author's commits in a time window with files touched and insertion/deletion totals. Defaults to the repo's user.name and the last 7 days. Pure local git; no network. Returns { author, since, commit_count, commits[] } where each commit has subject, date, files, insertions, deletions.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Path inside the target git repo. Defaults to the server's current working directory. | |
| limit | No | Maximum number of commits to return, newest first. Default 100. | |
| since | No | Any git date expression, e.g. `7 days ago`, `2026-05-01`, `last monday`. Default `7 days ago`. | |
| author | No | Author name or email substring (passed to `git log --author`). Defaults to `git config user.name`. |
| Name | Required | Description |
|---|---|---|
| since | No | |
| author | No | |
| commits | No | |
| commit_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces annotations with 'Read-only' and adds behavioral context like 'Pure local git; no network', which goes beyond the annotations. It also describes the output structure. No contradictions with annotations.
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: the first succinctly defines purpose and scope, the second details the return format. Every word contributes meaningful information, no fluff or repetition.
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?
Given the tool's moderate complexity and the presence of an output schema in the description, the description covers defaults, return type, and key constraints. Minor omissions like the exact git command used are not critical for an AI agent.
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 coverage is 100%, but the description adds valuable default behavior information (e.g., author defaults to repo's user.name, since defaults to 7 days ago). This enriches the agent's understanding beyond the raw schema.
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 clearly states it's a read-only standup/changelog helper that shows one author's commits in a time window with file changes and insertion/deletion totals. This distinctively sets it apart from sibling tools like 'branch_hygiene' or 'co_change' by focusing on individual author activity.
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 implies usage scenarios (standup, changelog) and mentions defaults, but does not explicitly state when to avoid using it or compare it to sibling tools like 'who_touched' or 'commit_context'. However, the context is clear enough for an AI agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Code ownership for a file via git blame, aggregated by author. Returns each author's line count, commit count, and most recent commit date, plus the primary_owner (most lines). Pass line_start/line_end to scope to one region (e.g. a single function). Errors if cwd is not a git repo or file is untracked. Cost scales with file size; instant for typical files.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Path inside the target git repo. Defaults to the server's current working directory. | |
| file | Yes | File path relative to the repo root, e.g. `src/auth.ts`. | |
| function | No | Optional label echoed back in the result; cosmetic only, does not change the blame range. | |
| line_end | No | Optional 1-based end line (inclusive). Must be paired with `line_start`. | |
| line_start | No | Optional 1-based start line. Must be paired with `line_end` to take effect. |
| Name | Required | Description |
|---|---|---|
| file | No | |
| authors | No | |
| total_lines | No | |
| primary_owner | No | Name of the author with the most lines. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds cost scaling and error conditions (non-git repo, untracked file), going beyond annotations without contradiction.
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?
Concise and well-structured: front-loaded with purpose and output, then usage details. Every sentence adds information with no redundancy.
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?
Covers purpose, output, parameter usage, error conditions, and performance. Output schema exists so return values are documented separately. Complete for the tool's complexity.
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 coverage is 100%, baseline 3. Description adds meaning: scoping with line_start/line_end, and clarifies that 'function' is cosmetic. This adds value beyond schema.
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 clearly states the tool reads code ownership via git blame, aggregated by author, and lists specific outputs (line count, commit count, primary owner). This distinguishes it from siblings like 'commit_context' or 'co_change'.
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?
Provides clear guidance on when to use line_start/line_end for scoping, error conditions, and performance characteristics. Does not explicitly mention alternatives but context is strong.
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.3branch_hygiene4 fields changedInput schema / properties / cwd / descriptionAdded value: +"Path inside the target git repo. Defaults to the server's current working directory."Input schema / properties / remote / descriptionPrevious value: -"Inspect remote (origin) branches instead of local (default false)"New value: +"Inspect remote (`origin`) branches instead of local branches. Default false."Input schema / properties / stale_days / descriptionPrevious value: -"Days without commit to count as stale (default 30)"New value: +"A branch with no commit newer than this many days is flagged `stale`. Default 30."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "branches": {
+ "items": {
+ "properties": {
+ "ahead": {
+ "type": "number"
+ },
+ "behind": {
+ "type": "number"
+ },
+ "last_commit_author": {
+ "type": "string"
+ },
+ "last_commit_date": {
+ "type": "string"
+ },
+ "merged": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "stale": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "type": "number"
+ },
+ "default_branch_excluded": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}co_change6 fields changedInput schema / properties / cwd / descriptionAdded value: +"Path inside the target git repo. Defaults to the server's current working directory."Input schema / properties / file / descriptionAdded value: +"File path relative to the repo root to find co-changing files for."Input schema / properties / limit / descriptionPrevious value: -"Max results (default 20)"New value: +"Maximum number of co-changing files to return, highest count first. Default 20."Input schema / properties / threshold / descriptionPrevious value: -"Min co-occurrence count (default 3)"New value: +"Minimum co-occurrence count for a file to be included. Default 3."Input schema / properties / window / descriptionPrevious value: -"How many recent commits touching the file to mine (default 1000)"New value: +"How many recent commits touching `file` to mine. Default 1000."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "co_changed": {
+ "items": {
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "file": {
+ "type": "string"
+ },
+ "ratio": {
+ "description": "count / total_commits_touching, 0–1.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "file": {
+ "type": "string"
+ },
+ "total_commits_touching": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}commit_context3 fields changedInput schema / properties / cwd / descriptionAdded value: +"Path inside the target git repo. Defaults to the server's current working directory."Input schema / properties / sha / descriptionAdded value: +"Commit SHA (full or abbreviated) or any revision `git` accepts, e.g. `HEAD`, `HEAD~3`, a tag."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "author": {
+ "type": "string"
+ },
+ "body": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "deletions": {
+ "type": "number"
+ },
+ "files_changed": {
+ "items": {
+ "properties": {
+ "deletions": {
+ "type": "number"
+ },
+ "insertions": {
+ "type": "number"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "insertions": {
+ "type": "number"
+ },
+ "pr": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "related_issues": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "sha": {
+ "type": "string"
+ },
+ "subject": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}introducing_pr5 fields changedInput schema / properties / commit / descriptionPrevious value: -"SHA (optional alternative to file/line)"New value: +"Commit SHA to look up directly. Use this instead of `file`/`line`."Input schema / properties / cwd / descriptionAdded value: +"Path inside the target git repo. Defaults to the server's current working directory."Input schema / properties / file / descriptionAdded value: +"File path relative to the repo root. Requires `line`."Input schema / properties / line / descriptionAdded value: +"1-based line number in `file` to blame back to its introducing commit."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "author": {
+ "type": "string"
+ },
+ "commit": {
+ "type": "string"
+ },
+ "commit_date": {
+ "type": "string"
+ },
+ "commit_message": {
+ "type": "string"
+ },
+ "pr": {
+ "description": "PR details when resolved, else null.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "source": {
+ "description": "How the PR was resolved: `merge-message`, `github-api`, or `not-found`.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}recent_work5 fields changedInput schema / properties / author / descriptionPrevious value: -"Defaults to git config user.name"New value: +"Author name or email substring (passed to `git log --author`). Defaults to `git config user.name`."Input schema / properties / cwd / descriptionAdded value: +"Path inside the target git repo. Defaults to the server's current working directory."Input schema / properties / limit / descriptionPrevious value: -"Max commits to return (default 100)"New value: +"Maximum number of commits to return, newest first. Default 100."Input schema / properties / since / descriptionPrevious value: -"Git date expression (default '7 days ago')"New value: +"Any git date expression, e.g. `7 days ago`, `2026-05-01`, `last monday`. Default `7 days ago`."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "author": {
+ "type": "string"
+ },
+ "commit_count": {
+ "type": "number"
+ },
+ "commits": {
+ "items": {
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "deletions": {
+ "type": "number"
+ },
+ "files": {
+ "type": "number"
+ },
+ "insertions": {
+ "type": "number"
+ },
+ "sha": {
+ "type": "string"
+ },
+ "subject": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "since": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}who_touched6 fields changedInput schema / properties / cwd / descriptionPrevious value: -"Repo path. Defaults to current working dir."New value: +"Path inside the target git repo. Defaults to the server's current working directory."Input schema / properties / file / descriptionPrevious value: -"Path to file (relative to repo root)"New value: +"File path relative to the repo root, e.g. `src/auth.ts`."Input schema / properties / function / descriptionPrevious value: -"Optional function name label (cosmetic)"New value: +"Optional label echoed back in the result; cosmetic only, does not change the blame range."Input schema / properties / line_end / descriptionAdded value: +"Optional 1-based end line (inclusive). Must be paired with `line_start`."Input schema / properties / line_start / descriptionAdded value: +"Optional 1-based start line. Must be paired with `line_end` to take effect."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "authors": {
+ "items": {
+ "properties": {
+ "commits": {
+ "type": "number"
+ },
+ "email": {
+ "type": "string"
+ },
+ "last_commit_date": {
+ "description": "ISO 8601 timestamp of the author's most recent commit to this range.",
+ "type": "string"
+ },
+ "lines": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "file": {
+ "type": "string"
+ },
+ "primary_owner": {
+ "description": "Name of the author with the most lines.",
+ "type": "string"
+ },
+ "total_lines": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}branch_hygieneco_changecommit_contextintroducing_prrecent_workwho_touchedScored across 6 tools
Each tool targets a distinct git analysis task: branches, file co-change, commit details, PR introduction, recent work, and file ownership. No functional overlap is apparent.
All names use lowercase snake_case and are descriptive compound nouns (e.g., branch_hygiene, who_touched). While not strictly verb_noun, the pattern is consistent and readable.
Six tools is a well-scoped set for a git insight server, covering key analyses without being overwhelming or too sparse.
The set covers branch analysis, co-change, commit details, PR discovery, recent work, and blame. Missing common operations like branch diff or commit log filtering, but still functional for the intended domain.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Hosted code graph over MCP: exact callers, dependencies, and cross-repo blast radius for AI agents.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
