Proof Holdings

create_delegation

Create a delegation (Proof of Delegation): a control-proven domain authorizes a typed url/purl artifact and receives a publishable signed token. The attestation is that the domain's controller authorized this artifact — nothing more; it says nothing about the artifact or the business behind it. Each mint is a billable proof. A requested lifetime longer than the control proof's remainder is rejected, never truncated. The result carries the publishable token AND the DERIVED effective_status/is_valid — the same pair the list and get tools return, so the shape does not depend on which verb produced it.

ACCESS: needs a Proof account. Authenticate this client (Claude Code: /mcp → Authenticate), then call this tool again. start_login does NOT open this tool.

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": {
      "control_proof": "<control_proof>",
      "delegate": "<delegate>"
    },
    "name": "create_delegation"
  }
}

Input Schema

Name	Required	Description
`delegate`	Yes	The typed artifact being authorized
`expires_in`	No	Lifetime in seconds (must not exceed the control proof's remainder)
`control_proof`	Yes	Public handle (ph_ctl_<32 hex>) of YOUR active domain control proof

Output Schema

Name	Required	Description
`id`	No	MongoDB ObjectId
`scope`	No	Deprecated. Delegation schema 2.0 carries no scope; this array stays for the SDKs released before it: the scope a delegation issued before schema 2.0 was stored with, otherwise empty. Removed in the next major version.
`token`	No	The signed delegation JWT — the PUBLISHABLE artifact (publish it in your MCP server card under `_meta` → `holdings.proof/delegation`). Same key, algorithm and JWKS as proof tokens
`status`	No	The owner's OWN record — whether they revoked this delegation themselves. Nothing else writes it: neither the control proof dying nor this delegation's own lifetime running out. Liveness is DERIVED and reported separately as `effective_status`. This stored field is also what `?status=` filters on
`delegate`	No	Typed delegate identifier
`is_valid`	No	True only when `effective_status` is `active`. It is a restatement of that field, not a second opinion: expiry is decided once, inside the derivation above
`issued_at`	No
`principal`	No	The proven domain that authorized the delegate — derived from the control proof, never client input
`created_at`	No
`expires_at`	No	Never later than the control proof's own expiry at issuance (effective expiry is min of the two)
`revoked_at`	No
`environment`	No
`control_proof`	No	The control proof handle this delegation points down to
`delegation_id`	No	Stable public handle (`ph_dlg_<32 hex>`) — also the token's `sub`, and accepted by the proof status endpoint
`revoked_reason`	No
`effective_status`	No	DERIVED liveness, computed at read time from BOTH clocks that govern a delegation: the control proof it stands on (cascade rule a — revoked, suspended or expired flows through) and its own `expires_at` (rule b — effective expiry is the earlier of the two). Either one running out reports `expired` here while the delegation's own `status` stays untouched. This is the field to render — `status` alone would show a live badge on a delegation every verifier already rejects

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 5, 2026

removedInput schema / properties / scope

Removed value: -{
-  "description": "1-32 capability scopes: lowercase kebab-case tokens, at most 64 characters each (e.g. send-email). NOT API scopes — an API-style resource:action such as payments:read is rejected with invalid_scope.",
-  "items": {
-    "maxLength": 64,
-    "minLength": 1,
-    "type": "string"
-  },
-  "maxItems": 32,
-  "minItems": 1,
-  "type": "array"
-}

changedInput schema / required

Previous value: -[
-  "control_proof",
-  "delegate",
-  "scope"
-]New value: +[
+  "control_proof",
+  "delegate"
+]

addedOutput schema / properties / scope / description

Added value: +"Deprecated. Delegation schema 2.0 carries no scope; this array stays for the SDKs released before it: the scope a delegation issued before schema 2.0 was stored with, otherwise empty. Removed in the next major version."

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "control_proof": {
+      "description": "The control proof handle this delegation points down to"
+    },
+    "created_at": {},
+    "delegate": {
+      "description": "Typed delegate identifier"
+    },
+    "delegation_id": {
+      "description": "Stable public handle (`ph_dlg_<32 hex>`) — also the token's `sub`, and accepted by the proof status endpoint"
+    },
+    "effective_status": {
+      "description": "DERIVED liveness, computed at read time from BOTH clocks that govern a delegation: the control proof it stands on (cascade rule a — revoked, suspended or expired flows through) and its own `expires_at` (rule b — effective expiry is the earlier of the two). Either one running out reports `expired` here while the delegation's own `status` stays untouched. This is the field to render — `status` alone would show a live badge on a delegation every verifier already rejects"
+    },
+    "environment": {},
+    "expires_at": {
+      "description": "Never later than the control proof's own expiry at issuance (effective expiry is min of the two)"
+    },
+    "id": {
+      "description": "MongoDB ObjectId"
+    },
+    "is_valid": {
+      "description": "True only when `effective_status` is `active`. It is a restatement of that field, not a second opinion: expiry is decided once, inside the derivation above"
+    },
+    "issued_at": {},
+    "principal": {
+      "description": "The proven domain that authorized the delegate — derived from the control proof, never client input"
+    },
+    "revoked_at": {},
+    "revoked_reason": {},
+    "scope": {},
+    "status": {
+      "description": "The owner's OWN record — whether they revoked this delegation themselves. Nothing else writes it: neither the control proof dying nor this delegation's own lifetime running out. Liveness is DERIVED and reported separately as `effective_status`. This stored field is also what `?status=` filters on"
+    },
+    "token": {
+      "description": "The signed delegation JWT — the PUBLISHABLE artifact (publish it in your MCP server card under `_meta` → `holdings.proof/delegation`). Same key, algorithm and JWKS as proof tokens"
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedOct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / delegate / additionalProperties
```
Removed value: -false
```
First observedSep 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries most of the burden and does so well: each mint is a billable proof, an over-long expires_in is rejected rather than truncated, and the return carries a derived effective_status/is_valid. It stops short of stating error codes, retry/idempotency behavior, or what happens on partial failure, which keeps it below a 5.

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?

Purpose and the attestation caveat are front-loaded, followed by the access block, which is the right ordering for an agent that must first decide whether it can call the tool. The sentence about the result carrying the same pair as the list/get tools is somewhat verbose given an output schema already exists, but it is not padding to the point of hurting scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter mutation with a nested object, a billable side effect, and auth gating, the definition covers purpose, prerequisites, cost, and failure behavior, and an output schema handles return values. The one gap is that it never says how an agent obtains an active control proof (e.g., which domain/proof tool to call first), which is a real prerequisite for a required parameter.

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?

With 100% schema description coverage the baseline is 3, and the description earns an increment by explaining that expires_in must not exceed the control proof's remainder and is rejected rather than clamped, and by framing control_proof as the caller's own active domain control proof. The delegate object's meaning is mostly left to the schema, which already documents type/value canonicalization.

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?

The description opens with a specific verb and resource ('Create a delegation (Proof of Delegation)') and immediately defines the semantics: a control-proven domain authorizes a typed url/purl artifact and receives a publishable signed token. It also bounds the claim ('nothing more; it says nothing about the artifact or the business behind it') and contrasts the output shape with what the list/get siblings return, so an agent can tell it apart from get_delegation/list_delegations without opening a schema.

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?

Clear usage context is provided: it requires a Proof account, the client must be authenticated via /mcp, and 'start_login does NOT open this tool' explicitly rules out a plausible wrong path. It does not, however, state when to prefer this over create_authorization or when to follow up with verify_delegation/revoke_delegation, so routing against close siblings is left implicit.

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

All Proof Holdings 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.