ProofSnap

Check whether ProofSnap issued a manifest

lookup_manifest

Read-onlyIdempotent

Looks up the SHA-256 of an evidence package's manifest.json in ProofSnap's public ledger: whether ProofSnap issued exactly this manifest, and when. It covers packages issued by the ProofSnap API and dashboard; packages made with the browser extension are not in this ledger. Returns issued (true or false) and, when issued, issued_at, the package type and eidas (whether the package carries an eIDAS qualified timestamp). Reads public ledger data only; no account is needed.

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": {
      "hash": "<hash>"
    },
    "name": "lookup_manifest"
  }
}

Input Schema

Name	Required	Description	Default
`hash`	Yes	SHA-256 of the package's manifest.json as 64 hexadecimal characters (a sha256: prefix is accepted), for example the manifest_hash of a capture

Output Schema

Name	Required	Description	Default
`type`	No
`eidas`	No
`issued`	No
`issued_at`	No
`manifest_sha256`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, and the description adds genuinely new behavioral context: it reads public ledger data only, requires no account, and enumerates the returned fields (issued, issued_at, package type, eidas). The coverage caveat about the browser extension is a behavioral limitation an agent could not infer from annotations or schema.

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?

Three sentences, each carrying distinct information: what is looked up, what is out of scope, and what comes back. The core purpose is front-loaded in the first clause with no 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?

For a single-parameter read tool with full schema coverage, an output schema, and rich annotations, the description covers purpose, scope limits, auth requirements, and return shape. Nothing an agent needs to call it correctly or interpret a false result 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 coverage is 100% with a single well-documented parameter including a regex pattern, prefix tolerance, and an example source (manifest_hash of a capture). The description restates the parameter's meaning in prose but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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: looks up the SHA-256 of a package's manifest.json in ProofSnap's public ledger, and names the exact question answered (whether ProofSnap issued this manifest, and when). It also scopes which packages are covered, so an agent knows precisely what the tool can and cannot confirm.

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?

Gives the positive use case (verify issuance and timing for a manifest hash) and an explicit when-not: packages made with the browser extension are not in this ledger, so a false result there is not proof of non-issuance. It also states no account is needed, removing an auth prerequisite question. No siblings exist, so no alternative routing is required.

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

All ProofSnap 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.