Proof Holdings

create_authorization

Create a new authorization request. Authorizations grant permission to send confirmations to a user via a specific channel. The user must approve the authorization before confirmations can be sent.

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": {
      "hitl_id": "<hitl_id>",
      "recipient": "<recipient>",
      "phone": "<phone>",
      "channel": "<channel>"
    },
    "name": "create_authorization"
  }
}

Input Schema

Name	Required	Description
`bsuid`	No	WhatsApp Business-Scoped User ID (alternative to phone for WhatsApp channel)
`phone`	Yes	Target phone number in E.164 format (e.g., +15551234567)
`scope`	No	Authorization scope (default: confirmations)
`channel`	Yes	Channel for sending confirmations
`hitl_id`	Yes	HITL configuration ID to link this authorization to
`recipient`	Yes	Channel-specific recipient identifier (chat_id for Telegram, phone/BSUID for WhatsApp)
`expires_in`	No	Expiry in seconds (max 90 days, default 90 days)
`business_name`	No	Deprecated and ignored: the consent message always names the approval setup's sub-account. Leave it out.
`business_profile_id`	No	Sub-account to record on the authorization (does not change the name the person sees)

Output Schema

Name	Required	Description
`id`	Yes	MongoDB ObjectId
`bsuid`	No	WhatsApp Business-Scoped User ID
`phone`	No
`scope`	Yes	Scope of the authorization. `identity_challenge` is the Proof of Me scope.
`status`	Yes	Status of an authorization
`channel`	Yes	Channel authorized for sending confirmations
`hitl_id`	Yes
`recipient`	No	Channel-specific recipient identifier (chat_id for Telegram, phone or BSUID for WhatsApp)
`created_at`	Yes
`expires_at`	Yes
`business_name`	Yes	The name the consent message carried: the approval setup's sub-account name, never a name typed in the request.
`authorization_url`	Yes	URL to send to the user for authorization

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "Response from creating an authorization request",
+  "properties": {
+    "authorization_url": {
+      "description": "URL to send to the user for authorization",
+      "type": "string"
+    },
+    "bsuid": {
+      "description": "WhatsApp Business-Scoped User ID",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "business_name": {
+      "description": "The name the consent message carried: the approval setup's sub-account name, never a name typed in the request.",
+      "type": "string"
+    },
+    "channel": {
+      "description": "Channel authorized for sending confirmations",
+      "type": "string"
+    },
+    "created_at": {
+      "type": "string"
+    },
+    "expires_at": {
+      "type": "string"
+    },
+    "hitl_id": {
+      "allOf": [
+        {
+          "type": "string"
+        },
+        {}
+      ]
+    },
+    "id": {
+      "description": "MongoDB ObjectId",
+      "type": "string"
+    },
+    "phone": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "recipient": {
+      "description": "Channel-specific recipient identifier (chat_id for Telegram, phone or BSUID for WhatsApp)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "scope": {
+      "description": "Scope of the authorization. `identity_challenge` is the Proof of Me scope.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Status of an authorization",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "status",
+    "hitl_id",
+    "channel",
+    "scope",
+    "business_name",
+    "authorization_url",
+    "expires_at",
+    "created_at"
+  ],
+  "type": "object"
+}

Changed1 schema field changedOct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```

Changed3 schema fields changedOct 22, 2026

changedInput schema / properties / business_name / description

Previous value: -"Business name displayed to user during authorization"New value: +"Deprecated and ignored: the consent message always names the approval setup's sub-account. Leave it out."

changedInput schema / properties / business_profile_id / description

Previous value: -"Public profile ID for branding"New value: +"Sub-account to record on the authorization (does not change the name the person sees)"

changedInput schema / required

Previous value: -[
-  "hitl_id",
-  "recipient",
-  "phone",
-  "channel",
-  "business_name"
-]New value: +[
+  "hitl_id",
+  "recipient",
+  "phone",
+  "channel"
+]

First observedSep 19, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the annotations (write, non-destructive), it discloses a two-step consent flow (approval required before confirmations send) and concrete auth gating. This is meaningful context an agent cannot infer from the schema. It does not mention rate limits or what happens on re-issue/duplicate, keeping it below 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?

Front-loaded purpose followed by the access prerequisite. No filler sentences, though the two-paragraph layout with an ACCESS block could be tighter; every sentence still carries information.

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?

An output schema exists so return values need not be explained, and the auth prerequisite plus consent-flow context cover what's needed to call it correctly. Only the sibling disambiguation and duplicate-handling edge cases are missing.

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 all 9 parameters are already documented, including the deprecated business_name note and enums. The description adds no parameter-level guidance, so baseline 3 applies.

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?

States a specific verb+resource ('Create a new authorization request') and explains the concept — permission to send confirmations via a channel. This distinguishes it conceptually from create_confirmation, though it does not name that sibling explicitly to sharpen the boundary.

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?

Gives real preconditions: a Proof account is required, the client must be authenticated, and start_login does NOT open this tool. It also clarifies that the target user must approve before confirmations flow. It stops short of contrasting with related tools like request_hitl_authorization or create_delegation.

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.