@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

list_revoked_proofs

Read-only

Fetches a signed list of revoked proof IDs for offline proof validation; reuse it for 5 minutes, then refresh to see new revocations.

Instructions

Get the revocation list for offline proof validation. Returns a signed list of all revoked proof IDs. Reuse a fetched list for up to 5 minutes (its cache lifetime), then fetch it again to see new revocations; if you cannot, its signature stays verifiable offline for 1 hour.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`kid`	Yes	Key id of the signing key, for JWKS lookup
`count`	Yes	Number of entries in `revoked`
`revoked`	Yes
`has_more`	Yes	True when a source hit its cap and the list may be incomplete — re-baseline and prefer the Token Status List, which never truncates
`issued_at`	Yes	When this list was generated
`signature`	Yes	Signature over the payload for offline verification, in the algorithm of the key `kid` names (null when unsigned)
`status_list_uri`	Yes	The Token Status List endpoint — the scalable status channel that also covers SUSPENDED and can retract entries (an unsuspended bit flips back; a CRL entry cached by a `?since` poller cannot be unpublished)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.7.2Nov 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "Signed list of revoked proofs",
+  "properties": {
+    "count": {
+      "description": "Number of entries in `revoked`",
+      "type": "number"
+    },
+    "has_more": {
+      "description": "True when a source hit its cap and the list may be incomplete — re-baseline and prefer the Token Status List, which never truncates",
+      "type": "boolean"
+    },
+    "issued_at": {
+      "description": "When this list was generated",
+      "type": "string"
+    },
+    "kid": {
+      "description": "Key id of the signing key, for JWKS lookup",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "revoked": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "proof_id": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "proof_type": {
+            "type": "string"
+          },
+          "public_proof_id": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "reason": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "revoked_at": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "proof_id",
+          "public_proof_id",
+          "proof_type",
+          "revoked_at",
+          "reason"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "signature": {
+      "description": "Signature over the payload for offline verification, in the algorithm of the key `kid` names (null when unsigned)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "status_list_uri": {
+      "description": "The Token Status List endpoint — the scalable status channel that also covers SUSPENDED and can retract entries (an unsuspended bit flips back; a CRL entry cached by a `?since` poller cannot be unpublished)",
+      "type": "string"
+    }
+  },
+  "required": [
+    "revoked",
+    "issued_at",
+    "count",
+    "has_more",
+    "status_list_uri",
+    "signature",
+    "kid"
+  ],
+  "type": "object"
+}

First observedv1.1.0Sep 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint annotation by disclosing two distinct freshness windows: a 5-minute cache lifetime and a 1-hour offline signature verifiability window. That is exactly the staleness information an agent needs to decide whether a cached list is still trustworthy.

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?

Two sentences, front-loaded with purpose and followed by the caching rule. Every clause carries operational meaning — cache lifetime and signature lifetime are both load-bearing.

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?

Return values are covered by the output schema and safety by the readOnlyHint annotation, so the description only needed to supply the freshness semantics, which it does completely. Nothing required to call or trust the result is missing.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly adds no redundant parameter prose.

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 ('Get the revocation list') and scopes it precisely to 'offline proof validation', which separates it from sibling reads such as get_proof_status, get_request_proofs, and validate_proof. The second sentence reinforces exactly what is returned: a signed list of all revoked proof IDs.

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?

Gives clear operating context: fetch this when you need revocation data for offline validation, reuse for up to 5 minutes, refetch to pick up new revocations. It does not explicitly exclude alternatives (e.g., when to call validate_proof instead), so it stops short of full when/when-not routing.

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

Deploy Server