lazaretto

check_lockfile

Read-onlyIdempotent

Check EXACTLY-PINNED npm dependencies against published malicious-package advisories (OSV/OpenSSF). Free, anonymous, one call for the whole set. Give EITHER lockfile, the full text of a package-lock.json, yarn.lock or pnpm-lock.yaml, OR packages, a list of "name@version" strings, which is the one to reach for when you only care about a few dependencies or when an 800-package tree would not fit in your context. Give one or the other, never both. Only exact versions can be answered: a range like ^5.0.0 has no definitive answer because a compromised release usually sits between clean ones. Fail-closed: anything that could not be checked is returned in unverified, so an empty malicious list is an all-clear only when unverified is empty too AND truncated is false. truncated: true means the lockfile ran past the per-request package limit and the packages past it went into NEITHER list: they were never looked at, checked counts only the ones that were, and the rest are unchecked rather than clean. When that happens, send the remainder as packages (name@version strings) in a second call, or split the lockfile by workspace, before telling anyone the tree is clean.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lockfile`	No	The full text contents of a package-lock.json, yarn.lock, or pnpm-lock.yaml.
`packages`	No	Exactly pinned packages, as "name@version" strings (for example ["chalk@5.6.1","debug@4.4.2"]). Use instead of `lockfile` when you know which dependencies you care about, so a whole tree need not pass through your context. Mutually exclusive with `lockfile`.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No
`format`	No	Lockfile format detected.
`checked`	Yes	How many exactly pinned versions were actually checked.
`skipped`	No	Entries with no registry identity (file:, link:, workspace:, git:).
`malicious`	Yes	Pinned versions listed as malware in the advisory corpus. Act on these.
`truncated`	No	True when the lockfile ran past the per-request package limit. The packages past it are in neither `malicious` nor `unverified`: they were never checked. Send them as `packages` in another call.
`disclaimer`	No
`unverified`	Yes	Could NOT be decided. Never treat these as clean.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 22, 2026

addedInput schema / properties / packages

Added value: +{
+  "description": "Exactly pinned packages, as \"name@version\" strings (for example [\"chalk@5.6.1\",\"debug@4.4.2\"]). Use instead of `lockfile` when you know which dependencies you care about, so a whole tree need not pass through your context. Mutually exclusive with `lockfile`.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "lockfile"
-]
```

changedOutput schema / description

Previous value: -"Fail closed: an empty `malicious` list is an all-clear ONLY when `unverified` is also empty."New value: +"Fail closed: an empty `malicious` list is an all-clear ONLY when `unverified` is also empty AND `truncated` is false. Packages past the per-request limit appear in no list at all."

addedOutput schema / properties / truncated / description

Added value: +"True when the lockfile ran past the per-request package limit. The packages past it are in neither `malicious` nor `unverified`: they were never checked. Send them as `packages` in another call."

Changed1 schema field changedAug 30, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Fail closed: an empty `malicious` list is an all-clear ONLY when `unverified` is also empty.",
+  "properties": {
+    "checked": {
+      "description": "How many exactly pinned versions were actually checked.",
+      "type": "integer"
+    },
+    "disclaimer": {
+      "type": "string"
+    },
+    "format": {
+      "description": "Lockfile format detected.",
+      "type": "string"
+    },
+    "malicious": {
+      "description": "Pinned versions listed as malware in the advisory corpus. Act on these.",
+      "items": {
+        "properties": {
+          "ids": {
+            "description": "Advisory ids, for example MAL-2025-46969.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "name": {
+            "type": "string"
+          },
+          "version": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "version"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "type": "string"
+    },
+    "skipped": {
+      "description": "Entries with no registry identity (file:, link:, workspace:, git:).",
+      "type": "integer"
+    },
+    "truncated": {
+      "type": "boolean"
+    },
+    "unverified": {
+      "description": "Could NOT be decided. Never treat these as clean.",
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "reason": {
+            "type": "string"
+          },
+          "version": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "version"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "checked",
+    "malicious",
+    "unverified"
+  ],
+  "type": "object"
+}

AddedJul 21, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes far beyond the readOnly/idempotent hints: explains the service is free and anonymous, requires exact versions, and is fail-closed with an `unverified` bucket for anything not checked. It also spells out that `truncated: true` means omitted packages were never examined, and clarifies that `checked` counts only examined packages. No contradiction with annotations.

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?

Long but every sentence earns its place: purpose, input selection, exact-version constraint, fail-closed interpretation, and truncation handling are all material to using the tool correctly. Information is front-loaded and ordered logically. No filler or redundancy.

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?

Combined with the rich output schema and annotations, this is complete: it defines all-clear conditions, explains truncation consequences, and tells the agent exactly how to recover with a follow-up call. Nothing necessary for safe, correct invocation 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?

The schema already documents both parameters fully, so the baseline is 3. The description adds real usage nuance: `lockfile` means full text of supported lockfiles, `packages` means name@version strings and is preferred when only a few deps matter or the tree won't fit in context; it also reinforces mutual exclusivity with 'never both'. This is moderately additive but partly repeats schema language.

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 an explicit verb and resource: check exactly-pinned npm dependencies against OSV/OpenSSF malicious-package advisories. The 'one call for the whole set' and exact-pinning scope signal a distinct batch security-check tool, though it does not explicitly name `scan_lockfile_deep` or describe how it differs from that sibling. Therefore very clear but not perfectly differentiated.

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?

Provides concrete selection guidance: pass `lockfile` for the whole tree or `packages` when only a few dependencies matter or the tree would not fit in context, and explicitly says never both. It also gives exclusion criteria (ranges cannot be answered) and a follow-up strategy for `truncated: true`. It doesn't name sibling tools as alternatives, so it falls just short of full cross-tool routing.

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

All lazaretto tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.