Package Health Check

Check package.json for vulnerabilities

check_package_json

Read-onlyIdempotent

Use this when the user asks to check their package.json, or the dependencies of a project, for known vulnerabilities: "check my package.json for known vulnerabilities". Pass the text of the package.json; only the names and versions in dependencies, devDependencies and optionalDependencies are read, nothing else in the file is used or kept, and nothing is stored. Do not ask for source code or tokens. Checks up to 150 npm dependencies at the version each names (ranges at their lowest version) and returns the vulnerable ones, most severe first, with the fixed version. Dependencies without an exact version (tags, urls, workspaces) are listed as skipped.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "packageJson": "{\"name\":\"demo\",\"dependencies\":{\"lodash\":\"4.17.15\",\"left-pad\":\"^1.3.0\"},\"devDependencies\":{\"typescript\":\"~5.4.0\"}}"
    },
    "name": "check_package_json"
  }
}

Input Schema

Name	Required	Description	Default
`packageJson`	Yes	The text of the user's package.json. Only its dependency names and versions are read.

Output Schema

Name	Required	Description
`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.
`source`	Yes	Who the data comes from, to cite and to check it against.
`status`	Yes
`checked`	Yes	Dependencies looked up
`message`	No
`skipped`	Yes	Dependencies without an exact version, not looked up
`truncated`	Yes
`cleanCount`	Yes	Looked up with no known vulnerability
`skippedCount`	Yes
`vulnerablePackages`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 23, 2026

addedInput schema / examples

Added value: +[
+  {
+    "packageJson": "{\"name\":\"demo\",\"dependencies\":{\"lodash\":\"4.17.15\",\"left-pad\":\"^1.3.0\"},\"devDependencies\":{\"typescript\":\"~5.4.0\"}}"
+  }
+]

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

Added value: +{
+  "description": "Who the data comes from, to cite and to check it against.",
+  "properties": {
+    "name": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "url"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "status",
-  "checked",
-  "cleanCount",
-  "vulnerablePackages",
-  "skipped",
-  "skippedCount",
-  "truncated"
-]New value: +[
+  "status",
+  "checked",
+  "cleanCount",
+  "vulnerablePackages",
+  "skipped",
+  "skippedCount",
+  "truncated",
+  "as_of",
+  "source"
+]

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnly/idempotent/non-destructive), the description discloses substantive behavior: only dependency names and versions are read, nothing else is used or kept, nothing is stored, and there is a 150-dependency cap. It also explains edge-case handling — ranges resolved at their lowest version, tags/urls/workspaces listed as skipped — which the annotations cannot convey.

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?

The trigger and input instruction are front-loaded in the first two sentences, with limits and edge-case behavior following in descending order of importance. No sentence is filler; the privacy note is slightly redundant with the schema but is a meaningful reassurance rather than padding.

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?

An output schema exists, yet the description still frames the return shape usefully (vulnerable dependencies, most severe first, with fixed version, plus a skipped list). Combined with the dependency cap and skip rules, an agent has everything needed to call this correctly and set user expectations.

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% and the parameter already documents that only dependency names and versions are read, so the baseline would be 3. The description reinforces the scope constraint (nothing else in the file is retained), adding confidence about what the input string is used for, though it adds no format or syntax detail beyond the schema example.

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+resource pair — check package.json dependencies for known vulnerabilities — and anchors it with an example user utterance. It is fully unambiguous on its own, though it never mentions the sibling `check_package`, so an agent comparing the two must infer the difference from the names alone.

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 states explicitly when to invoke it (user asks to check their package.json or project dependencies, with a quoted example), what input to supply, and what not to do ("Do not ask for source code or tokens"). That is an explicit usage rule plus an exclusion, which is the top of the scale.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.