Github Repo Intelligence MCP server

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:///mcp) using the Streamable HTTP transport.
3. Call getrepohealth 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 getactivitymetrics, getissuehealth, getprhealth, or getcontributorinsights 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).

getrepohealth — headline verdict

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

Shortened. The full README is on GitHub.