Package Health Check

Check a package's repository health

check_repo_health

Read-onlyIdempotent

Use this when the user asks whether the project behind a package is maintained, abandoned or trustworthy: "is the express repo still maintained?", "when was the last commit to left-pad?", "what is the OpenSSF Scorecard of requests?". Pass the public package name and ecosystem (npm or pypi), or repo as a GitHub owner/repo. Returns the repository, the last commit date and days since, whether it is archived, stars, forks, open issues, the OpenSSF Scorecard score with its weakest checks, the npm maintainer count, and a verdict (healthy, watch, risky or unknown) with reasons. For known vulnerabilities of a version use check_package instead.

Input Schema

Name	Required	Description
`name`	No	Public package name, such as "express" or "requests". Its latest release names the repository.
`repo`	No	A GitHub repository instead of a package: "owner/repo" or its github.com url
`ecosystem`	No	npm (the default) or pypi; used with name

Output Schema

Name	Required	Description
`name`	No
`as_of`	Yes	ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.
`forks`	No
`stars`	No
`notice`	Yes
`source`	Yes	Who the data comes from, to cite and to check it against.
`status`	Yes
`license`	No
`message`	No
`reasons`	No	Why, worst first
`verdict`	No
`version`	No	The latest release, whose metadata named the repository
`archived`	No
`ecosystem`	No
`scorecard`	No
`openIssues`	No
`repository`	No
`unavailable`	No	Parts of the answer that could not be read right now
`lastCommitOn`	No	Date of the newest commit on the default branch, YYYY-MM-DD
`npmMaintainers`	No	Accounts that may publish the package on npm
`daysSinceLastCommit`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 23, 2026

addedInput schema / examples

Added value: +[
+  {
+    "ecosystem": "npm",
+    "name": "express"
+  }
+]

addedOutput schema / properties / as_of

Added value: +{
+  "description": "ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.",
+  "type": "string"
+}

addedOutput schema / properties / source / description

Added value: +"Who the data comes from, to cite and to check it against."

addedOutput schema / properties / source / properties

Added value: +{
+  "name": {
+    "type": "string"
+  },
+  "url": {
+    "type": "string"
+  }
+}

addedOutput schema / properties / source / required
```
Added value: +[
+  "name",
+  "url"
+]
```

changedOutput schema / properties / source / type

Previous value: -"string"New value: +"object"

changedOutput schema / required

Previous value: -[
-  "status",
-  "source",
-  "notice"
-]New value: +[
+  "status",
+  "source",
+  "notice",
+  "as_of"
+]

AddedOct 10, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered; the description adds meaningful context that the tool fans out to GitHub and OpenSSF data and synthesizes a judged verdict (healthy/watch/risky/unknown), which tells the agent results are aggregated and opinionated rather than raw. It stops short of noting failure modes (unknown verdict for unresolvable repos, upstream rate limits), which would have earned a 5.

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?

Front-loaded with the usage trigger and tight for the amount of coverage it delivers; every clause maps to a decision the agent must make. The three inline example questions are somewhat redundant with the trigger sentence but they are cheap and disambiguating.

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?

Despite an output schema existing, the description usefully summarizes the payload (last commit + days since, archived flag, stars/forks/issues, Scorecard score and weakest checks, maintainer count, verdict with reasons), so the agent can answer the user's question without a follow-up call. Ambiguity about input mode is fully resolved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a 3 would be the floor, but the description adds the key relational fact the schema only implies: name+ecosystem OR repo, i.e. the two input modes are alternatives rather than complements. It also states the package must be public and that the repo is derived from the latest release.

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?

Specific verb (check) + resource (a package's repository health), sharpened by real user phrasings ("is the express repo still maintained?") and an explicit enumeration of what the verdict covers (maintenance, abandonment, trustworthiness). It is clearly distinct from check_package (vulnerabilities) by both subject matter and the closing redirect.

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?

Opens with an explicit trigger condition ("Use this when the user asks whether the project behind a package is maintained...") and supplies three example questions that map directly to invocation. It also names the exclusion: "For known vulnerabilities of a version use check_package instead."

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Package Health Check tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.