lazaretto

find_attestation

Read-onlyIdempotent

Ask whether anyone has already attested an artifact, BEFORE you install it or pay to scan it. Free and anonymous. 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, which you can verify offline against https://lazaretto.dev/.well-known/jwks.json, plus freshness: whether the corpus has since contradicted it and whether it was attested under an older rules version. A miss is not a verdict, it only means nobody has scanned this yet. When nobody has attested an npm package identity, the answer falls back to a free identity check against published advisories: answer: "identity_check" with an identity_check object, and found still false, because an identity check is unsigned, looks at the identity rather than the code, and absence from the corpus is not a verdict. identity_check.listed_as_malware: true comes back as an error result, so a published malware version cannot be read as "nothing found"; null there means the corpus could not be consulted, which is unchecked and never clear.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`subject`	Yes	A package identity ("chalk@5.6.1"), an MCP server endpoint URL, or a sha256 content hash, optionally sha256: prefixed.

Output Schema

TableJSON Schema

Name	Required	Description
`risk`	No
`found`	Yes	False means nobody has attested it, which is not a clean verdict.
`answer`	No	"identity_check" when nobody has attested the subject and a free advisory lookup answered instead.
`verdict`	No
`age_days`	No
`attestation`	No	Compact JWS you can verify offline; it carries the verdict, never the evidence.
`attested_at`	No
`stale_rules`	No	True when attested under an older rules version.
`contradicted`	No	Non-null when this subject is NOW a known-bad match.
`identity_check`	No	The fallback answer, never an attestation. `listed_as_malware` is true (published as malware, returned as an error), false (not in the corpus, which is not a verdict on the code), or null (the corpus could not be consulted: unchecked, never clear).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 22, 2026

addedOutput schema / properties / answer

Added value: +{
+  "description": "\"identity_check\" when nobody has attested the subject and a free advisory lookup answered instead.",
+  "type": "string"
+}

addedOutput schema / properties / identity_check

Added value: +{
+  "description": "The fallback answer, never an attestation. `listed_as_malware` is true (published as malware, returned as an error), false (not in the corpus, which is not a verdict on the code), or null (the corpus could not be consulted: unchecked, never clear).",
+  "type": "object"
+}

Changed1 schema field changedAug 31, 2026

changedInput schema / properties / subject / description

Previous value: -"A package identity (\"chalk@5.6.1\") or a sha256 content hash, optionally sha256: prefixed."New value: +"A package identity (\"chalk@5.6.1\"), an MCP server endpoint URL, or a sha256 content hash, optionally sha256: prefixed."

AddedAug 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses key behavior: anonymity, offline verifiability, freshness semantics, fallback to unsigned identity checks, and how malware hits and unconsulted corpus states are encoded. This aligns with the openWorldHint and adds substantial context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the critical 'before install or paid scan' guidance, and most sentences carry important nuance. However, it is verbose and repeats the 'miss is not a verdict / absence is not a verdict' idea multiple times. A tighter structure with bullets would make the dense fallback and error semantics easier to parse.

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?

All important operational states are covered: signed verdicts, freshness, misses, fallback identity checks, malware hits as errors, and null as 'unchecked.' Since an output schema exists, the description does not need to document return shapes, but the behavioral nuances are fully explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes `subject`, but the description adds real meaning by enumerating the accepted forms: package identity, MCP server endpoint URL, and sha256 content hash with an optional `sha256:` prefix. It also explains how subject type affects fallback behavior, which the schema alone does not convey.

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 opens with a precise action—'Ask whether anyone has already attested an artifact'—and clearly identifies the resource. It also distinguishes itself from scan/verify siblings by telling the agent to call it 'BEFORE you install it or pay to scan it' and by noting the returned verdict can be verified offline.

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?

It gives clear when-to-use context: before installing, before paying for a scan, and for a free/anonymous check. It also warns that 'a miss is not a verdict,' which prevents misuse as a clearance check, but it does not explicitly name the scan alternatives or state when not to use this tool.

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.