Skip to main content
Glama

pkg-health-mcp

Is this dependency still maintained? Find out before you install it.

CI npm License: Apache 2.0 MCP Node

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/repo or 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), plus package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock and uv.lock for 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 confidence value instead of the score.

  • No account or API key needed. An optional GITHUB_TOKEN raises 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-mcp

Leave 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.json

  • Windows: %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-mcp

GitHub 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

name

string

—

Package name (express, @types/node, requests) or GitHub repository (owner/repo or a github.com URL)

ecosystem

"npm" | "pypi" | "github"

"npm"

Where to look. owner/repo and GitHub URLs are detected automatically

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

path

string

—

Path to a local manifest or lock file. Only the file names listed below are accepted

content

string

—

Full text of the file, if not passing path

filename

string

—

Optional, with content; used to detect the format. Content sniffing is used otherwise

include_dev

boolean

false

Also score devDependencies / optional dependencies

max_packages

integer

50

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.json

dependencies, peerDependencies, optionalDependencies, devDependencies (with include_dev), npm: aliases, GitHub specs (owner/repo, github:)

file:, link:, workspace:, non-GitHub git and URL specs

requirements*.txt, requirements*.in

Package names with extras, version specifiers and environment markers; git+https://github.com/… URLs

-r, --index-url and other options, other URLs, local paths

pyproject.toml

PEP 621 [project] dependencies and optional-dependencies; Poetry [tool.poetry.dependencies] and dev groups

python itself

package-lock.json, npm-shrinkwrap.json

Every installed package (lockfile v1, v2, v3), with dev flags

Linked workspaces, bundled packages

yarn.lock

Every entry (Yarn 1 and Berry), npm: aliases, patches

Workspaces, file:, link:, portal:. Yarn does not record dev-only packages

pnpm-lock.yaml

The packages: section (lockfile v5, v6, v9), with dev flags where recorded

Local and tarball dependencies

poetry.lock, uv.lock

Every [[package]], Poetry's category = "dev"

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

packages

string[]

—

2 to 5 package names or owner/repo repositories

ecosystem

"npm" | "pypi" | "github"

"npm"

Where to look

Healthiest: axios (92/100, A). Ranking: axios 92 > got 86 > request 10

followed 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 nose package 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

check <name...>

Score packages (npm unless --pypi) or GitHub repositories (owner/repo, URLs)

scan <file>

Score every dependency in a manifest or lock file

--pypi

Treat check arguments as PyPI packages

--github

Treat check arguments as GitHub repositories (only needed for unusual inputs)

--dev

Include dev and optional dependencies in scan

--max <n>

Score at most n packages in scan

--fail-under <n>

Exit with code 1 if any package scores below n. Packages that could not be scored do not fail the run, but are counted in the message

--json

Print the full reports as JSON

--markdown

Print a Markdown table, e.g. for $GITHUB_STEP_SUMMARY

--no-cache

Ignore the on-disk cache for this run

--help, --version

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

PKG_HEALTH_CACHE_DIR

~/.cache/pkg-health-mcp

Cache location. Set to off to disable the disk cache

PKG_HEALTH_CACHE_TTL_HOURS

12

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: 300

Input

Default

Description

manifest

package.json

File to scan

fail-under

(empty)

Fail if any dependency scores below this value

include-dev

false

Also score dev dependencies

max-packages

(empty)

Score at most this many packages

github-token

${{ github.token }}

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. confidence reports 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

registry.npmjs.org

Latest version, release date, deprecation, license, maintainers, repository

npm downloads

api.npmjs.org/downloads/range/last-year

Daily downloads, last 180 days used

PyPI metadata

pypi.org/pypi/<name>/json

Version, upload time, license, classifiers, project URLs

PyPI downloads

pypistats.org

Daily downloads without mirrors (~180 days kept)

Repository activity

api.github.com (REST)

Archived flag, license, latest release, commits of the last 12 months, recently closed issues

First maintainer response

api.github.com/graphql

Comments on the 60 most recent issues; needs a token

OpenSSF Scorecard

api.deps.dev

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-audit or 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 express

Try the tools interactively with the MCP Inspector:

npx @modelcontextprotocol/inspector node dist/index.js

Project 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 manifests

Contributing

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

Apache License 2.0

Available Tools

3 tools
check_packageCheck package healthA
Read-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.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesPackage name ('express', '@types/node', 'requests') or GitHub repository ('owner/repo' or a github.com URL)
ecosystemNoWhere 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

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 packagesA
Read-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.

ParametersJSON Schema
NameRequiredDescriptionDefault
packagesYesPackage names or GitHub repositories ('owner/repo') to compare
ecosystemNoWhere 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

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 manifestA
Read-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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoPath 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
contentNoFull text of the manifest file, if not passing `path`
filenameNoFile name for `content`, used to detect the format (e.g. package.json, yarn.lock)
include_devNoAlso score devDependencies / optional dependencies
max_packagesNoUpper limit on packages scored; lock files often list several hundred

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

  1. 3 tool updatesv0.2.0
    • First observedcheck_package
    • First observedcompare_packages
    • First observedscan_manifest

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers