Skip to main content
Glama
liminalpepe

x402-repohealth-mcp

by liminalpepe

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.devGET /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 own archived flag is true (overrides the score)

  • actively maintained — score >= 75

  • slowing down — score 45-74

  • likely 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-mcp

Or 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_health call costs ~3-4 GitHub requests. Fine for free/local/low-volume MCP use; the paid Worker adds a GITHUB_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 transport

src/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 tool
check_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesGitHub repo name, e.g. "react"
ownerYesGitHub repo owner / organization, e.g. "facebook"

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev0.1.0
    • First observedcheck_repo_health

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness5/5

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

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers