Which integrations are available for this server?

Provides deep repository analytics including hotspots, churn, coupling, knowledge maps, risk assessment, and release notes generation by analyzing local Git commit history.

How do I use GitIntel?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GitIntel Show me the hotspots and risk assessment for this repo." 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.

GitIntel

by hoangsonww

Overview Schema Related Servers Score Discussions

TypeScript

Local

GitIntel - A Git Intelligence MCP Server for AI Agents

TypeScript Node.js MCP SDK Zod Vitest Prettier tsx Git ESM JSON--RPC stdio Docker Kubernetes Terraform AWS Azure License

Git Intelligence MCP Server - deep repository analytics computed locally from your commit history.

Surfaces the same insights that tools like CodeScene and GitPrime charge for: hotspots, temporal coupling, knowledge maps, churn analysis, complexity trends, risk scoring, and more. Everything runs locally. No external APIs, no data leaves your machine.

This is a locally-built MCP server. It is not published to npm. You clone, build, and register it with your MCP client & AI agents (Claude Code, Codex, etc.).

You:    "Analyze this repo -- show me hotspots, risk, and who knows the auth module best."
Claude: [calls hotspots, risk_assessment, knowledge_map in parallel, returns formatted analysis]

Architecture

GitIntel is a standalone MCP server that exposes a suite of tools and resources for analyzing git repositories. It communicates with any MCP client (Claude Code, Codex, etc.) over stdio using JSON-RPC.

graph LR
    A[MCP Client<br/>Claude Code / Codex] <-->|stdio<br/>JSON-RPC| B[mcp-git-intel<br/>MCP Server]
    B -->|execFile| C[Git CLI]
    C --> D[Repository<br/>.git]
    B --> E[Analysis Engine<br/>scoring, formatting]

All communication happens over stdio using the Model Context Protocol. The server calls Git via execFile (never exec) to prevent shell injection. All operations are strictly read-only.

Related MCP server: git-intel

Tools

12 analysis tools, each returning formatted tables, score bars, and actionable recommendations -- not raw git output.

graph TD
    subgraph "Change Analysis"
        H[hotspots<br/>Change frequency]
        CH[churn<br/>Write/rewrite ratio]
        CT[complexity_trend<br/>Complexity over time]
    end
    subgraph "Dependency Analysis"
        CO[coupling<br/>Temporal coupling]
    end
    subgraph "Team Analysis"
        KM[knowledge_map<br/>Who knows what]
        CS[contributor_stats<br/>Team dynamics]
        CP[commit_patterns<br/>Work patterns]
    end
    subgraph "Risk & Release"
        RA[risk_assessment<br/>Change risk scoring]
        RN[release_notes<br/>Changelog generation]
        BR[branch_risk<br/>Branch health]
    end
    subgraph "Code Archaeology"
        FH[file_history<br/>File evolution]
        CA[code_age<br/>Staleness map]
    end

Tool	What it does	Key insight
`hotspots`	Files that change most frequently	Top 4% of files by change frequency contain 50%+ of bugs
`churn`	Code written then rewritten (additions vs deletions)	Churn ratio near 1.0 = code rewritten as fast as it's written
`coupling`	Files that always change together	Hidden dependencies not visible in imports
`knowledge_map`	Who knows a file/directory best, weighted by recency	Find the right reviewer, spot knowledge silos
`complexity_trend`	How a file's complexity evolves over time	Catch files growing out of control
`risk_assessment`	Risk score (0-100) for uncommitted or committed changes	Combines hotspot history, size, sensitivity, spread
`release_notes`	Structured changelog from conventional commits	Groups by type, extracts breaking changes and PR refs
`contributor_stats`	Team dynamics, collaboration graph, knowledge silos	Workload distribution, onboarding planning
`file_history`	Full commit history of a single file with rename tracking	Trace why a file looks the way it does
`code_age`	Age map showing when each file was last modified	Find dead code, abandoned features, stable infrastructure
`commit_patterns`	Day-of-week, hour-of-day, commit size distributions	Spot weekend work, late-night hotfixes, oversized commits
`branch_risk`	Branch staleness, divergence, and merge risk analysis	Branch hygiene, cleanup candidates, merge planning

Data Pipeline

Each tool transforms raw git output through a multi-stage pipeline:

graph LR
    A["Git CLI<br/>raw output"] -->|parse| B["Structured Data<br/>LogEntry[], stats"]
    B -->|score| C["Scored Results<br/>normalized 0-100"]
    C -->|format| D["Formatted Output<br/>tables, bars, text"]
    D -->|wrap| E["MCP Response<br/>CallToolResult"]

Resources

Resources are pre-computed summaries or feeds that can be read directly without arguments. Useful for quick snapshots or embedding into prompts.

Resource URI	Description
`git://repo/summary`	Repository snapshot: branch, last commit, total commits, active contributors, top languages, age, remote
`git://repo/activity`	Recent 50-commit activity feed with stats

Installation

This server is not published to npm. You must clone, build, and register it locally.

Prerequisites

Node.js >= 18
Git >= 2.20

Build from source

git clone https://github.com/hoangsonww/GitIntel-MCP-Server.git
cd GitIntel-MCP-Server
npm install
npm run build

Register with Claude Code

IMPORTANT

Important: For best results, always open Claude Code inside a git repository directory. The server auto-detects the repo from your working directory. If you open Claude Code from a non-repo folder (e.g. your home directory), you will need to pass repo_path to every tool call manually.

Quick registration (analyzes cwd by default):

claude mcp add git-intel -- node /absolute/path/to/mcp-server/dist/index.js

With a specific repository:

claude mcp add git-intel -- node /absolute/path/to/mcp-server/dist/index.js /path/to/your/repo

Register with any MCP client (manual JSON)

Add to your MCP client's configuration file (e.g. ~/.claude.json for Claude Code global config):

{
  "mcpServers": {
    "git-intel": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/mcp-server/dist/index.js"],
      "env": {}
    }
  }
}

With a pinned default repository (optional — useful if you always analyze the same repo):

{
  "mcpServers": {
    "git-intel": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/mcp-server/dist/index.js"],
      "env": {
        "GIT_INTEL_REPO": "/path/to/your/repo"
      }
    }
  }
}

TIP

Tip: The ~ home directory expansion works in the repo path argument (e.g. ~/projects/my-repo).

Also: When registered globally (in ~/.claude.json), the server auto-detects the git repo in your current working directory. No GIT_INTEL_REPO needed — just open Claude Code inside any git repo.

Configuration

Default Repository Resolution

The server determines which git repository to use as the default using this priority order:

Priority	Method	Example
1	CLI argument	`node dist/index.js /path/to/repo`
2	Environment variable	`GIT_INTEL_REPO=/path/to/repo`
3	Current working directory	Falls back to `process.cwd()`

The ~ prefix is expanded to the user's home directory in all path inputs.

Per-Tool `repo_path` Override

Every tool accepts an optional repo_path parameter that overrides the default repository for that specific call. This allows analyzing any repository on disk without reconfiguring the server:

{ "repo_path": "C:/Users/you/other-project", "days": 90 }

Resilient Startup (No-Crash Mode)

The server never crashes on startup, even when launched from a non-git directory. Instead:

If a git repository is found, it becomes the default for all tools.
If no git repository is found, the server starts anyway with no default repo. Tools require the repo_path parameter to specify which repo to analyze.
Resources (git://repo/summary, git://repo/activity) return informative messages directing the user to open Claude Code inside a git repo or use repo_path.

flowchart TD
    Start["Server starts"] --> CheckRepo{"Is cwd a\ngit repo?"}
    CheckRepo -->|Yes| Default["Set as default repo\nAll tools work immediately"]
    CheckRepo -->|No| NoDefault["Start with no default\nTools require repo_path"]
    Default --> Ready["Server ready\n12 tools, 2 resources"]
    NoDefault --> Ready
    Ready --> Call{"Tool called"}
    Call --> HasArg{"repo_path\nprovided?"}
    HasArg -->|Yes| UseArg["Use repo_path"]
    HasArg -->|No| HasDefault{"Default repo\navailable?"}
    HasDefault -->|Yes| UseDefault["Use default repo"]
    HasDefault -->|No| Error["Return helpful error:\n'Open Claude Code in a git repo\nor pass repo_path'"]
    UseArg --> Execute["Execute git analysis"]
    UseDefault --> Execute

This design means the server works as a global MCP server in Claude Code — it connects successfully regardless of which project directory you open.

Usage Examples

Once registered, the tools are available through natural language. You do not call them directly -- the AI client decides which tools to invoke based on your prompt.

Find bug-prone files:

"Show me the change hotspots in the last 60 days"

Analyze code stability:

"What's the churn analysis for the src/api directory over the last quarter?"

Find hidden dependencies:

"Which files are temporally coupled with src/auth/login.ts?"

Find the right reviewer:

"Who knows the src/api directory best?"

Track complexity growth:

"Show me the complexity trend for src/services/payment.ts"

Assess change risk before merging:

"What's the risk assessment for the uncommitted changes?" "Assess the risk of changes between main and feature-branch"

Generate release notes:

"Generate release notes from v1.0.0 to HEAD"

Understand team dynamics:

"Show me contributor statistics for the last 6 months" "Who are the top collaborators and where are the knowledge silos?"

Trace a file's evolution:

"Show me the full history of src/auth/login.ts"

Find stale or abandoned code:

"What are the oldest files in the src/ directory?" "Show me code age analysis for the project"

Analyze work patterns:

"What are the commit patterns for the last 3 months?" "When does the team usually commit?"

Branch hygiene:

"Which branches are stale or highly diverged?" "Show me branch risk analysis against main"

Full repo analysis:

"Using git-intel, give me a comprehensive analysis of this repository"

See docs/EXAMPLES.md for a complete real-world transcript of a full repo analysis session.

Development

graph LR
    subgraph "Development"
        Dev["npm run dev<br/>tsx auto-reload"]
        CLI["npm run cli<br/>Interactive REPL"]
    end
    subgraph "Testing"
        Unit["npm test<br/>Vitest unit tests"]
        Smoke["npm run smoke<br/>Full integration"]
    end
    subgraph "Quality"
        Lint["npm run lint<br/>tsc --noEmit"]
        Fmt["npm run format<br/>Prettier"]
    end
    subgraph "Ship"
        Build["npm run build<br/>TypeScript → dist/"]
    end

    Dev --> Unit --> Lint --> Build
    CLI --> Smoke

npm run dev          # Run server with tsx (auto-reload, uses cwd as repo)
npm run cli          # Interactive REPL for testing tools and resources
npm run smoke        # Automated smoke test -- runs every tool and resource
npm test             # Run unit tests (vitest)
npm run test:watch   # Watch mode
npm run lint         # Type check (tsc --noEmit)
npm run build        # Compile TypeScript to dist/

CLI REPL

The interactive CLI (npm run cli) spawns the MCP server as a child process, connects as a real MCP client over stdio, and provides a REPL for calling tools and reading resources.

sequenceDiagram
    participant User as Developer
    participant CLI as cli.ts (MCP Client)
    participant Server as index.ts (MCP Server)
    participant Git as Git CLI

    User->>CLI: npm run cli [repo_path]
    CLI->>Server: Spawn via StdioClientTransport
    Server-->>CLI: Connected (JSON-RPC over stdio)
    CLI->>User: git-intel> prompt

    User->>CLI: call hotspots {"days": 60}
    CLI->>Server: callTool("hotspots", {days: 60})
    Server->>Git: git log --since=...
    Git-->>Server: raw output
    Server-->>CLI: formatted analysis
    CLI->>User: Display result + elapsed time

    User->>CLI: read git://repo/summary
    CLI->>Server: readResource("git://repo/summary")
    Server-->>CLI: repo snapshot
    CLI->>User: Display result

    User->>CLI: exit
    CLI->>Server: close()

Start the CLI:

npm run cli                    # Uses current directory as repo
npm run cli ~/projects/myapp   # Analyze a specific repo

Available commands:

Command	Description
`tools`	List all registered tools with parameters
`resources`	List all registered resources
`call <tool> [json]`	Call a tool with optional JSON arguments
`read <uri>`	Read a resource by URI
`help`	Show help
`exit` / `quit` / `q`	Quit the CLI

Example session:

git-intel> tools
  Available tools (12):
  hotspots               Identify files that change most frequently...
                         params: repo_path, days, limit, path_filter
  churn                  Analyze code churn...
                         params: repo_path, days, limit, path_filter
  ...

git-intel> call hotspots {"days": 60, "limit": 5}
  Calling hotspots...
  (42ms)

## Change Hotspots (last 60 days)
File                  Changes  Authors  Last Changed  Heat
--------------------  -------  -------  ------------  ---------------
src/index.ts               12        2    2026-03-08  [██████████] 100
src/tools/risk.ts           8        1    2026-03-07  [██████░░░░] 67
...

git-intel> call knowledge_map {"path": "src/auth"}
  Calling knowledge_map...
  (38ms)

## Knowledge Map: src/auth (last 365 days)
...

git-intel> call risk_assessment
  Calling risk_assessment...
  (125ms)

## Risk Assessment: uncommitted changes
...

git-intel> read git://repo/summary
  Reading git://repo/summary...
  (15ms)

Branch: master
Last commit: c4934239 by dav nguyxn on 2026-03-09
...

git-intel> exit
Bye.

See docs/CLI.md for the full CLI reference.

TIP

This is useful for manual testing and debugging without needing to go through an AI client.

Smoke Test

npm run smoke connects to the server and calls every tool and every resource against the current repo, printing all results. Useful for verifying nothing is broken after changes.

Security Model

graph LR
    Input["User / AI Input"] --> V1["validatePathFilter()<br/>Blocks .. and abs paths"]
    Input --> V2["validateRef()<br/>Strict char whitelist"]
    V1 --> Safe["Sanitized Args<br/>(string array)"]
    V2 --> Safe
    Safe --> ExecFile["execFile()<br/>No shell involved"]
    ExecFile --> Git["Git CLI<br/>read-only commands only"]
    Git --> Repo[".git<br/>No writes ever"]

    subgraph "Environment Hardening"
        E1["GIT_TERMINAL_PROMPT=0"]
        E2["GIT_PAGER=''"]
        E3["LC_ALL=C"]
        E4["30s timeout"]
        E5["50MB buffer limit"]
    end

    ExecFile -.-> E1 & E2 & E3 & E4 & E5

Concern	Mitigation
Shell injection	All git commands use `execFile` (array args, no shell interpolation)
Path traversal	`validatePathFilter()` blocks `..` and absolute paths
Ref injection	`validateRef()` validates git refs against a strict character whitelist
Write operations	Strictly read-only. No tool modifies the repository in any way
Network access	No external network calls. All data is local
Git safety	`GIT_TERMINAL_PROMPT=0` prevents interactive prompts; `GIT_PAGER=''` disables pagers
Timeouts	30-second default timeout on all git commands
Buffer limits	50MB max buffer to prevent memory exhaustion
We take security seriously. This server is designed to be safe to run on any machine with access to git repositories. Here are the key mitigations for potential attack vectors:

Concern	Mitigation
Shell injection	All git commands use `execFile` (array args, no shell interpolation)
Path traversal	`validatePathFilter()` blocks `..` and absolute paths
Ref injection	`validateRef()` validates git refs against a strict character whitelist
Write operations	Strictly read-only. No tool modifies the repository in any way
Network access	No external network calls. All data is local
Git safety	`GIT_TERMINAL_PROMPT=0` prevents interactive prompts; `GIT_PAGER=''` disables pagers
Timeouts	30-second default timeout on all git commands
Buffer limits	50MB max buffer to prevent memory exhaustion

Project Structure

The code is organized into clear modules for git interaction, analysis tools, resources, and utilities. The entry point (index.ts) sets up the MCP server and registers all tools and resources.

src/
  index.ts              Entry point, server setup, tool/resource registration (resilient startup)
  cli.ts                Interactive REPL for testing
  smoke-test.ts         Automated smoke test
  git/
    executor.ts         Safe git command runner (execFile, timeouts, env)
    parser.ts           Git output parsers (log, numstat, conventional commits)
    repo.ts             Repo validation, path/ref sanitization
  tools/
    hotspots.ts         Change frequency analysis
    churn.ts            Code churn (additions vs deletions)
    coupling.ts         Temporal coupling detection
    knowledge-map.ts    Knowledge scoring per author
    complexity.ts       Complexity trend over time
    risk.ts             Multi-factor risk assessment
    release-notes.ts    Changelog from conventional commits
    contributors.ts     Contributor analytics and collaboration
    file-history.ts     Single-file evolution with rename tracking
    code-age.ts         File staleness and age distribution
    commit-patterns.ts  Work pattern analytics (time, size)
    branch-risk.ts      Branch staleness and divergence detection
  resources/
    summary.ts          Repository snapshot resource (graceful degradation)
    activity.ts         Recent commit activity feed (graceful degradation)
  util/
    scoring.ts          Normalization, recency decay, coupling, risk scoring
    formatting.ts       Tables, score bars, text output helpers
    resolve-repo.ts     Per-call repo resolution with fallback chain and error messages

Further Documentation

This README provides a high-level overview. For deeper technical details, see:

ARCHITECTURE.md -- Deep technical architecture, design decisions, module dependencies
docs/TOOLS.md -- Detailed reference for every tool (schemas, examples, interpretation)
docs/CLI.md -- Full CLI reference with all commands, parameters, and examples
docs/EXAMPLES.md -- Real-world usage transcript showing a full repo analysis session

License

MIT. See LICENSE for details.

Author

Created by Son Nguyen in 2026. Contributions are welcome! See CONTRIBUTING.md for guidelines.

Available Tools

12 tools

branch_riskBranch Risk AnalysisA

Read-only

Analyze all branches for staleness, divergence from the main branch, and merge risk. Identifies stale branches that should be cleaned up, branches that have diverged significantly and may cause merge conflicts, and branches with no recent activity. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description	Default
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.
`base_branch`	No	Branch to compare against (default: HEAD). Typically "main" or "master".	HEAD
`include_remote`	No	Include remote tracking branches (default: false)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, so the description carries a lower burden. It adds context about what the analysis covers (stale, diverged, merge-risk branches) and the repo_path condition. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lean and front-loaded: first sentence summarizes the tool, second expands on findings, third is a conditional note. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description could detail the return format, but it clearly states what the tool identifies. Annotations cover safety, and parameters are well-documented in schema. Slightly incomplete on output, but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 minimal parameter info beyond the schema (only repeats the repo_path condition). No added value for base_branch or include_remote.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('Analyze', 'Identifies') and clearly states the resource ('all branches'). It covers staleness, divergence, and merge risk, which distinguishes it from sibling tools like 'hotspots' or 'churn'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a conditional guideline about repo_path, but does not explicitly compare to sibling tools or state when to use this tool over others (e.g., 'risk_assessment'). Usage is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

churnCode Churn AnalysisA

Read-only

Analyze code churn — how much code is being written and then rewritten. High churn indicates instability, unclear requirements, or code that is hard to get right. A file with 500 lines added and 400 deleted in a month is a red flag. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description
`days`	No	Number of days to look back (default: 90)
`limit`	No	Max results to return (default: 20, max: 100)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.
`path_filter`	No	Filter to files under this path

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description's 'Analyze' is consistent. It adds context about interpreting churn as a red flag and the git requirement, but does not disclose other behavioral traits like authorization needs or rate limits. Given annotations, the added value is moderate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with purpose, and each sentence serves a clear role: definition, interpretation, and usage note. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only analysis tool with 4 well-described parameters and annotations, the description covers the concept and a key requirement. Lack of output schema is noted, but the description is sufficient to guide usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description mentions the 'repo_path' requirement specifically, but does not add semantics beyond the schema for other parameters. The schema descriptions already cover the parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the resource ('code churn') and verb ('Analyze'), and provides a concrete example ('500 lines added and 400 deleted') that illustrates the concept. It effectively distinguishes the tool from its many siblings by focusing on churn measurement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (high churn indicates instability) and includes a critical prerequisite: providing 'repo_path' if outside a git repo. However, it does not offer alternatives among sibling tools or explicitly state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

code_ageCode Age AnalysisA

Read-only

Show the age of code in each file — when it was last modified. Identifies stale files that haven't been touched in months or years (potential dead code or abandoned features) vs actively maintained areas. Useful for cleanup planning, onboarding, and understanding which parts of the codebase are actively evolving. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	Sort order: "oldest" shows stalest files first, "newest" shows most recent first	oldest
`limit`	No	Max files to return (default: 30, max: 100)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.
`path_filter`	No	Filter to files under this path (e.g., "src/")

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description reinforces this by describing a read-only analysis (showing age, identifying stale files). It adds behavioral context about identifying potential dead code and abandoned features. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences) and front-loaded with the core purpose. Each sentence adds value: purpose, utility, and a critical note. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no output schema, and moderate complexity, the description adequately explains the tool's purpose and context. However, it does not describe the return format (e.g., list with file paths and dates), which would help agents understand the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (all 4 parameters have descriptions). The description adds use-case context but does not provide additional parameter-level details beyond what the schema already covers. Baseline score of 3 is appropriate as the description does not compensate for missing schema info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows the age of code in each file (last modified time) and identifies stale files. It uses specific verbs ('Show', 'Identifies') and distinguishes from sibling tools by focusing on file age rather than hotspots, churn, or other analyses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases: cleanup planning, onboarding, understanding evolving areas. It also includes a conditional note about requiring repo_path when not inside a git repo. However, it does not explicitly compare to siblings or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

commit_patternsCommit PatternsA

Read-only

Analyze when and how the team commits — day-of-week distribution, hour-of-day heatmap, commit size breakdown, and weekly velocity trends. Reveals work patterns like weekend deployments, late-night hotfixes, or declining commit velocity. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description
`days`	No	Number of days to look back (default: 90)
`author`	No	Filter to a specific author (exact match on name)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the agent knows it is safe. The description adds valuable context about the analysis performed and specific patterns revealed (weekend deployments, late-night hotfixes, declining velocity), enhancing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with key analysis types, followed by examples and a conditional note. Every sentence adds value, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the output in terms of distributions, heatmaps, breakdowns, and trends. It also covers the conditional requirement for repo_path. Misses explicit mention of return format (e.g., table or chart), but sufficient for selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with adequate descriptions for all three parameters. The description does not add significant meaning beyond the schema, aside from giving examples of output patterns. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it analyzes commit patterns including day-of-week distribution, hour-of-day heatmap, commit size breakdown, and weekly velocity trends, and distinguishes from sibling tools like hotspots, churn, etc. by focusing on temporal and size-based analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a specific note about requiring repo_path if the server wasn't started in a git repo, but doesn't explicitly state when to use this tool vs alternatives like contributor_stats or file_history. Usage context is implied but not differentiated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

complexity_trendComplexity TrendA

Read-only

Track how a file's complexity has changed over time by sampling its state at regular intervals in git history. Identifies files growing out of control, complexity spikes from specific commits, and files that need splitting. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description
`days`	No	Days to look back (default: 180)
`path`	Yes	File path to analyze (relative to repo root)
`samples`	No	Number of time samples (default: 10, max: 30)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, and the description does not contradict this. It adds behavioral context: it samples at regular intervals, identifies spikes, etc. No mention of destructive effects or permissions needed, but given readOnlyHint, the description sufficiently supplements the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a crucial note, all front-loaded with purpose and benefits. Every sentence earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks specifics about the return value or output format, and there is no output schema. While the tool's purpose and usage are clear, a user (or AI) might need to know what kind of data the trend provides (e.g., numeric values, charts?). This is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The description does not add extra semantics beyond the schema, such as format or constraints not already mentioned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool tracks how a file's complexity has changed over time via git history sampling. The specific verb 'track' and resource 'file complexity' are present, and the focus on trends distinguishes it from sibling tools like 'hotspots' which likely give a single snapshot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly details what the tool identifies: files growing out of control, complexity spikes from specific commits, and files needing splitting. It also provides a prerequisite note about repo_path when not in a git repo. However, it lacks explicit when-not-to-use guidance or direct comparisons with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

contributor_statsContributor StatisticsA

Read-only

Comprehensive contributor analytics: who is active, what areas they work in, their commit patterns, and collaboration graph. Useful for understanding team dynamics, identifying knowledge silos, onboarding planning, and workload distribution. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description
`days`	No	Days to look back (default: 90)
`author`	No	Filter to a specific author name (partial match)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds value by detailing the scope of analytics and the collaboration graph aspect. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus a note, front-loaded with purpose. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 simple params, no output schema, and good annotations, the description covers purpose, usage, and a key prerequisite. Missing return format details but acceptable given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 3 parameters are described in the schema (100% coverage). The description adds a redundant note about repo_path but doesn't clarify days or author beyond schema defaults. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides 'comprehensive contributor analytics' including specific aspects like activity, areas, commit patterns, and collaboration graph. It effectively distinguishes from sibling tools (e.g., hotspots, churn) by focusing on people rather than code or risk.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool (understanding team dynamics, knowledge silos, onboarding, workload distribution) and provides a critical prerequisite note about repo_path if not in a git repo. No exclusions, 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.

couplingTemporal CouplingA

Read-only

Find files that always change together (temporal coupling). These represent hidden dependencies not visible in imports or type signatures. If auth.ts and middleware.ts change together in 90% of commits, refactoring one without the other will likely break things. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description
`days`	No	Days to look back (default: 90)
`limit`	No	Max pairs to return (default: 20)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.
`min_commits`	No	Minimum shared commits to report (default: 3)
`path_filter`	No	Filter to files under this path
`min_coupling`	No	Minimum coupling score 0-1 (default: 0.5)

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, so the description adds value by explaining the concept of temporal coupling and giving a concrete example (auth.ts and middleware.ts). This context helps the agent understand the tool's output and significance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise with minimal waste. The example and note are useful, but the explanation of temporal coupling could be slightly tighter. Good front-loading of purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a data analysis tool with no output schema, the description adequately conveys what to expect (file pairs with coupling score). Parameters are well-covered in schema. Could mention results format briefly, but overall complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are documented. The description only adds the note about repo_path, which is already in the schema. No additional meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 always change together (temporal coupling), with a specific verb and resource. It distinguishes itself from sibling tools by focusing on hidden dependencies not visible in imports or type signatures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to find hidden dependencies) and includes a critical note about providing repo_path if not in a git repo. However, it does not explicitly contrast with sibling tools or give when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

file_historyFile HistoryA

Read-only

Show the full commit history of a specific file — who changed it, when, how much, and why. Useful for understanding why a file looks the way it does, finding when a bug was introduced, or tracing the evolution of a module. Uses --follow to track renames. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description
`days`	No	Number of days to look back (default: 365)
`path`	Yes	File path to analyze (e.g., "src/index.ts")
`limit`	No	Max commits to return (default: 30, max: 100)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=false, which the description does not contradict. The description adds valuable behavioral detail: 'Uses --follow to track renames.' This goes beyond annotations and helps the agent understand renames handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a note, front-loaded with the primary action and use cases. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, but the description gives a high-level idea of output fields (who, when, how much, why). It covers prerequisites and behavior. A more detailed output description would be beneficial, but overall it is sufficiently complete for a listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds a behavioral note about --follow, which relates to path handling, but does not provide additional parameter-level semantics beyond what the schema offers. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows the full commit history of a specific file, with details on who changed it, when, how much, and why. It distinguishes from sibling tools (e.g., hotspots, churn) by focusing specifically on file commit history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases (understanding file evolution, bug introduction, module tracing) and a prerequisite (require repo_path if not in git repo). However, it does not mention when not to use this tool or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hotspotsChange HotspotsA

Read-only

Find files that change most frequently. High change frequency correlates with defect density — the top 4% of files by change frequency typically contain 50%+ of bugs. Use this to identify files that need refactoring, better test coverage, or architectural attention. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description
`days`	No	Number of days to look back (default: 90)
`limit`	No	Max results to return (default: 20, max: 100)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.
`path_filter`	No	Filter to files under this path (e.g., "src/api")

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and description adds important behavioral context: the requirement for repo_path if not in a git repo, and the defect correlation insight. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences. Front-loads the core purpose, adds rationale, and ends with a critical usage condition. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides clear purpose, usage condition, and defect correlation context. No output schema exists, but description omits what the output looks like. Otherwise complete for a read-only listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 4 parameters with descriptions (100% coverage). Description only adds a conditional note on repo_path; does not significantly augment parameter meaning beyond what schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Find' and resource 'files that change most frequently', clearly distinguishing from siblings like churn and coupling. Adds context about defect correlation and actionable use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States to use for identifying files needing refactoring, but lacks explicit guidance on when not to use or alternatives among siblings. The repo_path condition is helpful but no comparison to other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

knowledge_mapKnowledge MapA

Read-only

Show who knows a file or directory best, weighted by recency, volume of changes, and commit frequency. Use this to find the right reviewer for a PR, identify knowledge silos, or plan for team transitions. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description
`days`	No	Days to look back (default: 365)
`path`	Yes	File or directory path to analyze (relative to repo root)
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, so no safety contradiction. The description discloses the weighting algorithm and the requirement for repo_path, providing useful behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three efficient sentences that front-load the purpose, then usage, then a critical note. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks output format description, but use cases and constraints are well-covered. For a read-only query tool, this is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 the note about repo_path but does not elaborate on days or path beyond what the schema already provides. No semantic gap, but also no added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool identifies who knows a file/directory best, using specific weighting criteria (recency, volume, commit frequency). It then lists concrete use cases (reviewer, silos, transitions), fully distinguishing it from sibling tools like hotspots or churn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases and a crucial prerequisite (provide repo_path if not in a git repo). It does not contrast directly with siblings, but the use cases imply when to choose this tool over alternatives like coupling or contributor_stats.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

release_notesRelease Notes GeneratorA

Read-only

Generate structured release notes from commits between two git refs. Groups by conventional commit type, extracts breaking changes, and links PR/issue references. Supports grouping by type, scope, or author. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description	Default
`to_ref`	No	Ending ref (default: HEAD)	HEAD
`from_ref`	Yes	Starting ref (tag, branch, or commit hash)
`group_by`	No	How to group commits (default: type)	type
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only indicate readOnlyHint=true. The description adds behavioral context: it generates release notes by grouping, extracting breaking changes, and linking PR/issue references. This goes beyond the annotation to explain what processing occurs, though it could detail more about output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences plus a note. The main action is front-loaded, the capabilities are listed succinctly, and the critical usage condition is highlighted as a note. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters (1 required) and no output schema, the description covers the core functionality and a key usage condition. It lacks explicit mention of return format, but the purpose is clear enough. Sibling tools are all different analyses, so no confusion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for each parameter. The description adds value by explaining the grouping behavior (conventional commit type) and the condition for repo_path. It also clarifies that grouping can be by type, scope, or author, which aligns with the enum but provides functional context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates structured release notes from commits between two git refs, groups by conventional commit type, extracts breaking changes, and links references. This specific verb-resource pair distinguishes it from sibling tools that analyze code hotspots, churn, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides a usage note about when repo_path is required ('If the server was not started inside a git repo, you MUST provide repo_path'). It does not give when-not-to-use or alternatives, but the context is clear enough for an agent to decide when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

risk_assessmentChange Risk AssessmentA

Read-only

Assess the risk profile of uncommitted changes or a specific commit range. Combines multiple signals: file hotspot history, change size, number of files, author familiarity, and file type sensitivity. Returns a score 0-100 with per-file breakdown and actionable recommendations. NOTE: If the server was not started inside a git repo, you MUST provide repo_path.

ParametersJSON Schema

Name	Required	Description	Default
`ref_range`	No	Git ref range to assess (e.g., "main..feature-branch"). Defaults to uncommitted changes.
`repo_path`	No	Absolute path to the git repository to analyze. Required if Claude Code was not opened in a git repo.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations confirm readOnlyHint=true, and description aligns with a non-destructive, analytical tool. Description adds value by detailing combined signals and return format (score, per-file breakdown, recommendations). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus a note. Front-loaded with main purpose and key details. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description adequately explains return values (score, breakdown, recommendations). Covers essential context for usage, including default behavior and prerequisite for repo_path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions. The tool description adds context: default behavior (uncommitted changes) and condition for repo_path (required if not in git repo). This enhances understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it assesses risk profile of uncommitted changes or a commit range. The verb 'assess' and resource 'risk profile' are specific. However, it does not explicitly differentiate from sibling tools like hotspots or churn, which may overlap in purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a conditional usage note about repo_path when server is not in a git repo. But it lacks guidance on when to use this tool vs alternatives, such as when to prefer risk_assessment over hotspots or branch_risk.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv1.0.0Jul 29, 2026
- First observedbranch_risk
- First observedchurn
- First observedcode_age
- First observedcommit_patterns
- First observedcomplexity_trend
- First observedcontributor_stats
- First observedcoupling
- First observedfile_history
- First observedhotspots
- First observedknowledge_map
- First observedrelease_notes
- First observedrisk_assessment

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct aspect of git analytics such as churn, coupling, contributor stats, and code age, with no functional overlap.

Naming Consistency5/5

All tool names are descriptive nouns or noun compounds in lowercase snake_case, following a consistent pattern (e.g., knowledge_map, commit_patterns).

Tool Count5/5

12 tools is well-scoped for a git intelligence server, covering analysis, risk, history, and collaboration without being overwhelming.

Completeness5/5

The toolset comprehensively covers code metrics, change patterns, ownership, risk, and history, with no obvious gaps for typical git analysis tasks.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Gluecron B
com.gluecron
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Version Control CI/CD & DevOps Code Analysis
622
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
GitHub Repository IntelligenceOAuth
io.github.heisencodex-jpg
Repo intel for AI coding agents: overview, PRs, contributors, hot files, CI, deps. Remote MCP.
Version Control CI/CD & DevOps Code Analysis
2

Related MCP Servers

my-local-mcp
Version Control Code Analysis Developer Tools
az-ka
F
license
Not graded
quality
D
maintenance
A local MCP server that turns AI clients into power users of local git repositories, enabling clone, browse, search, and inspect code without burning API tokens.
Updated 4 months ago (2026-05-17 06:33 UTC)
-
git-intel
Version Control Code Analysis Developer Tools
JBrightmanAI
A
license
A
quality
C
maintenance
A local Git intelligence MCP server that provides deep repository analytics including hotspots, churn, knowledge maps, and risk scoring, all computed from commit history without data leaving your machine.
Updated 2 months ago (2026-07-18 00:33 UTC)
12
MIT
gitl
Version Control Code Analysis CI/CD & DevOps
akomyagin
A
license
Not graded
quality
A
maintenance
AI code reviews and git activity digests with machine-readable risk scoring, available as an MCP server for use within an agent session.
Updated 15 days ago (2026-08-22 19:43 UTC)
1
MIT
git-summary-mcp
Version Control Code Analysis Developer Tools
yifanyifan897645
A
license
Not graded
quality
D
maintenance
An MCP server that gives AI assistants deep understanding of your local Git repositories, providing instant repo overviews, change summaries, blame analysis, changelogs, branch health checks, and history search.
Updated 5 months ago (2026-04-13 13:58 UTC)
62
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoangsonww/GitIntel-MCP-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

GitIntel - A Git Intelligence MCP Server for AI Agents

Architecture

Tools

Data Pipeline

Resources

Installation

Prerequisites

Build from source

Register with Claude Code

Register with any MCP client (manual JSON)

Configuration

Default Repository Resolution

Per-Tool repo_path Override

Resilient Startup (No-Crash Mode)

Usage Examples

Development

CLI REPL

Smoke Test

Security Model

Project Structure

Further Documentation

License

Author

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Per-Tool `repo_path` Override