Skip to main content
Glama
Sign In
lazaretto-mcp

lazaretto-mcp

by jamesdfinance-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Verify a signed scan attestation another agent shared with you (free, no API key)

verify_attestation

Confirm a Lazaretto attestation's signature and return its attested claims so you can trust an out-of-band scan verdict without re-scanning the artifact.

Instructions

Verifies a Lazaretto attestation: the compact-JWS token that a scan verdict ships with. It confirms the signature is genuinely Lazaretto's and returns the attested claims, so a verdict another agent (or a README, or a lockfile) handed you can be trusted WITHOUT re-scanning the artifact yourself.

WHEN TO USE: when you receive a verdict out of band and want to rely on it. Prefer this over re-running scan_artifact when someone already scanned the exact artifact and gave you the token, since verification is free and instant. Use scan_artifact instead when no attestation exists yet.

COST AND EFFECTS: free, no API key, no payment. Read-only, a single HTTPS call. Ships no crypto of its own; the service checks the signature against its published keys.

LIMITS: a valid signature proves the verdict is authentic and unaltered, NOT that it is still current. There is no expiry: a token says "clear at scan time under rules vX", not "clear forever". Verification alone says nothing about the artifact in front of you: you MUST compare what you are about to run against claims.sub (its sha256, or its package identity) yourself.

READING THE RESULT: valid: true with claims means the signature is Lazaretto's and the claims are untampered. valid: false means the token is forged, altered, or not ours, so ignore it. A contradicted field means the signature is valid but the subject is now a known-bad match (a stale verdict): treat that as a failure, not a pass.

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": {
      "attestation": "<attestation>"
    },
    "name": "verify_attestation"
  }
}

Input Schema

NameRequiredDescriptionDefault
attestationYesThe compact-JWS attestation string from a scan report (the `attestation` field of a scan verdict): three base64url segments separated by dots.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does so well: it discloses cost (free, no API key, no payment), effect (read-only, a single HTTPS call), trust model (no shipped crypto, service checks against published keys), and key limits (no expiry, signature authenticity does not imply currency). The only shortfall is that the practical consequence of the `valid: false` path is stated but not whether the call can itself fail/error or what rate limits apply.

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?

Labeled sections (WHEN TO USE, COST AND EFFECTS, LIMITS, READING THE RESULT) front-load the decision-relevant material and each block adds distinct information. Minor redundancy: "free, no API key" appears in the title and is repeated verbatim in COST AND EFFECTS.

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?

There is no output schema, so the description compensates by decoding the result shape itself — `valid: true` with `claims`, `valid: false`, and the tricky `contradicted` case with explicit "treat that as a failure, not a pass" guidance. It also flags the caller's obligation to compare against `claims.sub`, which is the main way this tool gets misused.

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 schema already explains the three-segment base64url compact-JWS format, so the baseline is 3. The description adds provenance meaning beyond the schema — that the token is what a scan verdict ships with and can arrive via another agent, a README, or a lockfile — which helps the agent locate the right value.

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?

States a specific verb and resource ("Verifies a Lazaretto attestation: the compact-JWS token that a scan verdict ships with") and immediately contrasts it with the sibling scan_artifact, so an agent can distinguish the two without opening either 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?

The WHEN TO USE block gives an explicit trigger (a verdict received out of band), an explicit preference over re-running scan_artifact with the reason (free and instant), and the inverse condition ("Use scan_artifact instead when no attestation exists yet").

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

Deploy Server

Other Tools