Skip to main content
Glama
Sign In
@proof-holdings/mcp-server

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

verify_delegation

Read-only

Verifies that an expected domain authorized a specific agent artifact, walking signature, principal, delegate and revocation. Requires an identity you resolved yourself to defeat copied tokens.

Instructions

Verify a Proof of Delegation — the attestation that a domain authorized a specific agent artifact. Pass either the artifact's card (MCP server.json / A2A agent card) or a raw delegation token, PLUS two facts you established yourself: the artifact identity you resolved (the package you are installing, the endpoint you are calling) and the domain you expect to stand behind it. Both are required — a token can be copied into someone else's card, and any domain owner can mint a valid delegation naming someone else's package, so a verdict without both pins would mean 'some domain said something about some artifact'. WHERE THE IDENTITY MAY COME FROM: it is the artifact you are acting on, and never a value read from inside the artifact you are checking. A name in the artifact's own package.json, card or manifest is self-declared and editable by whoever ships it, so checking it against the delegation compares the artifact with itself. Resolve it afresh at call time instead of reusing a value from earlier in this conversation, which may already be stale. When no independently resolvable identity exists — a local or unpublished artifact — you have nothing to compare against, and that is the honest answer: report it rather than a mismatch, because a mismatch here reads as an accusation against the domain named in the delegation. The verifier walks signature → principal → delegate → revocation status, including the cascade down to the domain control proof. Requires no API key. What a verified result means: the expected domain's controller authorized this artifact — NOT that the artifact is safe, audited or endorsed.

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": {
      "delegate": "<delegate>",
      "expected_principal": "<expected_principal>"
    },
    "name": "verify_delegation"
  }
}

Input Schema

NameRequiredDescriptionDefault
cardNoThe MCP server card or A2A agent card to read the delegation from
tokenNoA raw delegation token, when you already have it instead of a card
delegateYesThe artifact identity you resolved independently. Required: this comparison is what defeats a copied token.
check_statusNoDefault true. When false the signature and claims are checked but revocation is NOT — treat the result as "not revoked-checked", never as "not revoked".
expected_principalYesRequired. The domain you expect to have authorized this artifact (e.g. postmarkapp.com) — an issuer binds the artifact to nothing, so any domain owner can mint a valid delegation for someone else's package. Without this pin the answer is only "some domain claims this".

Output Schema

NameRequiredDescriptionDefault
reasonNoWhen not verified: the verifier's failure reason
attestsNoWhen verified: what the delegation attests, in one sentence
messageNoWhen not verified: a readable explanation
outcomeNoWhen not verified: invalid (a genuine negative verdict) or unconfirmed (no confident answer right now)
verifiedYestrue when the delegation verified; false is a verdict, read reason and outcome
pull_hintNoWhere to pull a re-signed token after key_revoked
delegationNoWhen verified: the verified claims
disclaimerNoWhen verified: what the verdict does not say
refresh_hintNoHow to refresh the key set
status_checkedNoWhen verified: whether revocation was checked
cache_age_secondsNoHow stale the key set is after jwks_stale, in seconds; null when unknown
principal_checkedNoWhen verified: whether the principal was compared with expected_principal

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.7.2
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / card / propertyNames
      Added value: +{
+  "type": "string"
+}
    • removedInput schema / properties / delegate / additionalProperties
      Removed value: -false
    • removedInput schema / 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": {
+    "attests": {
+      "description": "When verified: what the delegation attests, in one sentence",
+      "type": "string"
+    },
+    "cache_age_seconds": {
+      "description": "How stale the key set is after jwks_stale, in seconds; null when unknown",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "delegation": {
+      "additionalProperties": {},
+      "description": "When verified: the verified claims",
+      "properties": {
+        "control_proof": {
+          "type": "string"
+        },
+        "delegate": {
+          "type": "string"
+        },
+        "delegation_id": {
+          "type": "string"
+        },
+        "expires_at": {
+          "type": "string"
+        },
+        "issued_at": {
+          "type": "string"
+        },
+        "issuer": {
+          "type": "string"
+        },
+        "principal": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "issuer",
+        "principal",
+        "delegate",
+        "control_proof",
+        "delegation_id",
+        "issued_at",
+        "expires_at"
+      ],
+      "type": "object"
+    },
+    "disclaimer": {
+      "description": "When verified: what the verdict does not say",
+      "type": "string"
+    },
+    "message": {
+      "description": "When not verified: a readable explanation",
+      "type": "string"
+    },
+    "outcome": {
+      "description": "When not verified: invalid (a genuine negative verdict) or unconfirmed (no confident answer right now)",
+      "type": "string"
+    },
+    "principal_checked": {
+      "description": "When verified: whether the principal was compared with expected_principal",
+      "type": "boolean"
+    },
+    "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": {
+      "description": "When not verified: the verifier's failure 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"
+    },
+    "status_checked": {
+      "description": "When verified: whether revocation was checked",
+      "type": "boolean"
+    },
+    "verified": {
+      "description": "true when the delegation verified; false is a verdict, read reason and outcome",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "verified"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, and the description adds substantial context beyond that: no API key required, the verification chain walked (signature → principal → delegate → revocation, including the domain control proof cascade), the check_status caveat that a false setting means 'not revoked-checked' not 'not revoked', and an explicit scope limit that a verified result does not mean the artifact is safe or audited.

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?

Front-loaded correctly — what it does and the required inputs come first — but it runs long and repeats itself: the copied-token rationale appears in the opening paragraph and again in the delegate schema text, and the 'any domain owner can mint a delegation' argument is stated twice. Several clauses could be consolidated without losing any guidance.

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, so return values need no explanation, and the description still covers the parts a schema cannot: where the identity may come from, the staleness risk of reusing earlier conversation values, the negative case for local artifacts, and the precise meaning of a positive verdict. Nothing an agent needs in order to call it 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 the baseline is 3, but the prose adds real meaning: it explains WHY both delegate and expected_principal are mandatory (a copied token, or a domain minting a delegation for someone else's package), and it constrains the allowed source of the delegate value far beyond the schema's wording.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ("Verify a Proof of Delegation") and defines what the attestation is, so an agent can tell this is a single-token verification rather than a creation or listing operation. It does not, however, name the obvious sibling verify_delegations (batch) or explain the split, leaving that distinction to be inferred.

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?

Explicitly states what must be passed (card or token PLUS the two self-established pins) and adds a genuine when-not case: for local/unpublished artifacts with no independently resolvable identity, report the absence rather than a mismatch. It stops short of routing to alternative tools (verify_delegations, get_delegation, create_delegation) by name.

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