About abandoncheck
abandoncheck scores dependency maintenance from caller-provided repository signals, for teams assessing dependency health. Its local, fixed scoring rules return a verdict and the reasons behind it without fetching repositories or inspecting code.
Key features
- 01Scores repository maintenance signals
- 02Returns verdict, score, and reasons
- 03Classifies release and commit recency
- 04Validates inputs with path-specific errors
Use cases
- 01Review dependency health during maintenance
- 02Compare dependencies using supplied signals
MCP support
The MCP server exposes `check_dep_maintenance`, which evaluates caller-supplied signals and returns a verdict, score, signals, and reasons. It performs no network lookup.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
Tools
1Saved tool list · updated 1w ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| name | string | Yes | Dependency name |
| archived | boolean | Yes | Whether the dependency's repository is archived |
| open_issues | integer | No | Open issue count (optional; reported, never scored) |
| last_commit_days | integer | No | Days since the last commit (optional; omit if unknown) |
| maintainer_count | integer | No | Number of active maintainers (optional) |
| last_release_days | integer | No | Days since the last release (optional; omit if none) |
| recent_commits_90d | integer | No | Commits in the last 90 days (optional) |
Details
From the project READMEabandoncheck
Every dependency in a tree was chosen at some point, often years ago, and the question that matters later is a plain one: is anyone still looking after this thing? abandoncheck answers it without guessing. You supply the factual signals you already have — whether the repository is archived, how long since the last release and the last commit, how many commits landed in the last 90 days, how many maintainers are active, and how many issues sit open — and it returns a verdict, a score, the bands those signals fall into, and the exact reasons behind the number.
Nothing is fetched and nothing is inferred about the code
itself. An archived repository settles the question on its
own: the score is 0 and the verdict is abandoned, no
matter how fresh the other signals look. Otherwise the
score starts at 100 and loses points in a fixed order for
missing or stale release information, missing or stale
commit information, a silent last 90 days, and a thin
maintainer bench — never below 0. The open issue count is
echoed back in the signals and deliberately never scored:
a busy tracker can mean a popular project as easily as a
neglected one, and this tool sticks to signals that point
one way.
The bands make the score auditable at a glance. A release
180 days old or newer is fresh, then aging to 365,
stale to 730, and dormant beyond that; with no release
information the band is unknown. Commits run on a tighter
clock: active to 90 days, slowing to 180, quiet to
365, and silent beyond that. Scores of 80 and up read as
maintained, 50 and up as at_risk, anything above 0 as
likely_abandoned, and 0 as abandoned. When no deduction
applies at all, the single reason is "no adverse signals";
otherwise each reason names the deduction that fired, in
the order it was applied.
Malformed input — a missing, empty, or non-string name,
a missing or non-boolean archived, or any optional count
that is not an integer of at least 0 — is a validation
error naming the offending path, with no partial result.
Unknown extra fields are ignored. The computation is pure
and local: no network, no configuration, and no repository
is read or touched.
CLI
npx @reneturcios/abandoncheck check --input args.json
npx @reneturcios/abandoncheck --version
args.json contains the full arguments object:
{
"name": "leftpad",
"archived": false,
"last_release_days": 45,
"last_commit_days": 12,
"recent_commits_90d": 18,
"maintainer_count": 3,
"open_issues": 27
}
The result is printed as JSON:
{
"name": "leftpad",
"verdict": "maintained",
"score": 100,
"signals": {
"archived": false,
"last_release_band": "fresh",
"last_commit_band": "active",
"recent_commits_90d": 18,
"maintainer_count": 3,
"open_issues": 27
},
"reasons": ["no adverse signals"]
}
Absent optional signals echo as null in signals, and
their bands are "unknown". Exit codes: 0 on success,
1 on a runtime error (including an unreadable or invalid
input file, or invalid input), 2 on a usage error.
MCP server
npx -y @reneturcios/abandoncheck mcp
MCP client config:
{
"mcpServers": {
"abandoncheck": {
"command": "npx",
"args": ["-y", "@reneturcios/abandoncheck", "mcp"]
}
}
}
Tools
-
check_dep_maintenance— Judge whether one dependency is maintained, from caller-supplied factual signals only.name(string, required, non-empty) — dependency namearchived(boolean, required) — whether the dependency's repository is archivedlast_release_days(integer, optional, at least 0) — days since the last release; omit if nonelast_commit_days(integer, optional, at least 0) — days since the last commit; omit if unknownrecent_commits_90d(integer, optional, at least 0) — commits in the last 90 daysmaintainer_count(integer, optional, at least 0) — number of active maintainersopen_issues(integer, optional, at least 0) — open issue count; reported, never scored
Returns
{name, verdict, score, signals, reasons}, wheresignalsis{archived, last_release_band, last_commit_band, recent_commits_90d, maintainer_count, open_issues}.
Docker
docker run -i ghcr.io/cloudcorprecords/abandoncheck
docker run --rm -v "$PWD:/w" ghcr.io/cloudcorprecords/abandoncheck check --input /w/args.json
Development
npm install
npm run build # tsc -> dist/
npm test # tsx --test test/*.test.ts (pure local, no network)
npm run dev # run the CLI from source
License
MIT — Copyright (c) 2026 Rene Turcios
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.