Skip to main content
Glama

Package risk check: npm, PyPI, Cargo, Go, Maven or NuGet metadata and dependency-risk signals, latest or pinned version

package
Read-only

Reports package existence, latest version and release, age, version count, npm weekly downloads, licenses, deprecation and known advisory severity. ok means no listed flags, not a safety guarantee. Supports npm, PyPI, Cargo, Go, Maven and NuGet. Optional exact version adds pinned-version metadata and uses deps.dev advisories; use /package-audit for OSV affected ranges and dated FIRST EPSS CVE estimates. Use before adding a dependency. Example: ecosystem=npm, name=lodash. Price $0.002/call via x402 USDC or a card key (/credits), first 25 free; failed calls free. Reads or computes only and changes nothing; each call is charged, so repeats are not free.

Input Schema

NameRequiredDescriptionDefault
nameYesExact package name, e.g. lodash or @scope/name
versionNoOptional exact version to inspect; ranges and tags are not accepted
ecosystemYesOne of npm, pypi, cargo, go, maven, nuget

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / version
      Added value: +{
      +  "description": "Optional exact version to inspect; ranges and tags are not accepted",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • removedInput schema / properties / version
      Removed value: -{
      -  "description": "Optional exact version to inspect; ranges and tags are not accepted",
      -  "type": "string"
      -}
  3. Changed1 schema field changed
    • addedInput schema / properties / version
      Added value: +{
      +  "description": "Optional exact version to inspect; ranges and tags are not accepted",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • removedInput schema / properties / version
      Removed value: -{
      -  "description": "Optional exact version to inspect; ranges and tags are not accepted",
      -  "type": "string"
      -}
  5. Changed1 schema field changed
    • addedInput schema / properties / version
      Added value: +{
      +  "description": "Optional exact version to inspect; ranges and tags are not accepted",
      +  "type": "string"
      +}
  6. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, it discloses pricing ($0.002/call, first 25 free, failed calls free), the fact that repeats are charged (explaining the non-idempotent hint), and a key semantic caveat: 'ok means no listed flags, not a safety guarantee.' It also states which advisory source is used per mode, which is material behavioral context an agent cannot get from annotations.

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 return fields are front-loaded and the sibling routing and caveats follow logically, with every clause carrying information. It is dense and slightly overloaded by the pricing/billing sentence, but nothing is redundant filler.

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?

There is no output schema, and the description compensates by enumerating the returned signals and the meaning of the 'ok' status. Coverage of ecosystems, version modes, cost, and safety caveats is sufficient for an agent to call this correctly on the first attempt.

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 meaning the schema does not: supplying an exact version switches to pinned-version metadata and deps.dev advisories, whereas the default covers latest-version signals. That consequence-level detail is genuinely useful, though the version-format constraint is already in 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?

The description names a specific resource and enumerates exactly what is returned: existence, latest version, release date, age, version count, npm weekly downloads, licenses, deprecation, and advisory severity. It also scopes the supported ecosystems and explicitly distinguishes itself from the sibling package_audit, so an agent can route between them without opening a schema.

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 gives a direct usage rule ('Use before adding a dependency') and names the alternative with the condition that selects it ('use /package-audit for OSV affected ranges and dated FIRST EPSS CVE estimates'). It also supplies a concrete call example (ecosystem=npm, name=lodash), leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.