Skip to main content
Glama
IN3PIRE

GitHub Health Monitor MCP

by IN3PIRE

GitHub Health Monitor MCP

MCP Badge

TypeScript Node.js MCP SDK License npm

πŸš€ Monitor, analyze, and improve your GitHub repository health with intelligent MCP tooling.

GitHub Health Monitor is a powerful Model Context Protocol (MCP) server that continuously tracks critical repository health metrics. Get instant insights into stale branches, aging pull requests, inactive issues, and security vulnerabilitiesβ€”all through standardized MCP interfaces that integrate seamlessly with AI assistants and automation tools.

πŸ“Š Key Features

Feature

Description

Default Threshold

🌿 Stale Branch Detection

Identify branches untouched for extended periods

>30 days

πŸ”„ Old PR Tracking

Find pull requests awaiting review/merge

>14 days

πŸ“‹ Unresponsive Issues

Flag issues needing attention

>7 days

πŸ”’ Security Alert Monitoring

Track potential security concerns

Real-time

🎯 MCP Native

Full MCP Resources & Tools integration

β€”

⚑ Configurable

Customize thresholds and behavior

Flexible

Related MCP server: Narad GitHub Agent

πŸš€ Quick Start

Prerequisites

  • Node.js 20+

  • npm or compatible package manager

  • GitHub Personal Access Token (optional but recommended for higher rate limits)

Installation & Setup

# Clone the repository
git clone https://github.com/IN3PIRE/github-health-monitor.git
cd github-health-monitor

# Install dependencies
npm install

# Build the project
npm run build

# Optional: Test the build
npm test

Testing Your Installation

# Run in development mode
npm run dev

# Or start the built version
npm start

πŸ”§ Configuration

Environment Variables

Configure behavior using these environment variables:

Variable

Description

Default

Example

GITHUB_TOKEN

GitHub PAT for authenticated requests

β€”

ghp_xxxxxxxxxxxx

STALE_BRANCH_DAYS

Days before branch considered stale

30

21

OLD_PR_DAYS

Days before PR considered old

14

7

UNRESPONSIVE_ISSUE_DAYS

Days before issue needs attention

7

3

MCP Client Integration

Add to your MCP-compatible client configuration:

{
  "mcpServers": {
    "github-health": {
      "command": "node",
      "args": ["/absolute/path/to/github-health-monitor/dist/index.js"],
      "env": {
        "GITHUB_TOKEN": "${GH_TOKEN}",
        "STALE_BRANCH_DAYS": "21"
      }
    }
  }
}
  • Claude Desktop: Add to claude_desktop_config.json

  • Cursor: Use MCP settings panel

  • Windsurf: Configure via MCP integrations

  • Custom Applications: Use MCP SDK directly

See the examples/ directory for ready-to-use configuration templates.

πŸ“– Usage Guide

As an MCP Tool

Trigger comprehensive health checks for any repository:

// Basic repository check
const healthReport = await mcpClient.callTool("check_health", {
  owner: "facebook",
  repo: "react"
});

// With custom thresholds for this specific check
const strictHealth = await mcpClient.callTool("check_health", {
  owner: "vercel",
  repo: "next.js",
  staleBranchDays: 14,
  oldPRDays: 7,
  unresponsiveIssueDays: 3
});

Tool Parameters:

  • owner (string, required): GitHub username or organization

  • repo (string, required): Repository name

  • staleBranchDays (number, optional): Override default stale threshold

  • oldPRDays (number, optional): Override PR age threshold

  • unresponsiveIssueDays (number, optional): Override issue timeout

As an MCP Resource

Read the current aggregated health metrics:

// Access latest health snapshot
const metrics = await mcpClient.readResource("health://current");

// Integrate with monitoring dashboards
const healthData = await mcpClient.readResource("health://metrics");

Available Resources:

  • health://current: Real-time repository health snapshot

  • health://metrics: Time-series health metrics

  • health://summary: Condensed health report

Direct API Usage

For programmatic integration without MCP:

# Build the server
npm run build

# Run directly with environment variables
GITHUB_TOKEN=ghp_xxx node dist/index.js

# Use with process managers
pm2 start dist/index.js --name "github-health-monitor"

πŸ“ˆ Example Outputs

Full Health Report

{
  "repository": "facebook/react",
  "timestamp": "2024-03-20T15:30:00Z",
  "staleBranches": [
    {
      "name": "feature/deprecated-component",
      "lastCommit": "2024-01-15T10:30:00Z",
      "author": "dev123",
      "daysStale": 45,
      "url": "https://github.com/facebook/react/tree/feature/deprecated-component"
    }
  ],
  "oldPRs": [
    {
      "number": 26784,
      "title": "Add experimental concurrent features",
      "author": "core-team",
      "createdAt": "2024-02-20T08:15:00Z",
      "daysOpen": 28,
      "reviewStatus": "changes-requested",
      "url": "https://github.com/facebook/react/pull/26784"
    }
  ],
  "unresponsiveIssues": [
    {
      "number": 24563,
      "title": "Bug: Suspense fallback shows briefly on fast networks",
      "author": "community-member",
      "createdAt": "2024-02-10T14:22:00Z",
      "lastUpdated": "2024-02-10T14:22:00Z",
      "daysSinceUpdate": 39,
      "assignee": null,
      "labels": ["bug", "needs-triage"],
      "url": "https://github.com/facebook/react/issues/24563"
    }
  ],
  "securityAlerts": [
    {
      "severity": "high",
      "package": "semver",
      "vulnerableVersion": "<7.5.2",
      "patchedVersion": "7.5.2",
      "description": "Regular Expression Denial of Service (ReDoS)"
    }
  ],
  "summary": {
    "totalStaleBranches": 3,
    "totalOldPRs": 7,
    "totalUnresponsiveIssues": 12,
    "totalSecurityAlerts": 1,
    "healthScore": 72
  }
}

Condensed Summary

{
  "repository": "vercel/next.js",
  "healthScore": 85,
  "status": "healthy",
  "requiresAttention": {
    "staleBranches": 2,
    "oldPRs": 3,
    "unresponsiveIssues": 5
  },
  "timestamp": "2024-03-20T15:30:00Z"
}

🎯 Use Cases

For Maintainers & Teams

  • Daily Standups: Quick health pulse before meetings

  • Release Readiness: Ensure no blockers before shipping

  • Cleanup Campaigns: Identify technical debt systematically

  • Security Audits: Monitor for new vulnerabilities

  • Onboarding: Help new contributors understand repository state

For Automation

  • CI/CD Integration: Gate deployments on health thresholds

  • Scheduled Reports: Daily/weekly health digests via automation

  • ChatOps: Query repository health from Slack/Discord bots

  • Dashboards: Feed metrics to Grafana, Datadog, etc.

πŸ” Troubleshooting

Common Issues

Rate Limiting

GitHub API rate limit exceeded. Retry after about 60 seconds. Set GITHUB_TOKEN for a higher request limit.
  • Solution: Set GITHUB_TOKEN environment variable for 5,000 req/hour limit (vs 60 for unauthenticated)

  • Token: Generate at github.com/settings/tokens with repo scope

  • Behavior: Short retry windows are retried with exponential backoff. Longer GitHub reset windows are returned as a clear health-check error with the retry time.

Connection Issues

Error: Failed to connect to MCP server
  • Verify Node.js version: node --version (requires 20+)

  • Check port availability: lsof -i :<port>

  • Review firewall settings

Permission Errors

Error: Resource not accessible by integration
  • Ensure token has access to target repository

  • Verify repository name spelling

  • Check organization access if applicable

Debug Mode

# Enable verbose logging
DEBUG=mcp:* npm run dev

# Or set globally
export DEBUG=mcp:*
node dist/index.js

Getting Help

  1. Check existing issues

  2. Review logs with DEBUG=mcp:*

  3. Verify configuration against examples in examples/

  4. Open a new issue with debug logs and reproduction steps

πŸ§ͺ Testing

# Run full test suite
npm test

# Run with coverage
npm test -- --coverage

# Lint check
npm run lint  # if configured

πŸ—οΈ Architecture

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚   MCP Client    │◄─────  MCP Protocol Layer  β”œβ”€β”€β”€β”€β–Ίβ”‚  Health Monitor β”‚
β”‚ (Claude/Cursor) β”‚     β”‚  (SDK Integration)   β”‚     β”‚     Server      β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                                       β”‚
                                                       β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚    GitHub API   │◄─────   Octokit Clients    │◄─────   Metrics       β”‚
β”‚   (REST/GraphQL)β”‚     β”‚ (REST + GraphQL)     β”‚     β”‚   Engine        β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Core Components

  • MCP Server: Handles protocol negotiation and tool/resource exposure

  • Metrics Engine: Orchestrates data collection and analysis

  • GitHub Adapter: Octokit-based API communication layer

  • Health Calculator: Scoring and status determination logic

🀝 Contributing Guidelines

We welcome contributions! Please see CONTRIBUTING.md for detailed guidelines.

Quick Contribution Steps

  1. Star the repo ⭐ (required for PR merging)

  2. Fork the repository

  3. Create a feature branch: git checkout -b feat/your-feature

  4. Make your changes with tests

  5. Commit with clear messages: git commit -m "feat: add new metric type"

  6. Push to your fork: git push origin feat/your-feature

  7. Open a Pull Request with detailed description

⚠️ Important: PRs can only be merged if you have ⭐ starred this repository!

Development Setup

# Fork and clone your fork
git clone https://github.com/YOUR_USERNAME/github-health-monitor.git
cd github-health-monitor

# Install dependencies
npm install

# Start development mode
npm run dev

# Run tests before committing
npm test

πŸ“„ License

MIT License - see LICENSE file for details.

Copyright Β© 2024 IN3PIRE

🌟 Support & Community

  • ⭐ Star this repository to show support and unlock PR merging capabilities

  • πŸ› Report bugs with detailed reproduction steps

  • πŸ’‘ Request features via GitHub Discussions

  • πŸ’¬ Join discussions about roadmap and improvements

Watch for Releases

Click πŸ‘€ Watch β†’ Releases only to get notified about new versions and security updates.


Built with ❀️ for the MCP ecosystem.

⭐ Don't forget to star the repo to enable PR merging and show your support!

Additional Information

  • Offers Easy Installation: Install via the LobeHub badge or a single npm install command; no complex manual setup required.

  • Has LICENSE: The repository includes an MIT LICENSE file.

  • Includes Prompts: Ready‑to‑use prompts are bundled for easy integration with MCP clients.

  • Includes Resources: Example configurations, schemas, and context resources are provided in the examples/ folder.

Available Tools

1 tool
check_healthC

Check health metrics for a GitHub repository

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesRepository name
ownerYesRepository owner (username or organization)

TDQS

C2.6/5.0
Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or any side effects. For a health check tool, this is a significant gap.

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 with no waste. It is front-loaded and efficient, though it could be structured with bullet points for clarity.

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 no annotations, the description should explain what 'health metrics' means and the return format. It is incomplete for an agent to use effectively.

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 description adds no extra meaning beyond what the schema already provides. Baseline 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?

Description states 'Check health metrics for a GitHub repository', which is a clear verb+resource but does not elaborate on what 'health metrics' specifically entail. No sibling tools exist, so no differentiation needed, but the description is essentially a tautology of the name and title.

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, what prerequisites exist, or when to avoid it. The description lacks context for decision-making.

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.

  1. 1 tool updatev1.0.0
    • First observedcheck_health

TDQS

C2.8/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of ambiguity or confusion with other tools.

Naming Consistency5/5

With a single tool, naming consistency is trivially maintained. The verb_noun pattern 'check_health' is clear and descriptive.

Tool Count2/5

A single tool for a health monitor feels too thin. Typically, a health monitoring server would benefit from multiple tools (e.g., listing checks, getting detailed metrics) to cover the domain.

Completeness1/5

The tool surface is severely incomplete. Only one health check tool cannot cover the full scope of monitoring repository health, such as different metric types or historical data.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/IN3PIRE/github-health-monitor-mcp'

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