Skip to main content
Glama

lazaretto

by io.github.jamesdfinance-dev

scan_lockfile_deep

Behaviorally scan EVERY exactly-pinned dependency in a lockfile, not just their identities: reads the code of each package and reports credential theft, exfiltration, obfuscation, prompt injection and install-time droppers with file-and-line evidence. This is the paid counterpart to check_lockfile, which only matches names and versions against advisories. Metered: one credit per package that returns a verdict, nothing for one that errors. Capped at 25 packages per call. Use it before installing a tree you have not vetted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lockfileYesThe full text contents of a package-lock.json, yarn.lock, or pnpm-lock.yaml.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
erroredNo
resultsYes
scannedYes
not_scannedNoWhat was left out and why.
worst_verdictNo
billed_creditsYes
refunded_creditsNoCredits reserved for packages that errored and were given back.
complete_coverageYes
remaining_creditsNo

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, the description discloses concrete behavioral details: it reads package code, reports specific threat categories with evidence, charges one credit per verdict, charges nothing for errors, and caps at 25 packages. This goes well beyond what readOnlyHint, openWorldHint, idempotentHint, and destructiveHint communicate.

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 description is front-loaded with a precise, high-signal first sentence, followed by metering details and a practical usage directive. Every sentence contributes new information, with no redundancy or filler despite the richness of content.

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?

Given the output schema exists, the description covers everything an agent needs: what the tool does, what the input is, cost model, error charging behavior, limit, how it differs from the primary sibling, and when to invoke it. No critical operational context is missing.

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%, and the lockfile parameter is already described as the full text contents of supported lockfile formats. The tool description does not add new parameter-level semantics, so the baseline of 3 is appropriate.

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 uses a specific verb and resource: "Behaviorally scan EVERY exactly-pinned dependency in a lockfile." It clearly distinguishes this tool from check_lockfile by explaining it reads package code and reports specific threat categories with file-and-line evidence, rather than just matching names and versions.

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?

The description explicitly names check_lockfile as the cheaper advisory-only alternative, characterizes this tool as its paid counterpart, and gives a direct use case: "Use it before installing a tree you have not vetted." It also states metering and package caps, which are practical when/when-not signals.

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

All lazaretto toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Each tool has a distinct target and action: lockfile advisory checks, deep behavioral scans, MCP server scans, local tool-definition checks, hash lookups, and attestation operations. The closest overlap is check_lockfile vs scan_lockfile_deep and check_mcp_tools vs scan_mcp_server, but the descriptions clearly separate free vs paid and local vs remote workflows.

Naming Consistency4/5

Most tools follow a clear verb_noun snake_case pattern: check_lockfile, scan_artifact, scan_mcp_server, find_attestation, verify_attestation. known_bad_lookup is the one outlier, using an object-first pattern instead of a verb-first one, but it is still readable and does not create real confusion.

Tool Count5/5

Eight tools is well-scoped for a security-scanning service covering lockfiles, artifacts, MCP servers, hash lookups, and attestations. Each tool addresses a distinct use case, and the count is neither bloated nor thin for the server's purpose.

Completeness4/5

The surface covers the main security workflows: advisory lockfile checks, deep behavioral scanning, MCP server vetting, local tool-definition analysis, known-bad hash lookups, and attestation discovery/verification. Minor gaps exist around explicitly creating or managing attestations, but scans likely generate them implicitly and the core lifecycle is coherent.

Resources