@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

update_settings

Destructive

Configure your Proof account's outbound webhook endpoint, event subscriptions, and default proof lifetime. Set the first webhook to create and return the signing secret for verification.

Instructions

Update account settings: the outbound webhook endpoint with its event subscriptions, and the default proof lifetime. Branding belongs to each sub-account: change it with update_profile. Setting the first webhook endpoint creates the signing secret and returns it in this response; the value is returned only when this call created or rotated it, so record it then.

ACCESS: needs a Proof account. Set PROOF_API_KEY and restart this server, then call this tool again. start_login does NOT open this tool.

Input Schema

Name	Required	Description
`hitl`	No	Approval-setup settings
`webhook`	No	Outbound webhook configuration. Deliveries carry an HMAC-SHA256 X-Proof-Signature over "<X-Proof-Timestamp>.<body>".
`proof_expiry_days`	No	Default proof-token lifetime in days for newly issued proofs

Output Schema

Name	Required	Description
`hitl`	No	Approval-setup settings.
`success`	No
`webhook`	No	Outbound webhook configuration — DEPRECATED (#421). An account switched over to webhook endpoints sees its account-wide (`legacy`) endpoint here: `url` is null while that endpoint is disabled, a `url` write updates or creates it, `url: null` disables it (its secret is kept), and `rotate_secret` rotates its secret. An account not yet switched over sees its settings fields, as before. Omitted for an API key bound to one sub-account.
`proof_expiry_days`	No	Default lifetime in days of newly issued verification proofs, or null when the account has never set one. Confirmation-decision proofs do not use it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.7.2Nov 6, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / hitl

Added value: +{
+  "description": "Approval-setup settings",
+  "properties": {
+    "approver_password_min_length": {
+      "anyOf": [
+        {
+          "maximum": 128,
+          "minimum": 8,
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The shortest encryption password an approver may choose when enrolling (8-128); null removes the minimum. Applies to new enrolments only."
+    }
+  },
+  "type": "object"
+}

removedInput schema / properties / webhook / additionalProperties
```
Removed value: -false
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "hitl": {
+      "description": "Approval-setup settings."
+    },
+    "proof_expiry_days": {
+      "description": "Default lifetime in days of newly issued verification proofs, or null when the account has never set one. Confirmation-decision proofs do not use it."
+    },
+    "success": {},
+    "webhook": {
+      "description": "Outbound webhook configuration — DEPRECATED (#421). An account switched over to webhook endpoints sees its account-wide (`legacy`) endpoint here: `url` is null while that endpoint is disabled, a `url` write updates or creates it, `url: null` disables it (its secret is kept), and `rotate_secret` rotates its secret. An account not yet switched over sees its settings fields, as before. Omitted for an API key bound to one sub-account."
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedv1.7.0Oct 16, 2026

removedInput schema / properties / branding

Removed value: -{
-  "additionalProperties": false,
-  "description": "Branding settings to update",
-  "properties": {
-    "business_name": {
-      "description": "Business name displayed in verifications",
-      "maxLength": 100,
-      "type": "string"
-    },
-    "email_theme": {
-      "description": "Email template theme",
-      "enum": [
-        "dark",
-        "light"
-      ],
-      "type": "string"
-    },
-    "logo_url": {
-      "anyOf": [
-        {
-          "anyOf": [
-            {
-              "not": {}
-            },
-            {
-              "format": "uri",
-              "type": "string"
-            }
-          ]
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "description": "HTTPS URL to business logo"
-    },
-    "primary_color": {
-      "description": "Primary brand color (hex, e.g. #FF5733)",
-      "pattern": "^#[0-9A-Fa-f]{6}$",
-      "type": "string"
-    },
-    "support_email": {
-      "description": "Support email shown in verification messages",
-      "format": "email",
-      "type": "string"
-    }
-  },
-  "type": "object"
-}

Changed2 schema fields changedv1.6.0Oct 16, 2026

addedInput schema / properties / proof_expiry_days

Added value: +{
+  "description": "Default proof-token lifetime in days for newly issued proofs",
+  "maximum": 365,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / webhook

Added value: +{
+  "additionalProperties": false,
+  "description": "Outbound webhook configuration. Deliveries carry an HMAC-SHA256 X-Proof-Signature over \"<X-Proof-Timestamp>.<body>\".",
+  "properties": {
+    "events": {
+      "description": "Subscription patterns: an exact event type, a family wildcard such as \"proof.*\", or \"*\". An empty list means every event.",
+      "items": {
+        "type": "string"
+      },
+      "maxItems": 32,
+      "type": "array"
+    },
+    "rotate_secret": {
+      "description": "Replace the signing secret and return the new value. The previous value stops verifying immediately.",
+      "type": "boolean"
+    },
+    "url": {
+      "anyOf": [
+        {
+          "format": "uri",
+          "maxLength": 2000,
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "HTTPS endpoint outbound webhooks are delivered to, at most 2000 characters; null removes it. Private, loopback and link-local addresses are refused."
+    }
+  },
+  "type": "object"
+}

First observedv1.1.0Sep 9, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the destructiveHint annotation, it discloses the key side effects an agent cannot infer: setting the first endpoint mints a signing secret, the secret is returned only on creation or rotation so it must be recorded immediately, and rotating kills the old value for verification instantly. It also states the auth precondition and that start_login does not unlock this tool, which is exactly the kind of info that prevents a failed call.

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?

Two tight paragraphs: the scope and the update_profile split come first, the irreversible secret behavior next, and the access prerequisite is isolated in a clearly labeled block. Every sentence earns its place; the only cost is that the dense secret-handling sentence packs creation and rotation semantics into one clause.

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?

With annotations, a full output schema and 100% schema coverage, the description supplies the pieces structured data cannot: access prerequisites, secret lifecycle, and the branding-to-profile routing. The remaining gaps are the unmentioned `hitl` group and the lack of routing against the dedicated webhook-endpoint and secret-rotation tools that overlap this one.

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 description coverage is 100%, so the schema already carries most parameter meaning and the baseline is 3. The description does add value for the webhook URL (that providing one creates the signing secret) and for the returned secret, but says nothing about the `hitl.approver_password_min_length` setting even though it is one of the three top-level parameters.

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?

"Update account settings" is paired with a concrete enumeration of the mutable resources (outbound webhook endpoint with event subscriptions, default proof lifetime), which makes the scope unambiguous. It also explicitly separates branding from this tool and points at update_profile. The enumeration is incomplete, though: the `hitl` approval-password setting is a top-level parameter that the opening sentence never mentions.

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?

It gives a clear when-not ("Branding belongs to each sub-account: change it with update_profile") and a concrete precondition sequence for access (set PROOF_API_KEY, restart, retry; start_login will not help). What it omits is the more pressing ambiguity: the sibling set contains create_webhook_endpoint, update_webhook_endpoint and rotate_webhook_endpoint_secret, and the description never says when to use this settings-level webhook block instead of those dedicated tools.

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

Deploy Server