Which integrations are available for this server?

Analyzes git repository metrics including commit statistics, author metrics, file churn analysis, team summaries, commit patterns, code ownership, velocity trends, collaboration metrics, quality metrics, and technical debt identification. Uses GitHub Actions for automated testing on pull requests as part of the CI/CD pipeline.

How do I use Git Metrics MCP Server?

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., "@Git Metrics MCP Server show me team summary and velocity trends for the last 2 weeks" 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.

Git Metrics MCP Server

by jonmatum

Overview Schema Related Servers Score Discussions

TypeScript

Local

Git Metrics MCP Server

MCP server for analyzing git repository metrics and understanding team health. Built for Kiro CLI (Amazon Q CLI) and other MCP clients.

Overview

This server provides tools to extract meaningful metrics from git repositories, helping teams understand their development patterns, identify risks early, and have better conversations about code quality and team health.

This is a mirror, not a microscope. Use it to reflect on team health and process quality, not to surveil individual behavior.

Related MCP server: Git Analytics MCP Server

Features

Commit Statistics: Track commits, additions, deletions, and files changed
Author Metrics: Per-developer performance breakdown
File Churn Analysis: Identify frequently modified files (quality indicators)
Team Summaries: Comprehensive team performance reports
Commit Patterns: Analyze when people commit (burnout detection)
Code Ownership: Bus factor and knowledge distribution analysis
Velocity Trends: Week/month productivity tracking
Collaboration Metrics: Team interaction patterns
Quality Metrics: Commit size, reverts, and fix rates
Technical Debt: Stale files and complexity hotspots
Conventional Commits: Analyze commit types, scopes, and release frequency

Production Features

Input Sanitization: Protection against command injection attacks
Structured Logging: JSON-formatted logs with timestamps for monitoring
Configurable Timeouts: Set GIT_TIMEOUT env var (default: 30s)
Error Boundaries: Graceful error handling with detailed logging
CI/CD: Automated testing on pull requests via GitHub Actions

Installation

From npm (Recommended)

npm install -g @jonmatum/git-metrics-mcp-server

From Source

git clone https://github.com/jonmatum/git-metrics-mcp-server.git
cd git-metrics-mcp-server
npm install
npm run build

Kiro CLI Configuration

Add to ~/.kiro/settings/mcp.json:

If installed globally:

{
  "mcpServers": {
    "git-metrics": {
      "command": "git-metrics-mcp-server",
      "args": []
    }
  }
}

If using npx:

{
  "mcpServers": {
    "git-metrics": {
      "command": "npx",
      "args": ["@jonmatum/git-metrics-mcp-server"]
    }
  }
}

If running from source:

{
  "mcpServers": {
    "git-metrics": {
      "command": "npx",
      "args": ["tsx", "/path/to/git-metrics-mcp-server/src/git-metrics.ts"]
    }
  }
}

Usage with Kiro CLI

Start Kiro CLI:

kiro-cli chat

Then ask natural language questions:

Get commit stats for /home/user/myproject since 2025-11-01
Show me team summary and velocity trends for the last 2 weeks
What's our bus factor? Who are single points of failure?
Show me commit patterns - are people committing late at night?
What files have the most churn since October?
Identify technical debt and complexity hotspots

For comprehensive analysis, see the Analysis Prompt.

Available Tools

Note on Date Ranges: The until parameter is inclusive - commits on the end date are included in results. For example, since="2025-11-01" until="2025-11-30" includes all commits from November 1st through November 30th.

get_commit_stats

Get overall commit statistics for a time period.

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD), inclusive
author (optional): Filter by author

Returns:

{
  "commits": 45,
  "additions": 1250,
  "deletions": 380,
  "filesChanged": 67,
  "netChange": 870
}

get_author_metrics

Detailed metrics per contributor.

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD)

Returns:

{
  "John Doe <john@example.com>": {
    "commits": 23,
    "additions": 650,
    "deletions": 120,
    "files": 34
  }
}

get_file_churn

Files with most changes (indicates complexity or issues).

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD), inclusive
limit (optional): Number of files, default 10

Returns:

[
  { "file": "src/main.ts", "changes": 15 },
  { "file": "src/utils.ts", "changes": 12 }
]

get_team_summary

Comprehensive team performance report.

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD)

Returns:

{
  "period": { "since": "2025-11-01", "until": "now" },
  "team": {
    "totalCommits": 45,
    "totalAdditions": 1250,
    "totalDeletions": 380,
    "contributors": 3
  },
  "contributors": { ... }
}

get_commit_patterns

Analyze when people commit (burnout detection).

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD)

Returns:

{
  "byDay": { "Mon": 45, "Tue": 38, ... },
  "byHour": { "09": 12, "14": 18, ... },
  "patterns": {
    "weekendPercentage": "15.2%",
    "lateNightPercentage": "8.3%"
  }
}

Note: Hours are shown in the author's local timezone at the time of commit.

get_code_ownership

Bus factor and knowledge distribution.

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD), inclusive

Returns:

{
  "totalFiles": 150,
  "sharedFiles": 80,
  "soloFiles": 70,
  "busFactor": [
    { "author": "John <john@example.com>", "exclusiveFiles": 25 }
  ]
}

get_velocity_trends

Track velocity over time.

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD), inclusive
interval (optional): "week" or "month", default "week"

Returns:

{
  "interval": "week",
  "trends": [
    { "period": "2025-11-01", "commits": 45, "additions": 1250, "deletions": 380 }
  ]
}

get_collaboration_metrics

Team interaction patterns.

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD), inclusive

Returns:

{
  "collaborativeFiles": 80,
  "topCollaborations": [
    { "pair": "John <-> Jane", "sharedFiles": 25 }
  ]
}

get_quality_metrics

Code quality indicators.

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD), inclusive

Returns:

{
  "averageCommitSize": 125,
  "medianCommitSize": 85,
  "revertRate": "2.3%",
  "fixRate": "18.5%"
}

get_technical_debt

Identify technical debt.

Parameters:

repo_path (required): Path to git repository
stale_days (optional): Days to consider stale, default 90

Returns:

{
  "staleFiles": [
    { "file": "old-module.js", "daysSinceLastChange": 180 }
  ],
  "complexityHotspots": [
    { "file": "big-file.js", "churn": 25 }
  ]
}

get_conventional_commits

Analyze conventional commit usage and release patterns.

Parameters:

repo_path (required): Path to git repository
since (required): Start date (YYYY-MM-DD)
until (optional): End date (YYYY-MM-DD), inclusive

Returns:

{
  "totalCommits": 25,
  "conventionalCommits": 25,
  "conventionalPercentage": "100.0%",
  "commitTypes": [
    { "type": "feat", "count": 5 },
    { "type": "fix", "count": 5 }
  ],
  "topScopes": [
    { "scope": "main", "count": 8 }
  ],
  "breakingChanges": 0,
  "recentReleases": [
    { "tag": "v2.0.1", "date": "2025-11-24" }
  ],
  "releaseFrequency": "8 releases since 2025-11-01"
}

Real-World Use Case: Team Health Analysis

Here's how a real engineering team used this tool to understand their development patterns across 5 repositories with 83 contributors:

The Challenge

A team needed to understand their development health across multiple repositories without manually parsing git logs. They wanted to identify risks, improve collaboration, and ensure sustainable work practices.

What They Discovered

Team Health Insights:

✅ Excellent work-life balance: Only 1.3% weekend commits
✅ Strong release discipline: 114 releases with 86.3% conventional commit adoption
⚠️ Bus factor risk: Two developers owned 61% of exclusive files in one repo
⚠️ High fix rate (36.3%) indicated reactive development in one project

Collaboration Patterns:

Best practice: One repo had 88.9% shared files (excellent knowledge distribution)
Needs improvement: Another repo had only 30.5% shared files
Identified top collaboration pairs for knowledge sharing

Code Quality Indicators:

Found complexity hotspots: Files with 66+ changes needing refactoring
Identified technical debt: Stale files and high-churn areas
Discovered optimal commit patterns: Median 17 lines (focused commits)

Actions Taken

Immediate: Scheduled knowledge transfer sessions for high bus factor areas
Process: Implemented pair programming to increase file sharing
Quality: Added pre-commit hooks to reduce fix rate
Culture: Replicated best practices from high-performing repos

Time Saved: What would have taken days of manual analysis was completed in minutes with natural language queries.

Read the full analysis: team-activity-analysis.md

Use Cases

✅ Good Use Cases

Sprint Retrospectives

Show me team summary and velocity trends for the last 2 weeks
What's our commit pattern? Are we burning out?

Risk Management

What's our bus factor? Who are single points of failure?
Show me code ownership - where do we have knowledge concentration?

Code Quality Reviews

Show me quality metrics and technical debt
What files have high churn and need refactoring?

Team Health Checks

Are people committing late at night or on weekends?
Show me collaboration metrics - is the team working together?

Onboarding Support

Get commit stats for new-dev@example.com since their start date
Show their velocity trend over the first 3 months

❌ What This Is NOT For

❌ Micromanagement or surveillance
❌ Comparing developers against each other
❌ Performance review ammunition
❌ Daily productivity tracking

Team Health Indicators You Can Track

Risk Management

Bus Factor: Knowledge concentration risk - who are single points of failure?
Code Ownership: File sharing patterns - is knowledge distributed?
Technical Debt: Stale files, complexity hotspots needing attention

Team Well-being

Burnout Indicators: Weekend/late-night commits - is the team overworked?
Work Patterns: When people commit - are boundaries healthy?
Velocity Trends: Sustainable pace or sprint-and-crash cycles?

Code Quality

Churn: Files changed repeatedly (quality indicator)
Commit Size: Focused commits vs. large dumps
Revert Rate: How often do we undo work?
Fix Rate: Reactive (high fixes) vs. proactive development

Collaboration Health

File Sharing: How much code is touched by multiple people?
Collaboration Pairs: Who works together most often?
Contribution Balance: Even distribution or bottlenecks?

Process Maturity

Conventional Commits: Adoption rate of commit standards
Release Frequency: How often do we ship?
Breaking Changes: How disruptive are our releases?

Tips for Responsible Usage

How to Use This Tool Well

Use natural language: Kiro understands context, so ask questions naturally
Focus on trends, not snapshots: Weekly/monthly patterns matter more than daily counts
Combine metrics: Ask for multiple analyses to get the full picture
Start conversations, don't end them: Use data to ask "why?" not to judge
Look for patterns: Team health indicators, not individual performance scores
Regular reviews: Weekly health checks (5 min), sprint retrospectives (15 min), monthly trends (30 min)

Red Flags (Don't Do This)

❌ Checking metrics more than once per day
❌ Creating leaderboards or rankings
❌ Setting commit quotas or targets
❌ Using metrics in performance reviews without context
❌ Comparing developers directly

Green Flags (Good Usage)

✅ You check trends weekly/monthly, not daily
✅ You ask "what does this tell us about our process?"
✅ You use it to start conversations, not end them
✅ You focus on team health, not individual performance
✅ You look for patterns, not outliers
✅ You use it to help, not judge

Remember: The best teams are built on trust, not metrics. Use this tool to support your team, not surveil them.

Development

npm run dev    # Run in development mode
npm run build  # Build for production
npm start      # Run built version

Testing

npm test              # Run tests
npm run test:watch    # Run tests in watch mode
npm run test:coverage # Run tests with coverage report

The test suite covers:

Date validation
Repository path validation
Git command execution
Commit data parsing
Core git operations (stats, metrics, churn, velocity)

License

MIT - See LICENSE file

Author

Jonatan Mata (@jonmatum)

Contributing

Issues and PRs welcome at https://github.com/jonmatum/git-metrics-mcp-server

Support

GitHub Issues: https://github.com/jonmatum/git-metrics-mcp-server/issues
MCP Documentation: https://modelcontextprotocol.io/

Available Tools

12 tools

get_author_metricsC

Get detailed metrics per author

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided. Description does not disclose behavioral traits such as read-only nature, output format, or any limitations. For a read operation, it should at least indicate it is safe and does not modify data.

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?

Single sentence, no fluff. However, it is overly brief given the complexity; could add more detail without becoming verbose.

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

Completeness2/5

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

With no output schema and 10 sibling tools, the description is insufficient. It does not explain what 'detailed metrics' entails or provide context on the scope of the data returned.

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?

Input schema covers all parameters with descriptions (100% coverage). Description adds no extra meaning beyond the schema, but baseline 3 is appropriate since schema already explains parameters.

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

Purpose3/5

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

Description states verb+resource ('Get detailed metrics per author') but is vague about what metrics are included. Does not differentiate from siblings like get_commit_stats or get_team_summary, which could overlap.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. For example, it does not clarify the difference from get_collaboration_metrics or when to prefer this over other metric tools.

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

get_code_ownershipC

Analyze code ownership and bus factor

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It only states 'Analyze', implying a read operation, but does not confirm non-destructiveness, required permissions, or any side effects. The agent cannot infer safety or resource impact.

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 a single sentence that immediately states the core purpose. It is highly concise with no redundant content, earning a score of 4.

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

Completeness2/5

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

Despite having three parameters and no output schema, the description omits explanation of the return format, the definition of 'bus factor', and any calculation details. This leaves the agent underinformed about what the tool produces.

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 each parameter having a clear description (e.g., 'Path to git repository'). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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?

The description uses a clear verb ('analyze') and identifies the specific resources ('code ownership and bus factor'). It is more specific than general sibling tools like 'get_author_metrics', but doesn't explicitly differentiate from them. Still, the purpose is well communicated.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus its siblings (e.g., get_author_metrics, get_collaboration_metrics). There is no mention of prerequisites or context, leaving the agent without decision-support information.

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

get_collaboration_metricsC

Analyze team collaboration patterns

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It only states 'analyze' but does not specify whether it is read-only, what computations are performed, or what the response contains. Critical behavioral traits like resource usage or side effects are absent.

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

Conciseness2/5

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

The description is a single sentence with no wasted words, but it is under-specified. True conciseness balances brevity with sufficient information; here, the lack of detail makes it inadequate for agent understanding. The structure is minimal but not effective.

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

Completeness2/5

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

Given the tool has 3 parameters, no output schema, and 10 sibling tools, the description is incomplete. It does not explain the output format, scope of analysis, or how it differs from similar tools. More context is needed for an agent to use it correctly.

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?

Input schema coverage is 100%, with each parameter having a description (repo_path, since, until). The description adds no additional meaning beyond the schema. Since the schema already documents parameters clearly, a baseline score of 3 is appropriate.

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

Purpose3/5

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

The description 'Analyze team collaboration patterns' provides a general verb ('analyze') and resource ('team collaboration patterns'), but lacks specificity. It does not differentiate from siblings like 'get_team_summary' or 'get_author_metrics', which could also analyze collaboration. The purpose is clear but vague.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The single sentence implies use for analyzing collaboration, but without comparisons to sibling tools, the agent has no decision support.

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

get_commit_patternsC

Analyze commit frequency patterns by day and hour

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the tool analyzes patterns, but does not specify if it is a read-only operation, what side effects exist (none expected), or the output format. Lacks details on data source (local repo) and any performance considerations.

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 a single, front-loaded sentence with no extraneous words. It is concise, though it could be expanded slightly to include more context without losing conciseness.

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

Completeness2/5

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

Given no annotations or output schema, the description should provide more context about the output (e.g., commit frequency distribution) and usage context. It lacks information about return structure and how the results are grouped.

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 descriptions for all three parameters (repo_path, since, until). The description adds no additional meaning beyond the schema, which is acceptable given full coverage.

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?

Description clearly states the tool analyzes commit frequency patterns by day and hour, which distinguishes it from sibling tools like get_commit_stats or get_velocity_trends. It is specific about the dimensions of analysis.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like get_commit_stats or get_author_metrics. The description does not state any prerequisites or exclusions.

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

get_commit_statsC

Get commit statistics for a repository

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional
`author`	No	Filter by author email/name, optional

TDQS

C2.9/5.0

Behavior2/5

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

Annotations are missing, so the description must carry the full transparency burden. It implies a read-only operation ('Get') but does not explicitly confirm safety, side effects, or authentication requirements.

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 a single, clear sentence with no wasted words. It is front-loaded and efficient.

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

Completeness2/5

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

The description is too minimal given the complexity of 4 parameters and no output schema. It does not explain what statistics are returned, leaving the agent uncertain about the tool's full behavior.

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 no additional meaning beyond what the schema already provides for the parameters.

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?

The description clearly states the action ('Get') and resource ('commit statistics'), but lacks specificity about what statistics are included. It does not differentiate from sibling tools like get_author_metrics or get_commit_patterns.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or which sibling tools might be more appropriate.

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

get_conventional_commitsC

Analyze conventional commit usage and release patterns

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only mentions analysis of commits but lacks details on side effects, read-only access, or data sources. Minimal transparency.

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

Conciseness3/5

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

The description is very short and front-loaded, but it sacrifices necessary detail. It achieves conciseness at the expense of completeness, earning an average score.

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

Completeness2/5

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

Lacking output schema and annotations, the description does not clarify return values, filtering behavior, or examples. It leaves significant gaps for an analysis tool with multiple parameters.

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 clear descriptions for each parameter. The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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?

The description states the tool analyzes conventional commit usage and release patterns, aligning with the tool name. However, it does not differentiate from sibling tools like get_commit_patterns, leaving some ambiguity about its unique focus.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives or any context about prerequisites or exclusions. The description is too brief to inform usage decisions.

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

get_file_churnB

Get files with most changes (churn)

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional
`limit`	No	Number of files to return, default 10

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavior. It only states the purpose without explaining what 'churn' means (e.g., definition, calculation method), safety, or side effects.

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 a single, concise sentence. It is not verbose, though a bit more structure could enhance clarity. It earns its place without redundant words.

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

Completeness2/5

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

The tool has 4 parameters, no output schema, and no annotations. The description lacks explanation of return format, pagination, or how churn is computed, making it incomplete for agent invocation.

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?

Input schema has 100% coverage with descriptions for all parameters. The description adds no extra meaning beyond what the schema provides, but the schema itself is adequate, so baseline score of 3 applies.

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 'Get files with most changes (churn)', effectively conveying the verb and resource. It distinguishes from sibling tools like get_commit_stats or get_quality_metrics by focusing on file churn.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus others, such as get_commit_patterns or get_author_metrics. No context on prerequisites or limitations is given.

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

get_quality_metricsC

Code quality indicators (commit size, reverts, etc)

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, required permissions, data aggregation, or how metrics are computed. The minimal description is insufficient for a tool with no annotations.

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

Conciseness3/5

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

The description is very short (one sentence) but lacks a leading verb, making it slightly unclear. It is concise but at the cost of completeness.

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

Completeness2/5

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

With no output schema and no annotations, the description is too brief. It fails to explain return format, aggregation period, or how metrics are calculated. The tool's complexity demands more context.

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 baseline is 3. The description adds no new semantics beyond the schema's parameter descriptions (which already specify date format and optionality). It neither enhances nor detracts.

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?

The description clearly indicates the tool provides code quality indicators with specific examples (commit size, reverts). It differentiates from siblings by focusing on quality metrics, though it lacks a verb like 'get' or 'retrieve'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_commit_patterns or get_technical_debt. The description implies usage for quality analysis but provides no exclusion criteria or context.

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

get_team_summaryC

Get comprehensive team performance summary

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It fails to disclose whether the tool is read-only, any side effects, or what 'comprehensive' entails (e.g., aggregation, filtering).

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 a single, concise sentence with no wasted words. It is appropriately front-loaded, though could benefit from more structure.

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

Completeness2/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 and no annotations, the description lacks sufficient detail. It does not explain what the summary includes, how results are structured, or any caveats.

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 each parameter described. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.

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?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('team performance summary'). While generic, it distinguishes from sibling tools like get_author_metrics or get_commit_stats by focusing on team-level performance.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_author_metrics or get_collaboration_metrics. No exclusions or context provided.

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

get_technical_debtC

Identify technical debt indicators

ParametersJSON Schema

Name	Required	Description	Default
`repo_path`	Yes	Path to git repository
`stale_days`	No	Days without changes to consider stale, default 90

TDQS

C2.7/5.0

Behavior1/5

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

No annotations are provided, and the description fails to disclose any behavioral traits such as whether this is a read-only operation, what permissions are needed, or side effects. The description carries the full burden and is completely silent.

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 a single concise sentence. It is appropriately front-loaded for a simple tool, though it could be slightly expanded without becoming verbose.

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

Completeness2/5

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

Given no output schema and two parameters, the description lacks context on what 'technical debt indicators' means or what the return value contains. There are clear gaps for a moderately capable 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 baseline is 3. The description adds no additional meaning beyond what the schema already provides, but does not need to since the schema is sufficient.

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?

The description clearly states it identifies technical debt indicators, a specific verb+resource. However, it does not differentiate from sibling tools like get_quality_metrics, which may have overlapping purpose.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. As a result, an AI agent lacks context for appropriate selection.

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

get_velocity_trendsC

Track velocity trends over time

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Path to git repository
`since`	Yes	Start date (YYYY-MM-DD)
`until`	No	End date (YYYY-MM-DD), optional
`interval`	No	week or month, default week

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. It does not disclose that this is a read-only operation, what data is returned, or any performance or authentication considerations.

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?

Single sentence with no extraneous words. Efficiently conveys the core purpose.

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

Completeness2/5

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

No output schema, so description should explain return value structure (e.g., list of data points, metrics). It fails to do so, leaving agent unsure of what the tool provides.

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?

Input schema has 100% description coverage, so description adds no additional meaning beyond what the schema already provides. Baseline of 3 applies.

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?

Description clearly states verb 'Track' and resource 'velocity trends over time'. It distinguishes from siblings by focusing on velocity, but does not explicitly contrast with other analytics tools.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like get_commit_stats or get_author_metrics. The description implies temporal trend analysis but offers no context for appropriate use.

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

health_checkA

Verify server is operational

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It states the tool verifies server operation but does not detail what that entails (e.g., network ping, database check) or the nature of the outcome.

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?

A single concise sentence that communicates the tool's purpose without unnecessary words. It is front-loaded and efficient.

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's simplicity (no parameters, no output schema), the description is nearly complete. However, mentioning the return format (e.g., status object) would enhance completeness.

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?

The input schema is empty with 100% coverage, so no parameters need explanation. The description adds no param info, which is acceptable given there are none.

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 verb 'Verify' and the resource 'server is operational', leaving no ambiguity about the tool's function. It is distinct from sibling tools which focus on specific metrics.

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 no explicit guidance on when to use this tool versus alternatives. While the purpose implies it's a preliminary check, no context is given about prerequisites or exclusions.

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.0Jan 11, 2026
- First observedget_author_metrics
- First observedget_code_ownership
- First observedget_collaboration_metrics
- First observedget_commit_patterns
- First observedget_commit_stats
- First observedget_conventional_commits
- First observedget_file_churn
- First observedget_quality_metrics
- First observedget_team_summary
- First observedget_technical_debt
- First observedget_velocity_trends
- First observedhealth_check

Install Server

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

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct metrics category (author, ownership, collaboration, commits, quality, etc.), with no functional overlap. Descriptions clearly differentiate them.

Naming Consistency4/5

All tools use a consistent 'get_' prefix followed by a descriptive noun phrase, except 'health_check' which omits the prefix. This minor deviation lowers the score slightly.

Tool Count5/5

12 tools cover a well-scoped metrics domain without being excessive or insufficient. Each tool provides meaningful and distinct functionality.

Completeness4/5

The set covers a broad range of git metrics (author, commits, collaboration, quality, technical debt). Minor gaps exist, such as missing PR or issue metrics, but overall it's fairly comprehensive.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

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

searchcode A
com.searchcode
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search Code Analysis Version Control
62
Keypup Engineering AnalyticsOAuth
io.keypup
Generate answers & visualizations from your engineering data to track software development health.
Developer Tools Data Visualization Project Management
21
CoderbudsOAuth
com.coderbuds
Your team's shipping standards, org map and delivery metrics, inside your coding agent.
1
ForumsOAuth
io.github.basehub-ai
Ask any GitHub repository a question. Get source-backed answers.
Search Version Control Developer Tools
336

Related MCP Servers

OSSInsight MCP Server
Version Control Search Developer Tools
damonxue
A
license
A
quality
D
maintenance
Provides GitHub data analysis for repositories, developers, and organizations, enabling insights into open source ecosystems through API calls and natural language queries.
Updated a year ago (2025-05-14 08:29 UTC)
5
14
MIT
Git Analytics MCP Server
Version Control Developer Tools Code Analysis
singhashish4000
F
license
B
quality
D
maintenance
Provides comprehensive Git repository insights including author statistics, branch health, and code churn analysis. It enables users to perform data-driven assessments of their codebase and track development patterns through the Model Context Protocol.
Updated a year ago (2025-06-15 15:51 UTC)
3
-
MCP Git Analysis Server
Version Control Developer Tools
Jaz-spec
F
license
Not graded
quality
D
maintenance
Analyzes local Git repositories to provide detailed insights into commit statistics, contributor activity, and frequently changed files. It allows users to query repository history and access structured activity data through the Model Context Protocol.
Updated a year ago (2025-10-09 15:46 UTC)
-
git-repo-analyzer-mcp
AntonyWhatsup
F
license
Not graded
quality
B
maintenance
Enables analysis of local Git repositories via standard git commands, providing insights like line authorship, commit frequency, code churn, and co-changed files.
Updated 2 months ago (2026-07-21 09:00 UTC)
-

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/jonmatum/git-metrics-mcp-server'

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