Github Repo Intelligence MCP

A maintainability verdict, not another dashboard.

GitHub Repo Health Check is an MCP server that answers the one question your dependency list can't: is this repo still maintained, or am I building on sand? Last-commit date lies. Star count lies. One signal isn't a verdict. So it returns a four-way read — Actively maintained, Slowing, At-risk, or Likely abandoned — synthesized across four dimensions (activity, issues, PRs, contributors), backed by the transparent, inspectable thresholds that produced it. Point it at any owner/name (or GitHub URL) and your agent gets a verdict it can act on, plus the raw numbers so it can see exactly why. Same repo state + config → the same verdict, every time.

It runs as a Standby Actor on the Apify platform — always warm, reachable over the Streamable HTTP transport at the /mcp path, with API access, scheduling, and monitoring included.

See it in action

Two repos, two very different verdicts — then a drill-down into the metrics behind them, all over MCP:

Who is this for?

• Agent developers whose agents need to decide whether to adopt, recommend, or monitor an open-source library or tool
• Dependency due-diligence — vetting whether a package's upstream is alive before committing to it
• OSS vendor evaluation — checking the health of a project before building on it
• Repo triage at scale — ranking a list of candidates by health before a human reviews them
• Automated monitoring — scheduling recurring checks and alerting when a dependency starts slowing

If you've ever asked "is this repo abandoned?" or run a GitHub repo health check by hand, this server does it programmatically at any scale.

Why use GitHub Repo Health Check?

Most GitHub tools hand an agent raw API access and leave the judgment to the model — inconsistent, hand-rolled heuristics on every call. This server does the synthesis for you.

The differentiator is judgment, not raw access: every verdict ships alongside the pinned thresholds and raw metrics that produced it, so the agent (and you) can audit the reasoning. Same repo state + same config always yields the same verdict.

One GitHub fetch per repository is cached and shared across all five tools. Drilling from the headline verdict into a specific dimension costs no extra upstream calls.

How to use GitHub Repo Health Check

1. Deploy the Actor — run it in Standby mode on Apify. It boots with no input required.
2. Connect your MCP client to the Standby endpoint (https://<your-standby-url>/mcp) using the Streamable HTTP transport.
3. Call get_repo_health with a repo argument ("owner/name" or any https://github.com/owner/name URL) to get the headline verdict.
4. Add a GitHub token — this is effectively required. The Actor's primary data source (GitHub's GraphQL API) rejects unauthenticated requests, and Apify's shared egress IPs exhaust GitHub's anonymous quota almost immediately. Without a token the Actor returns rate-limit errors, not verdicts. See Input for setup.
5. Drill into dimensions — call get_activity_metrics, get_issue_health, get_pr_health, or get_contributor_insights when you need detail beyond the headline. All five tools read from the same cached payload.

The five tools

All tools take a single repo argument — either "owner/name" or any https://github.com/owner/name[/...] URL (case-insensitive).

get_repo_health — headline verdict

Returns the overall verdict, a per-dimension breakdown, and a rationale string explaining the worst dimension.

{
  "repo": "honojs/hono",
  "overallVerdict": "Actively maintained",
  "dimensions": {
    "activity":     { "verdict": "Healthy", "lastCommitDaysAgo": 1, "commits90d": 412 },
    "issues":       { "verdict": "Healthy", "medianFirstResponseDays": 2.4, "staleOpenRatio": 0.12 },
    "pullRequests": { "verdict": "Healthy", "mergeRate": 0.88, "oldestOpenPrDaysAgo": 14 },
    "contributors": { "verdict": "Healthy", "totalContributors": 312, "busFactorFlag": false }
  },
  "rationale": "Overall: activity is Healthy; weakest dimension is issues (Healthy).",
  "stars": 21000,
  "forks": 640,
  "fetchedAt": "2026-06-01T00:00:00.000Z",
  "authenticated": true
}

get_activity_metrics — commit cadence and momentum

Commit volumes over trailing windows, release frequency, and a momentum trend.

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "lastCommitDaysAgo": 1,
  "commits30d": 140,
  "commits90d": 412,
  "commits365d": 1680,
  "releaseCount365d": 48,
  "lastReleaseDaysAgo": 3,
  "momentumTrend": "steady",
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

momentumTrend is accelerating / steady / declining, derived from the 30-day commit rate vs the 90-day rate. Repos that tag rather than cutting GitHub Releases will show releaseCount365d: 0 and lastReleaseDaysAgo: null — this does not by itself degrade the verdict.

get_issue_health — responsiveness and backlog hygiene

How quickly maintainers respond to issues and how much of the backlog has gone stale.

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "openIssues": 32,
  "closedIssues": 1840,
  "openClosedRatio": 0.017,
  "medianFirstResponseDays": 2.4,
  "medianTimeToCloseDays": 5.1,
  "staleOpenIssues": 4,
  "staleOpenRatio": 0.12,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

An issue is stale if untouched for more than 90 days. Medians are null when no qualifying events exist in the analysis window — absence is not the same as zero.

get_pr_health — PR throughput and queue age

How effectively the project merges or closes contributions, and how old the oldest open PR is.

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "openPrs": 6,
  "mergedPrs": 220,
  "closedUnmergedPrs": 30,
  "mergeRate": 0.88,
  "medianTimeToMergeDays": 1.2,
  "oldestOpenPrDaysAgo": 14,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

mergeRate excludes still-open PRs from the denominator. It is null when no PRs have been decided in the analysis window.

get_contributor_insights — concentration and bus-factor risk

How many contributors the project has and whether commit activity is dangerously concentrated.

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "totalContributors": 312,
  "topContributorShare": 0.28,
  "topTwoContributorShare": 0.41,
  "busFactorFlag": false,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

busFactorFlag is true when the top contributor owns more than 50% of commits, or the top two together own more than 80%. totalContributors is the repository's all-time contributor count (sourced from GitHub's stable /contributors list endpoint) — it is not a 90-day-active count.

Verdict thresholds

Verdicts come from pinned, transparent thresholds — same repo state plus same config always yields the same verdict.

Overall verdict is activity-dominant, evaluated top-down (first match wins):

1. Likely abandoned — activity is Likely abandoned (no commits in > 365 days).
2. At-risk — activity is At-Risk, or any two of {issues, PRs, contributors} are At-Risk.
3. Actively maintained — activity is Healthy and no dimension is At-Risk.
4. Slowing — everything else (e.g. activity Moderate, or Healthy activity with one At-Risk dimension).

Input

The server boots with no input required (a Standby constraint — all fields are optional in the schema so the container never crash-loops on startup). In practice, you must provide a GitHub token for the Actor to return verdicts rather than rate-limit errors.

GitHub token setup. A classic token with no scopes is sufficient for public repositories. A fine-grained token scoped to specific repos works for private-repo analysis. For Standby deployments the recommended approach is to set a GITHUB_TOKEN environment variable on the Actor (stored as a secret) rather than pasting the token into the input field — it persists across restarts. Both paths work; both are stored as secrets and never exposed in logs.

Output