@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

verify_delegations

Read-only

Batch-verify up to 50 Proof of Delegation artifacts in one call to re-check trusted cards or tokens instead of verifying each separately; each item is checked independently with revocation included.

Instructions

Batch-verify up to 50 Proof of Delegation artifacts in one call — the inventory half of the checker (h-proof-checker-mcp): re-check everything you already trust instead of one verify_delegation call per artifact. Each item takes the same shape verify_delegation requires (card XOR token, delegate, expected_principal) and follows the same rule about where identity comes from: each delegate is the artifact you are acting on, never a value read from inside the artifact you are checking, and resolved afresh at call time. Items are verified INDEPENDENTLY — no cross-item state, nothing persisted, one item failing never affects another item's result. This tool does NOT discover what you have installed and does NOT fetch anything on your behalf: it verifies material you already hold, the same trust boundary verify_delegation draws. Revocation is always checked (there is no check_status:false here — the point of a batch re-check is to see what changed since you last looked). Each result carries an outcome: confirmed_valid (verified), confirmed_invalid (a genuine negative verdict — revoked, expired, mismatched, malformed, and similar), no_claim_found (the artifact publishes no delegation at all — an absence, never an accusation), or unconfirmed (we could not reach the issuer or otherwise get a confident answer right now — NEVER treat this as a bad verdict). Requires no API key. checked_at on each result is the moment THAT item's own check completed, not one timestamp shared across the call.

Input Schema

Name	Required	Description	Default
`items`	Yes	1-50 artifacts to verify in this call, each shaped like a verify_delegation call

Output Schema

Name	Required	Description	Default
`results`	Yes	One result per item, in the order the items were given

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.7.2Nov 6, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / items / items / additionalProperties
```
Removed value: -false
```
addedInput schema / properties / items / items / properties / card / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
removedInput schema / properties / items / items / properties / delegate / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / items / items / properties / required_scopes

Removed value: -{
-  "description": "Capability scopes the delegation must grant",
-  "items": {
-    "maxLength": 64,
-    "minLength": 1,
-    "type": "string"
-  },
-  "maxItems": 32,
-  "minItems": 1,
-  "type": "array"
-}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "results": {
+      "description": "One result per item, in the order the items were given",
+      "items": {
+        "anyOf": [
+          {
+            "additionalProperties": {},
+            "properties": {
+              "checked_at": {
+                "type": "string"
+              },
+              "outcome": {
+                "const": "confirmed_valid",
+                "type": "string"
+              },
+              "status_checked": {
+                "type": "boolean"
+              },
+              "verified": {
+                "const": true,
+                "type": "boolean"
+              }
+            },
+            "required": [
+              "outcome",
+              "verified",
+              "status_checked",
+              "checked_at"
+            ],
+            "type": "object"
+          },
+          {
+            "additionalProperties": {},
+            "properties": {
+              "cache_age_seconds": {
+                "description": "How stale the key set is after jwks_stale, in seconds; null when unknown",
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "checked_at": {
+                "type": "string"
+              },
+              "message": {
+                "type": "string"
+              },
+              "outcome": {
+                "description": "confirmed_invalid, no_claim_found or unconfirmed",
+                "type": "string"
+              },
+              "pull_hint": {
+                "additionalProperties": {},
+                "description": "Where to pull a re-signed token after key_revoked",
+                "properties": {
+                  "handle": {
+                    "type": "string"
+                  },
+                  "issuer_origin": {
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "issuer_origin",
+                  "handle"
+                ],
+                "type": "object"
+              },
+              "reason": {
+                "type": "string"
+              },
+              "refresh_hint": {
+                "additionalProperties": {},
+                "description": "How to refresh the key set",
+                "properties": {
+                  "jwks_uri": {
+                    "type": "string"
+                  },
+                  "method": {
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "jwks_uri",
+                  "method"
+                ],
+                "type": "object"
+              },
+              "verified": {
+                "const": false,
+                "type": "boolean"
+              }
+            },
+            "required": [
+              "outcome",
+              "verified",
+              "message",
+              "checked_at"
+            ],
+            "type": "object"
+          }
+        ]
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "results"
+  ],
+  "type": "object"
+}

First observedv1.1.0Sep 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The only annotation is readOnlyHint=true, so the description carries the rest and does so thoroughly: items are verified independently with no cross-item state and nothing persisted, one failing item never affects another, revocation is always checked, and no API key is required. It also defines the outcome vocabulary and warns that unconfirmed must never be read as a negative verdict, and clarifies checked_at is per-item rather than a shared timestamp.

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?

Front-loaded with purpose, batch size and the sibling alternative, then behavioral detail and the outcome enum. It is dense but stretches to roughly 250 words with some repetition — 'the same trust boundary verify_delegation draws' and 'the inventory half of the checker' say overlapping things.

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?

An output schema exists, yet the description still explains the four outcome values and the unconfirmed pitfall, which is exactly the judgment call an agent cannot infer from schema alone. Combined with the trust-boundary constraints on inputs, nothing needed to call this correctly 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?

Schema coverage is 100%, so baseline is 3; the description adds some meaning by restating the card-XOR-token rule and the delegate/expected_principal trust logic, plus the cross-item independence guarantee. Much of this duplicates the nested schema descriptions verbatim ('never a value read from inside the artifact you are checking'), so the added value is reinforcement rather than new information.

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 (batch-verify), a specific resource (Proof of Delegation artifacts), and a hard scope limit (up to 50, no discovery, no fetching). It explicitly positions itself against the sibling verify_delegation ('the inventory half of the checker' / 'instead of one verify_delegation call per artifact'), so an agent can route between the batch and single forms 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?

Gives both when-to-use ('re-check everything you already trust') and when-not ('does NOT discover what you have installed and does NOT fetch anything on your behalf'), plus the named alternative it replaces. The exclusion of a per-call check_status:false option further constrains usage explicitly.

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

Deploy Server