x402-repohealth-mcp
Provides tools for computing a health score for GitHub repositories, analyzing commit activity, issue responsiveness, and release cadence from live GitHub data.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@x402-repohealth-mcpHow healthy is facebook/react?"
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.
x402-repohealth-mcp
A free MCP (Model Context Protocol) server that computes a GitHub repo maintenance/abandonment health score from live GitHub data: is a repo actively maintained, slowing down, likely abandoned, or archived? No API key, no payment, no rate-limit games — just an MCP tool any MCP client can call.
This is the open funnel twin of a paid, x402-gated HTTP API:
x402-repohealth-poc.theliminalguy.workers.dev
— GET /repo-health/:owner/:repo, $0.01 USDC on Base per call via the
x402 payment protocol, for production/high-volume or
non-MCP (plain HTTP) / agent-automated use. Same scoring logic, same
output, just billed per call instead of free-via-MCP.
Why this exists
Agents that pick dependencies, tools, or libraries need to know whether a repo is safe to depend on — actively maintained vs. slowing down vs. effectively dead — and GitHub's own API only gives raw signals (commits, issues, releases), not the decision computed from them. This MCP server is the free/local half of filling that gap — try it for nothing via MCP; reach for the paid HTTP endpoint when you need it at volume or outside an MCP client.
Related MCP server: gts-repo-guardian
What it does
One tool, check_repo_health, takes a GitHub owner + repo and computes
a 0-100 health score across four weighted dimensions (commit recency,
commit activity, issue/PR responsiveness, release cadence, each 0-25
points), plus a verdict:
archived— GitHub's ownarchivedflag is true (overrides the score)actively maintained— score >= 75slowing down— score 45-74likely abandoned— score < 45
The response includes the full score breakdown, computed metrics (days
since last commit, commits in last 90 days, issue close ratio, etc.), and a
human-readable reasoning array built from the actual numbers — nothing is
hardcoded per-repo, it's fetched from GitHub's real public REST API and
scored at call time.
Install & run
npx x402-repohealth-mcpOr add it to an MCP client config (e.g. Claude Desktop's
claude_desktop_config.json):
{
"mcpServers": {
"repohealth": {
"command": "npx",
"args": ["-y", "x402-repohealth-mcp"]
}
}
}Tool: check_repo_health
Input:
{
"owner": "facebook",
"repo": "react"
}Output (MCP tool text content, JSON-stringified):
{
"owner": "facebook",
"repo": "react",
"fetchedAt": "2026-08-01T22:00:00.000Z",
"repoMeta": { "fullName": "facebook/react", "archived": false, "stargazersCount": 230000, "...": "..." },
"metrics": { "daysSinceLastCommit": 1, "commitsLast90Days": 100, "...": "..." },
"scoreBreakdown": { "commitRecency": 25, "commitActivity": 25, "issueResponsiveness": 17, "releaseCadence": 17 },
"score": 84,
"verdict": "actively maintained",
"reasoning": [
"Last commit 1 day ago (2026-07-31T...).",
"100+ commits in the last 90 days.",
"..."
]
}Scoring detail
Dimension | Points | Logic |
Commit recency | 0-25 | Days since last commit: <=14d->25, <=30d->21, <=90d->15, <=180d->9, <=365d->4, else 0 |
Commit activity | 0-25 | Commits in trailing 90 days: 0->0, 1-2->6, 3-9->13, 10-29->20, 30+->25 |
Issue/PR responsiveness | 0-25 | Of issues/PRs updated in the last 90 days: closed-ratio >=0.6 & median close <=14d->25, >=0.4->17, >=0.15->9, else->3. No recent activity -> neutral 14 |
Release cadence | 0-25 | Days since latest tagged release: <=180d->25, <=365d->17, <=730d->9, else 3. No releases ever -> neutral 12 |
archived: true from GitHub overrides the score-derived verdict entirely —
an archived repo is confirmed dead by the maintainer's own action, not
merely "likely abandoned."
What's real vs. limited
Real: every GitHub API call, the scoring math, and the MCP tool response are computed live at call time from that repo's actual GitHub data — nothing is hardcoded or mocked.
No auth against GitHub: uses GitHub's unauthenticated public REST API (60 requests/hour/IP shared across whoever runs this MCP server locally). A
check_repo_healthcall costs ~3-4 GitHub requests. Fine for free/local/low-volume MCP use; the paid Worker adds aGITHUB_TOKEN(5,000 req/hr) server-side.No caching: every call re-fetches GitHub live.
Local development
npm install
npm run dev # runs src/index.ts directly on stdio via tsx
npm run build # compiles to dist/ for the published npm package
npm run test:health # calls getRepoHealth() directly against real repos, no MCP transportsrc/github.ts, src/score.ts, src/health.ts, and src/types.ts are
the same GitHub-fetch + scoring logic as the paid Worker — this MCP server
is a thin src/index.ts wrapper around getRepoHealth().
When to use the paid HTTP twin instead
Use GET /repo-health/:owner/:repo
on the paid Worker instead of this MCP server when:
You're calling from outside an MCP client (plain HTTP, any language).
You need production/high-volume use and want to pay per call rather than share this MCP server's unauthenticated 60 req/hr GitHub budget.
Your agent already speaks x402 (e.g. via
x402-fetch/x402-axios) and can pay $0.01 USDC on Base per request.
Both routes call the exact same scoring function — output is identical.
License
MIT
Available Tools
1 toolcheck_repo_healthCheck Repo HealthA
Compute a maintenance/abandonment health verdict for a public GitHub repo from live GitHub data: a 0-100 score across commit recency, commit activity, issue/PR responsiveness, and release cadence, plus a verdict (actively maintained / slowing down / likely abandoned / archived) and human-readable reasoning. Free, unauthenticated MCP tool — the open twin of the paid x402-gated repo-health HTTP API (https://x402-repohealth-poc.theliminalguy.workers.dev/repo-health/:owner/:repo), same scoring logic, no payment required. Useful before depending on a library/tool: is this repo safe to build on? Uses GitHub's unauthenticated public REST API (60 requests/hour/IP) — for higher-volume or agent-automated x402-metered use, call the paid Worker endpoint instead.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub repo name, e.g. "react" | |
| owner | Yes | GitHub repo owner / organization, e.g. "facebook" |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: free, unauthenticated, uses GitHub's public REST API, enforces a 60 requests/hour/IP rate limit, and is read-only in nature. It does not explicitly cover failure modes (e.g., rate-limit exceeded, repo not found), but the most important operational constraints are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated. It front-loads the core purpose in the first sentence and packs usage, pricing, and API limits into the second. Every clause adds value, though it is slightly long and could be tightened without losing substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description enumerates the return components (score, verdict, reasoning) and the scoring dimensions. It covers use case, rate limits, free/unauthenticated nature, and the paid alternative, making it a complete and self-contained description for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% descriptive coverage for both parameters (owner and repo), so the baseline is 3. The description adds no extra parameter-level detail, but it does not need to; the schema examples are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Compute a maintenance/abandonment health verdict') on a clear resource ('a public GitHub repo') and details the output (0-100 score, verdict, reasoning). It fully satisfies the verb+resource+scope test and even differentiates itself from the paid API twin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Useful before depending on a library/tool' and contrasts with the paid alternative: 'for higher-volume or agent-automated x402-metered use, call the paid Worker endpoint instead.' It also mentions the rate limit (60 requests/hour/IP) as a constraint, offering clear context on when 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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
check_repo_health
TDQS
Scored across 1 tool
With only one tool, there is no possibility of overlap or confusion. The tool's purpose is clearly and specifically defined, making it unambiguous for agents.
The single tool name follows a clean verb_noun pattern ('check_repo_health'), which is internally consistent. With only one tool, there are no conflicting conventions.
The server has exactly one tool, which feels thin for a typical server but is justified by its narrow, single-purpose scope. It is borderline, as 1-2 tools are on the edge of being too few.
The tool covers the entire domain of repo health assessment, providing a score, verdict, and reasoning based on all relevant GitHub data. There are no obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
GitHub repo maintainability verdicts—maintained, slowing, at-risk, abandoned—via MCP.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Repository knowledge graph MCP server for codebase understanding and debugging.
Related MCP Servers
- AlicenseCqualityCmaintenanceMonitors and analyzes GitHub repository health by detecting stale branches, old pull requests, unresponsive issues, and security alerts. Integrates with MCP-compatible AI assistants and automation tools.1MIT
- FlicenseAqualityDmaintenanceMCP server for automated GitHub repository quality management, enabling review, README generation, cleanup, and monitoring.6-
- AlicenseAqualityBmaintenanceAn MCP server that provides operational tooling over the GitHub API — issue triage, PR review monitoring, repo health audits, and team access reviews.111MIT
- AlicenseNot gradedqualityDmaintenanceMCP server that checks npm and PyPI package health, providing maintenance signals, version info, CVE counts, and alternative suggestions.MIT