Skip to main content
Glama
Sign In

Proof Holdings

by holdings.proof
OverviewDiscussionsAdmin

update_settings

Destructive

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. Authenticate this client (Claude Code: /mcp → Authenticate), then call this tool again. start_login does NOT open this tool.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
hitlNoApproval-setup settings
webhookNoOutbound webhook configuration. Deliveries carry an HMAC-SHA256 X-Proof-Signature over "<X-Proof-Timestamp>.<body>".
proof_expiry_daysNoDefault proof-token lifetime in days for newly issued proofs

Output Schema

NameRequiredDescriptionDefault
hitlNoApproval-setup settings.
successNo
webhookNoOutbound 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_daysNoDefault 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.

  1. Changed2 schema fields changed
    • 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"
+}
    • 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"
+}
  2. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / webhook / additionalProperties
      Removed value: -false
  3. Changed1 schema field changed
    • 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"
-}
  4. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations mark this as non-read-only and destructive, and the description adds meaningful behavior beyond them: the signing secret is returned only when the webhook endpoint is created or the secret is rotated, and the caller must record it then. It also discloses the account-authentication requirement and warns that start_login does not unlock this tool.

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?

The scope is front-loaded in the first sentence, the update_profile alternative follows immediately, and the authentication and secret-return caveats are compact. There is no filler, and the unusual access warning earns its place.

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 nested settings tool with annotations and an output schema, the description covers the main operational risks, authentication, secret handling, and the update_profile boundary. The notable gap is that it never mentions the schema's hitl settings area, which an agent would only discover by reading the input schema.

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 documents webhook URL, event subscriptions, rotate_secret, proof lifetime, and HITL password length in detail. The description mentions the webhook and proof-lifetime areas but does not add parameter-level meaning beyond what the schema provides.

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?

The description states a specific verb and resource (update account settings) and names the concrete areas of webhook subscriptions and default proof lifetime. It also distinguishes branding from update_profile, although it omits the schema's top-level hitl settings, so the scope is not fully enumerated.

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 clearly tells the agent to use update_profile for branding and gives an explicit authentication prerequisite and retry flow. It does not explain when to use this tool instead of the dedicated webhook siblings such as update_webhook_endpoint or rotate_webhook_endpoint_secret, leaving some sibling routing 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 toolsInspect
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.

Resources