pkg-health-mcp
Scores GitHub repositories for maintenance health using commit and release activity, maintainer diversity, issue responsiveness, OpenSSF Scorecard, and license; accepts owner/repo or GitHub URLs and can be used as a GitHub Action.
Scores npm packages for maintenance health by analyzing release activity, maintainers, issue responsiveness, download trends, OpenSSF Scorecard, and license; can scan package.json and npm lock files.
Scores PyPI packages for maintenance health by analyzing release activity, maintainers, issue responsiveness, download trends, OpenSSF Scorecard, and license; can scan Python manifests and lock files such as requirements.txt, pyproject.toml, poetry.lock, and uv.lock.
pkg-health-mcp
Is this dependency still maintained? Find out before you install it.
pkg-health-mcp scores npm packages, PyPI packages and GitHub repositories from 0 to 100 for maintenance health. It combines release and commit activity, active maintainers, issue response times, download trends, OpenSSF Scorecard and license into an A–F grade and a plain-language list of risks.
Use it three ways, all built on the same engine:
MCP server for Claude Code, Claude Desktop, Cursor, VS Code and any other MCP client, so your AI agent checks a package before it suggests one.
CLI to audit a manifest or lock file, including transitive dependencies.
GitHub Action to add a health report to every pull request and fail the build below a threshold.
$ npx -y pkg-health-mcp scan package.json
F 10/100 request@2.88.2 [npm]
10 Recent activity last release 2444d ago
5 Maintainer diversity 0 active committer(s) in the last 12 months
10 Issue responsiveness median 113.2d to first maintainer response, 38% answered (8 issues)
65 Download trend 171.5M downloads in last 90d (-5% vs previous 90d)
34 OpenSSF Scorecard 3.4/10
100 License Apache-2.0 (permissive)
! Deprecated: request has been deprecated, see https://github.com/request/request/issues/3142
! No release in 6+ years
! No commits in the last 12 months
! 62% of recent issues got no maintainer response
F 10/100 left-pad@1.3.0 [npm]
! Deprecated: use String.prototype.padStart()
! Source repository is archived
A 99/100 express@5.3.0 [npm]
100 Recent activity last release 12d ago, last commit 4d ago
100 Maintainer diversity 42 active committer(s) in the last 12 months
100 Issue responsiveness median 0.2d to first maintainer response, 87% answered (53 issues)
100 Download trend 1.6B downloads in last 90d (+22% vs previous 90d)
85 OpenSSF Scorecard 8.5/10
100 License MIT (permissive)Contents
Related MCP server: pkgtruth
Why
A typical project pulls in hundreds of open-source packages. Some of them are quietly abandoned: no releases for years, one maintainer who moved on, issues piling up unanswered. When a vulnerability shows up in one of those, nobody fixes it.
Checking this by hand means opening each package's GitHub page and reading commit dates, issue lists and contributor graphs. Nobody does that for every dependency, and AI coding assistants never do it: they happily suggest whatever library was popular in their training data, including ones deprecated years ago.
pkg-health-mcp makes that check a single tool call, so:
AI agents can avoid recommending abandoned libraries and flag risky ones in existing code.
Engineering leads can audit a project's dependencies in seconds.
Security and compliance teams get a repeatable, explainable maintenance signal alongside vulnerability scanners.
Features
Three MCP tools: score one package, scan a whole manifest, or compare alternatives.
npm, PyPI and any GitHub repository. Pass
owner/repoor a GitHub URL to score a project that is not published to a registry.Manifests and lock files:
package.json,requirements.txt,pyproject.toml(PEP 621 and Poetry), pluspackage-lock.json,yarn.lock,pnpm-lock.yaml,poetry.lockanduv.lockfor transitive dependencies. Git dependencies on GitHub are scored as repositories.Six signals: release and commit recency, active committers, time to first maintainer response, download trend, OpenSSF Scorecard, license.
CI gating:
--fail-under <score>, Markdown output for job summaries, and a ready-made GitHub Action.Disk cache shared across runs (12 hours by default), so repeated scans cost almost no API calls.
Explainable output: every score comes with per-signal details and a list of concrete risks, not just a number.
Honest about missing data: unreachable APIs lower a
confidencevalue instead of the score.No account or API key needed. An optional
GITHUB_TOKENraises GitHub's rate limit.Local and private: runs on your machine, talks directly to public APIs, no backend and no telemetry.
Human, JSON and Markdown output for terminals, scripts and CI job summaries.
Quick start
Requires Node.js 20 or later. Nothing to install globally: npx downloads the package on first run.
Claude Code
claude mcp add pkg-health -e GITHUB_TOKEN=github_pat_xxx -- npx -y pkg-health-mcpLeave out -e GITHUB_TOKEN=… to run without a token.
Claude Desktop
Open Settings → Developer → Edit Config, or edit the file directly:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"pkg-health": {
"command": "npx",
"args": ["-y", "pkg-health-mcp"],
"env": { "GITHUB_TOKEN": "github_pat_xxx" }
}
}
}Restart Claude Desktop. The three tools appear under the tools icon.
Cursor
Add the same block to ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project). See examples/cursor-mcp.json.
VS Code
Add to .vscode/mcp.json. VS Code asks for the token the first time the server starts, so it never sits in the file. See examples/vscode-mcp.json.
{
"inputs": [
{ "type": "promptString", "id": "github-token", "description": "GitHub token (optional)", "password": true }
],
"servers": {
"pkg-health": {
"type": "stdio",
"command": "npx",
"args": ["-y", "pkg-health-mcp"],
"env": { "GITHUB_TOKEN": "${input:github-token}" }
}
}
}Any other MCP client
The server speaks MCP over stdio. Start it with:
npx -y pkg-health-mcpGitHub token
The token is optional, but strongly recommended for anything beyond a handful of packages.
Without token | With token | |
GitHub API limit | 60 requests/hour | 5,000 requests/hour |
Packages per hour (≈3–5 GitHub calls each) | about 15 | about 1,000+ |
Time to first maintainer response | not measured (needs GraphQL) | measured |
When the limit is hit, packages are still scored from registry data and the report includes a warning saying so. Responses are cached on disk, so a second scan of the same project within 12 hours makes no GitHub calls at all.
Creating one: GitHub → Settings → Developer settings → Fine-grained tokens → Public repositories (read-only), no additional permissions. The token is sent only to api.github.com. GH_TOKEN is accepted as well.
Tools
All tools are read-only and annotated as such (readOnlyHint, idempotentHint), so clients can run them without asking for confirmation.
check_package
Score one package.
Parameter | Type | Default | Description |
| string | — | Package name ( |
|
|
| Where to look. |
Returns a one-line summary followed by the full report:
left-pad: 10/100 (F), likely abandoned or unsafe to adopt. Main risk: Deprecated: use String.prototype.padStart().{
"package": "left-pad",
"ecosystem": "npm",
"version": "1.3.0",
"score": 10,
"grade": "F",
"confidence": 1, // share of the scoring weight backed by real data
"summary": "left-pad: 10/100 (F), likely abandoned or unsafe to adopt. ...",
"risks": [
"Deprecated: use String.prototype.padStart()",
"Source repository is archived",
"No release in 8+ years",
"No commits in the last 12 months"
],
"subscores": [
{ "key": "activity", "label": "Recent activity", "weight": 0.3, "score": 0, "detail": "Repository is archived (read-only)" },
{ "key": "maintainers", "label": "Maintainer diversity", "weight": 0.2, "score": 5, "detail": "0 active committer(s) in the last 12 months" },
{ "key": "issues", "label": "Issue responsiveness", "weight": 0.15, "score": 15, "detail": "No issues closed in 12 months, 10 open" },
{ "key": "downloads", "label": "Download trend", "weight": 0.15, "score": 100, "detail": "25.9M downloads in last 90d (+57% vs previous 90d)" },
{ "key": "scorecard", "label": "OpenSSF Scorecard", "weight": 0.1, "score": 39, "detail": "3.9/10" },
{ "key": "license", "label": "License", "weight": 0.1, "score": 100, "detail": "WTFPL (permissive)" }
],
"repository": "https://github.com/left-pad/left-pad",
"warnings": []
}A deprecated package is capped at 10 even when its downloads are still growing: popularity does not mean anyone is fixing it.
A GitHub repository is scored the same way, with its latest GitHub release as the version. There are no download statistics for a repository, so that signal is left out:
expressjs/express: 98/100 (A), healthy.scan_manifest
Score every dependency in a manifest or lock file and list the riskiest first.
Parameter | Type | Default | Description |
| string | — | Path to a local manifest or lock file. Only the file names listed below are accepted |
| string | — | Full text of the file, if not passing |
| string | — | Optional, with |
| boolean |
| Also score |
| integer |
| Upper limit (1–1000) on packages scored |
Pass path for lock files: they are often too large to paste into a tool call.
Supported formats:
File | What is read | What is skipped |
|
|
|
| Package names with extras, version specifiers and environment markers; |
|
| PEP 621 |
|
| Every installed package (lockfile v1, v2, v3), with | Linked workspaces, bundled packages |
| Every entry (Yarn 1 and Berry), | Workspaces, |
| The | Local and tarball dependencies |
| Every | The project itself, editable, path and URL sources |
Lock files include transitive dependencies, so they often list several hundred packages. Raise max_packages, and set a GitHub token.
Example response header:
Scanned 5 package(s). Grades: A=2, B=1, F=2. Needs attention: request (10), left-pad (10).followed by { scanned, total_dependencies, grades, packages: [...] }, with each package in a compact form (score, grade, confidence, risks, signals, repository).
compare_packages
Rank 2–5 alternatives from the same registry, or GitHub repositories.
Parameter | Type | Default | Description |
| string[] | — | 2 to 5 package names or |
|
|
| Where to look |
Healthiest: axios (92/100, A). Ranking: axios 92 > got 86 > request 10followed by { ranking: [...] } in the same compact form.
Using it with an AI agent
Once the server is connected, ask in plain language. Some prompts that work well:
"Before you add a date library, compare dayjs, date-fns and luxon with pkg-health."
"Scan this project's package.json and tell me which dependencies look abandoned."
"Is the
nosepackage still maintained? If not, what should I migrate to?""Is github.com/some-org/some-tool still alive? I want to vendor it."
"Scan package-lock.json, including transitive dependencies, and list everything graded F."
"Check every package in requirements.txt and make a checklist of the ones graded D or F."
To make it automatic, add a line to your project instructions (CLAUDE.md, .cursorrules, Copilot instructions…):
Before adding a new npm or PyPI dependency, call the pkg-health `check_package` tool.
Do not add packages graded D or F without asking me first, and mention any risks it reports.Command line
The same engine runs without an MCP client.
# Score one or more npm packages
npx -y pkg-health-mcp check express lodash
# PyPI packages
npx -y pkg-health-mcp check requests flask --pypi
# Any GitHub repository (owner/repo or URL)
npx -y pkg-health-mcp check expressjs/express https://github.com/pallets/flask
# Every dependency in a manifest, worst first
npx -y pkg-health-mcp scan ./package.json
npx -y pkg-health-mcp scan ./pyproject.toml --dev
# Transitive dependencies from a lock file
npx -y pkg-health-mcp scan ./package-lock.json
npx -y pkg-health-mcp scan ./uv.lock --max 300
# Fail (exit code 1) if anything scores below 50
npx -y pkg-health-mcp scan ./package.json --fail-under 50
# Machine-readable or Markdown output
npx -y pkg-health-mcp check express --json
npx -y pkg-health-mcp scan ./package.json --markdown >> "$GITHUB_STEP_SUMMARY"Command / flag | Description |
(no arguments) | Start the MCP server on stdio |
| Score packages (npm unless |
| Score every dependency in a manifest or lock file |
| Treat |
| Treat |
| Include dev and optional dependencies in |
| Score at most |
| Exit with code 1 if any package scores below |
| Print the full reports as JSON |
| Print a Markdown table, e.g. for |
| Ignore the on-disk cache for this run |
|
In the human-readable output, ! marks a risk and ~ a data warning. Exit codes: 0 success, 1 a package fell below --fail-under (or an error), 2 invalid arguments.
Cache
API responses are cached on disk for 12 hours in ~/.cache/pkg-health-mcp (or $XDG_CACHE_HOME/pkg-health-mcp), shared by the CLI and the MCP server. Only successful responses and 404s are cached.
Variable | Default | Description |
|
| Cache location. Set to |
|
| How long cached responses are reused |
GitHub Action
Add a dependency health report to every pull request, and optionally fail the job:
name: Dependency health
on: [pull_request]
jobs:
pkg-health:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: orcsnren/pkg-health-mcp@v0.2.0
with:
manifest: package-lock.json # or package.json, yarn.lock, pnpm-lock.yaml, requirements.txt, poetry.lock, uv.lock …
fail-under: 40 # leave out to report without failing
max-packages: 300Input | Default | Description |
|
| File to scan |
| (empty) | Fail if any dependency scores below this value |
|
| Also score dev dependencies |
| (empty) | Score at most this many packages |
|
| Token for GitHub API calls |
The table of results is written to the job summary. Without the Action, the CLI does the same in any CI system:
- name: Dependency health
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: npx -y pkg-health-mcp scan package.json --fail-under 40 --markdown >> "$GITHUB_STEP_SUMMARY"How the score works
Six signals are scored from 0 to 100 and combined with these weights:
Signal | Weight | What is measured |
Recent activity | 30% | Days since the latest release or commit, whichever is more recent |
Maintainer diversity | 20% | Unique human committers in the last 12 months (bus factor) |
Issue responsiveness | 15% | Median time to the first maintainer response (with a token), otherwise median time to close |
Download trend | 15% | Downloads in the last 90 days vs. the 90 days before |
OpenSSF Scorecard | 10% | Independent security-practice score |
License | 10% | Permissive, copyleft, proprietary or missing |
Signals without data are left out and the remaining weights are rescaled.
confidencereports how much of the weight was backed by data.Hard caps: deprecated packages score at most 10, archived repositories at most 15.
Grades: A ≥ 80, B ≥ 65, C ≥ 50, D ≥ 35, F below 35.
Every threshold, edge case and known blind spot is documented in docs/scoring.md.
Data sources
All public, no authentication required.
Data | Source | Notes |
npm metadata |
| Latest version, release date, deprecation, license, maintainers, repository |
npm downloads |
| Daily downloads, last 180 days used |
PyPI metadata |
| Version, upload time, license, classifiers, project URLs |
PyPI downloads |
| Daily downloads without mirrors (~180 days kept) |
Repository activity |
| Archived flag, license, latest release, commits of the last 12 months, recently closed issues |
First maintainer response |
| Comments on the 60 most recent issues; needs a token |
OpenSSF Scorecard |
| Overall Scorecard result for the repository |
Responses are cached in memory for one hour and on disk for 12 hours (see Cache), and at most four packages are analysed at a time.
Limitations
Maintenance, not security. This does not look for known vulnerabilities. Pair it with
npm audit,pip-auditor OSV."Done" is not "dead". A small, feature-complete utility can be safe with no commits for years. The score will flag it anyway; read the risks before acting.
Repository data comes from GitHub. Packages hosted on GitLab, Codeberg or self-hosted forges are scored from registry data, with lower confidence.
Monorepos share their activity with every package published from them.
Large lock files are slow on a cold cache. A lock file with 800 packages needs a few thousand API calls the first time. Use a token and
--max, or let the cache warm up.Maintainer responses are attributed by GitHub role. Only replies from owners, organization members and collaborators count. Projects triaged by community members can look less responsive than they are.
FAQ
Does it send my code or manifest anywhere? No. Only package names leave your machine, as part of the public API URLs listed above. See SECURITY.md.
Do I need the MCP server at all? No. The CLI and the GitHub Action use the same engine. The MCP server is what lets an AI agent check a package before it suggests one, which is where abandoned dependencies usually come from.
Why did a package I know is fine get a low score?
Look at risks and subscores; they say exactly which signal pulled it down. If the score is still wrong, please open a "wrong score" issue. Those reports are how the thresholds get tuned.
What does confidence mean?
The share of the scoring weight that was backed by real data. 1.0 means all six signals were available. Below 0.6 the summary says "low confidence".
How is this different from OpenSSF Scorecard, deps.dev or Socket?
Scorecard grades a repository's security practices; this tool uses it as one input. deps.dev and Socket are excellent websites and services. pkg-health-mcp focuses on one question, is this still maintained?, and makes the answer available inside AI agents as a tool call, with a single explainable score across ecosystems.
Can I use it commercially? Yes. It is licensed under Apache 2.0.
Development
Requires Node.js 22+ for the test runner.
git clone https://github.com/orcsnren/pkg-health-mcp
cd pkg-health-mcp
npm install # also builds dist/
npm test # offline unit tests
npm run typecheck
node dist/index.js check expressTry the tools interactively with the MCP Inspector:
npx @modelcontextprotocol/inspector node dist/index.jsProject layout:
src/
├── index.ts CLI entry point; starts the MCP server when run without arguments
├── server.ts MCP tool definitions
├── analyze.ts Gathers facts for a package from all sources
├── score.ts Pure scoring functions
├── manifest.ts Manifest and lock file parsing
├── http.ts fetch with timeout, memory + disk cache and concurrency limit
├── types.ts
└── sources/
├── npm.ts Registry metadata and download statistics
├── pypi.ts PyPI JSON API and pypistats
├── github.ts Repository, commits, issues, releases, first responses (GraphQL)
├── scorecard.ts OpenSSF Scorecard via deps.dev
└── repo-url.ts Normalizes the many shapes of repository URLs
docs/
├── scoring.md Full scoring methodology
└── architecture.md How the pieces fit together, and how to add an ecosystem
examples/ Client configurations and sample manifestsContributing
Bug reports, scoring feedback and pull requests are welcome. If a package you know well gets a grade that feels wrong, a wrong score report is the most useful thing you can send. New ecosystems (Maven Central, Go modules, crates.io, RubyGems) and repository hosts are good first contributions; docs/architecture.md lists the steps.
See CONTRIBUTING.md for the development setup and guidelines.
License
Available Tools
3 toolscheck_packageCheck package healthARead-onlyIdempotent
Score how well an npm or PyPI package, or any GitHub repository, is maintained (0-100, graded A-F). Looks at release and commit recency, number of active committers, time to first maintainer response, issue close time, download trend, OpenSSF Scorecard and license. Use before adding a new dependency, when asked whether a library or project is abandoned, or to vet a GitHub project that is not published to a registry.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name ('express', '@types/node', 'requests') or GitHub repository ('owner/repo' or a github.com URL) | |
| ecosystem | No | Where to look: 'npm' (JavaScript/TypeScript), 'pypi' (Python) or 'github' (any GitHub repository, name given as 'owner/repo'). A GitHub URL or 'owner/repo' is detected automatically. | npm |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is known. The description adds useful substance by enumerating the signals examined (release recency, committers, response time, downloads, OpenSSF Scorecard, license), but it says nothing about latency, rate limits, or what happens for an unknown package.
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?
Two sentences, front-loaded with the capability and output scale, followed by usage triggers. Nothing repeated and nothing wasted.
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?
With no output schema, the description helpfully states the return shape (a 0-100 score graded A-F) and the ecosystems covered. It omits failure behavior for a nonexistent or ambiguous package name, which is a minor but real gap for an openWorld lookup tool.
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?
Schema description coverage is 100%, so both parameters are documented in the schema. The description only reinforces that GitHub repos can be passed and that non-registry projects are supported; it adds no syntax or format detail beyond that, so baseline 3 applies.
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?
States a specific verb (score) and resource (package/repo maintenance) with a concrete output scale (0-100, A-F), and names the three ecosystems it covers. It does not explicitly contrast itself with scan_manifest or compare_packages, but the single-package scope is evident.
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?
Gives three concrete triggering situations: before adding a dependency, judging abandonment, and vetting an unpublished GitHub project. It names no alternatives or when-not conditions, so the sibling routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_packagesCompare alternative packagesARead-onlyIdempotent
Compare 2-5 alternative packages from the same registry (e.g. 'moment' vs 'dayjs' vs 'date-fns'), or GitHub repositories, and rank them by maintenance health. Use when choosing between libraries.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | Yes | Package names or GitHub repositories ('owner/repo') to compare | |
| ecosystem | No | Where to look: 'npm' (JavaScript/TypeScript), 'pypi' (Python) or 'github' (any GitHub repository, name given as 'owner/repo'). A GitHub URL or 'owner/repo' is detected automatically. | npm |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, and the description adds meaningful context: the result is a ranking by maintenance health and inputs must be 2-5 alternatives from one registry. It doesn't discuss caching, rate limits, or data freshness, so not 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the capability and its concrete example come first, the usage cue second. No filler.
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?
With no output schema, the description telling the agent that results are ranked by maintenance health covers the key expectation for a read-only comparison tool. Return shape and scoring method remain unspecified, but nothing needed to invoke it is missing.
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?
Schema coverage is 100%, so baseline is 3; the description earns extra by adding the constraint that packages must come from the same registry, a rule the schema does not encode. Example values (moment vs dayjs) also aid interpretation, though per-item format is left to the schema.
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?
Specific verb (compare) plus resource (2-5 alternative packages from a registry or GitHub repos) with concrete examples and the ranking criterion (maintenance health). Combined with the title, it's immediately distinguishable from check_package (single) and scan_manifest (manifest-wide).
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?
'Use when choosing between libraries' gives a clear triggering context, and 'from the same registry' sets a precondition. It stops short of naming when not to use it or pointing at check_package/scan_manifest as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_manifestScan dependency manifestARead-onlyIdempotent
Score every dependency in a manifest or lock file and list the riskiest first. Supports package.json, requirements.txt, pyproject.toml, and the lock files package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock and uv.lock (which include transitive dependencies). GitHub-hosted dependencies are scored as repositories. Prefer path for local files, especially large lock files; otherwise pass content. Use to audit a project's dependencies for abandoned or risky packages.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a local manifest or lock file, relative to the server's working directory. One of: package.json, requirements.txt, pyproject.toml, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, poetry.lock, uv.lock, requirements*.txt | |
| content | No | Full text of the manifest file, if not passing `path` | |
| filename | No | File name for `content`, used to detect the format (e.g. package.json, yarn.lock) | |
| include_dev | No | Also score devDependencies / optional dependencies | |
| max_packages | No | Upper limit on packages scored; lock files often list several hundred |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered; the description adds real context beyond that: lock files pull in transitive dependencies, GitHub dependencies are scored as repositories, and large lock files should be passed by path. It does not explain the scoring scale or what fields the ranked results contain, which keeps this from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler, with the core action and ordering behavior front-loaded, followed by the format list and the path-vs-content preference. Every sentence carries information an agent needs at call time.
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?
For a read-only five-parameter tool with annotations covering the safety profile and a fully documented schema, the description covers what it does, what inputs are accepted, how large inputs are best supplied, and the shape of the output ordering. Nothing needed to call it correctly is missing.
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?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine guidance beyond the schema by recommending `path` over `content` for large lock files and noting the inclusion of transitive dependencies, which contextualizes max_packages. It does not clarify `filename` detection or `include_dev` behavior.
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 gives a specific verb and resource: 'Score every dependency in a manifest or lock file and list the riskiest first.' Combined with 'GitHub-hosted dependencies are scored as repositories,' the agent knows this operates on whole manifests rather than single packages, which is enough to distinguish it from check_package and compare_packages without naming them.
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 states the use case ('Use to audit a project's dependencies for abandoned or risky packages') and gives explicit routing between parameters ('Prefer `path` for local files, especially large lock files; otherwise pass content'). It never names when not to use it or points at the sibling tools, so the alternative-routing is left implicit.
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.
3 tool updates
v0.2.0- First observed
check_package - First observed
compare_packages - First observed
scan_manifest
TDQS
Scored across 3 tools
Each tool operates at a clearly different granularity: check_package scores a single package/repo, scan_manifest scores an entire manifest or lock file, and compare_packages ranks 2-5 alternatives from the same registry. The descriptions make these boundaries explicit, so an agent can select correctly without guessing.
All three tools follow a strict verb_noun snake_case pattern (check_package, scan_manifest, compare_packages). The verbs are also semantically distinct, reinforcing the naming.
Three tools is well within the appropriate range and each maps to a distinct user intent: vet one dependency, audit a whole project, or choose between alternatives. No tool feels redundant or padding.
The surface covers the core lifecycle of package health assessment: single package scoring, bulk manifest auditing, and comparative evaluation. Minor gaps exist, such as retrieving a detailed score breakdown or history for already-scanned dependencies, but these are workarounds an agent can handle via check_package on individual names.
Maintenance
Related MCP Connectors
Scan packages and lockfiles (npm, PyPI, Go, Maven, Cargo, NuGet) for vulnerabilities and malware.
Supply chain risk scoring for npm, PyPI, Cargo, and Go. 9 tools. Behavioral signals.
Evaluates any GitHub repository for license risk, maintenance velocity, stars/forks, and supply-c.
Evaluates any GitHub repository for license risk, maintenance velocity, stars/forks, and security.
Related MCP Servers
- AlicenseAqualityCmaintenanceSupply chain risk scoring for npm, PyPI, and GitHub repos860 npm8MIT
- AlicenseAqualityAmaintenanceEnables AI coding agents and CI to vet npm dependencies before they reach the lockfile, flagging hallucinated, slopsquatted, or otherwise risky packages with evidence-backed verdicts.323 npm4MIT
- AlicenseNot gradedqualityBmaintenanceEnables safety-ranked discovery of open-source components across npm, PyPI, crates.io, RubyGems, GitHub, and Hugging Face, with license, security, and health checks.1,348 npmMIT
- AlicenseNot gradedqualityAmaintenanceRead-only npm dependency diagnostics: inventory, audit and health checks from package-lock.json, no account needed.27 npmMIT