Skip to main content
Glama
lazaretto-mcp

lazaretto-mcp

Find an existing signed verdict before you install or pay to scan (free, no API key)

find_attestation

Check whether an artifact (npm package, MCP server URL, or sha256 hash) already has a signed attestation before installing or scanning it. Returns the verdict, freshness, and contradictions.

Instructions

Asks whether anyone has already attested an artifact, BEFORE you install it or pay to scan it. Give a package identity like "chalk@5.6.1", an MCP server endpoint URL, or a sha256 content hash. Returns the signed verdict if one exists, plus freshness: whether the known-bad corpus has since contradicted it and whether it was attested under an older rules version.

WHEN TO USE: as the first question about one specific artifact, since it is free and instant. Use verify_attestation instead when someone already handed you an attestation token. Use scan_artifact (or scan_lockfile_deep for a whole tree) when nothing has been attested yet, or when the verdict found here is stale.

COST AND EFFECTS: free, no API key, no payment. Read-only, a single HTTPS lookup.

LIMITS: a miss means no attestation is on record for this subject; it is not a verdict either way. An attestation carries the verdict, never the evidence, and it describes the artifact at the time it was made. An MCP server can change what it advertises with no new version, so for a server the result says how to confirm the verdict still applies.

WHEN NOBODY HAS ATTESTED IT: if the subject is an npm package identity, the answer falls back to a free identity check against published advisories, returned as answer: "identity_check" with an identity_check object. found stays false, because an identity check is NOT an attestation: it is unsigned, it looks at the package identity rather than its code, and absence from the advisory corpus is not a verdict on the artifact.

READING THE RESULT: check contradicted first: non-null means the subject is NOW a known-bad match, so a stored clear must not be trusted (this result is then marked as an error). identity_check.listed_as_malware: true means this exact version is published as malware, and that result is marked as an error too, so it cannot be summarised as "no attestation found". identity_check.listed_as_malware: null means the corpus could not be consulted: unchecked, never clear. found: false is not a clean verdict. stale_rules: true means it was attested under an older rules version, so re-scan for a current verdict. attestation is a compact JWS you can verify with verify_attestation or offline against https://lazaretto.dev/.well-known/jwks.json.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "subject": "<subject>"
    },
    "name": "find_attestation"
  }
}

Input Schema

NameRequiredDescriptionDefault
subjectYesWhat to look up: a package identity such as "chalk@5.6.1" (pin an exact version), an MCP server endpoint URL such as "https://example.com/mcp", or a sha256 content hash as 64 hex characters, with or without a leading "sha256:" prefix.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden and does: free, no API key, no payment, read-only, a single HTTPS lookup. It also discloses the semantics of a miss (no record, not a verdict either way), that attestations carry verdicts but not evidence, that MCP servers can change without a version bump, and that contradicted or malware-listed results are marked as errors rather than clean outcomes.

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?

Purpose and the WHEN TO USE routing are front-loaded, and the all-caps section headers make the long body scannable. It is on the verbose side, with the LIMITS and READING THE RESULT blocks partly overlapping, but nearly every sentence carries operational meaning rather than 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?

With no annotations and no output schema, this description takes on the whole disclosure burden and does so: result-field semantics (contradicted, found, stale_rules, attestation, identity_check.listed_as_malware including the null-means-unchecked case) are all explained. An agent can call it correctly and interpret every branch without further documentation.

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 the single subject parameter is already fully documented in the schema, including its three accepted forms. The description adds only marginal nuance ('pin an exact version' and the server-specific confirmation caveat), which justifies the baseline 3 rather than anything higher.

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 opening states a specific verb and resource: asks whether an artifact has already been attested, accepting a package identity, an MCP server URL, or a sha256 hash. It explicitly distinguishes itself from verify_attestation and the scan_* siblings, so an agent can pick it apart from them without opening any 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?

There is a dedicated WHEN TO USE block that names the exact condition (first question about one specific artifact, free and instant) and routes to alternatives: verify_attestation when a token was handed over, scan_artifact or scan_lockfile_deep when nothing is attested or the verdict is stale. Both inclusion and exclusion conditions are spelled out.

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