@proof-holdings/mcp-server

Official

by ProofHoldings

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

create_user_request

Create a verification request so another user can share verified assets such as email, phone, or domain.

Instructions

Create a new verification request to ask another user to share verified assets. Each asset is an object naming its type, e.g. { "type": "email" }.

ACCESS: needs a Proof account. Set PROOF_API_KEY and restart this server, or sign in with start_login — a session opens this tool — then call this tool again.

Input Schema

TableJSON Schema

Name	Required	Description
`assets`	Yes	Assets to request, e.g. [{ "type": "email" }, { "type": "phone", "required": false }]
`partial_ok`	No	Whether partial asset sharing is acceptable (default: false)
`action_type`	No	Purpose of the request (default: verification); custom and confirmation also need an action_context title
`callback_url`	No	HTTPS webhook URL for request status updates
`redirect_url`	No	HTTPS URL to redirect the subject after completing the request
`reference_id`	No	External reference ID for tracking
`action_context`	No	What the recipient is shown about why the assets are needed, e.g. { "title": "Confirm your contact details" }
`expires_in_hours`	No	Hours until request expires (default: 168, i.e. 7 days)
`public_profile_id`	No	Public profile ID for branding
`validity_requirement`	No	How recently an existing proof must have been verified for the recipient to reuse it: a number and a unit, h hours, d days, w weeks or m months (30 days), e.g. "24h", "7d", "1m"

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedv1.6.0Oct 16, 2026

addedInput schema / properties / action_context / additionalProperties
```
Added value: +false
```

changedInput schema / properties / action_context / description

Previous value: -"Additional context about why assets are needed"New value: +"What the recipient is shown about why the assets are needed, e.g. { \"title\": \"Confirm your contact details\" }"

addedInput schema / properties / action_context / properties

Added value: +{
+  "amount": {
+    "exclusiveMinimum": 0,
+    "type": "number"
+  },
+  "currency": {
+    "maxLength": 10,
+    "minLength": 1,
+    "type": "string"
+  },
+  "description": {
+    "maxLength": 500,
+    "minLength": 1,
+    "type": "string"
+  },
+  "entity": {
+    "maxLength": 200,
+    "minLength": 1,
+    "type": "string"
+  },
+  "title": {
+    "maxLength": 100,
+    "minLength": 1,
+    "type": "string"
+  }
+}

changedInput schema / properties / action_context / type
```
Previous value: -"string"New value: +"object"
```

changedInput schema / properties / action_type / description

Previous value: -"Purpose of the request (default: verification)"New value: +"Purpose of the request (default: verification); custom and confirmation also need an action_context title"

changedInput schema / properties / action_type / enum

Previous value: -[
-  "verification",
-  "onboarding",
-  "compliance"
-]New value: +[
+  "verification",
+  "2fa",
+  "login",
+  "custom",
+  "confirmation",
+  "authorization"
+]

changedInput schema / properties / assets / description

Previous value: -"Asset type identifiers to request (e.g. email, phone, identity)"New value: +"Assets to request, e.g. [{ \"type\": \"email\" }, { \"type\": \"phone\", \"required\": false }]"

addedInput schema / properties / assets / items / additionalProperties
```
Added value: +false
```

addedInput schema / properties / assets / items / properties

Added value: +{
+  "allowed_channels": {
+    "description": "Channels the recipient may choose from",
+    "items": {
+      "enum": [
+        "whatsapp",
+        "telegram",
+        "sms",
+        "email",
+        "dns",
+        "http",
+        "auto",
+        "github",
+        "google",
+        "facebook",
+        "x",
+        "linkedin",
+        "instagram",
+        "youtube",
+        "tiktok",
+        "ethereum",
+        "solana",
+        "bitcoin",
+        "coinbase",
+        "kraken",
+        "telegram_bot_token"
+      ],
+      "type": "string"
+    },
+    "maxItems": 10,
+    "type": "array"
+  },
+  "channel": {
+    "description": "Verification channel to use for this asset",
+    "enum": [
+      "whatsapp",
+      "telegram",
+      "sms",
+      "email",
+      "dns",
+      "http",
+      "auto",
+      "github",
+      "google",
+      "facebook",
+      "x",
+      "linkedin",
+      "instagram",
+      "youtube",
+      "tiktok",
+      "ethereum",
+      "solana",
+      "bitcoin",
+      "coinbase",
+      "kraken",
+      "telegram_bot_token"
+    ],
+    "type": "string"
+  },
+  "identifier": {
+    "description": "The exact value to verify (e.g. an email address); omit to let the recipient choose",
+    "maxLength": 500,
+    "minLength": 1,
+    "type": "string"
+  },
+  "required": {
+    "description": "Whether this asset must be verified (default: true)",
+    "type": "boolean"
+  },
+  "type": {
+    "description": "What to verify",
+    "enum": [
+      "phone",
+      "email",
+      "domain",
+      "social",
+      "wallet",
+      "telegram_bot"
+    ],
+    "type": "string"
+  }
+}

addedInput schema / properties / assets / items / required
```
Added value: +[
+  "type"
+]
```
changedInput schema / properties / assets / items / type
```
Previous value: -"string"New value: +"object"
```

changedInput schema / properties / callback_url / description

Previous value: -"Webhook URL for request status updates"New value: +"HTTPS webhook URL for request status updates"

addedInput schema / properties / callback_url / maxLength
```
Added value: +2000
```
addedInput schema / properties / callback_url / pattern
```
Added value: +"^https:\\/\\/"
```

changedInput schema / properties / expires_in_hours / description

Previous value: -"Hours until request expires (default: 24)"New value: +"Hours until request expires (default: 168, i.e. 7 days)"

addedInput schema / properties / public_profile_id / pattern
```
Added value: +"^[0-9a-fA-F]{24}$"
```

changedInput schema / properties / redirect_url / description

Previous value: -"URL to redirect the subject after completing the request"New value: +"HTTPS URL to redirect the subject after completing the request"

addedInput schema / properties / redirect_url / maxLength
```
Added value: +2000
```
addedInput schema / properties / redirect_url / pattern
```
Added value: +"^https:\\/\\/"
```
addedInput schema / properties / reference_id / maxLength
```
Added value: +255
```
addedInput schema / properties / reference_id / minLength
```
Added value: +1
```

changedInput schema / properties / validity_requirement / description

Previous value: -"Required validity level for shared assets"New value: +"How recently an existing proof must have been verified for the recipient to reuse it: a number and a unit, h hours, d days, w weeks or m months (30 days), e.g. \"24h\", \"7d\", \"1m\""

addedInput schema / properties / validity_requirement / pattern
```
Added value: +"^\\d+[hdwm]$"
```

First observedv1.1.0Sep 9, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-but-not-destructive profile is covered. The description adds real value by disclosing the account/auth prerequisite and the login flow that unlocks the tool, but says nothing about what happens after creation (request state, notifications, idempotency, or rate limits).

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 short, front-loaded paragraphs: the core action first, then the access prerequisite. No filler or repetition, though the inline asset example is arguably redundant given the schema's own example.

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

Completeness3/5

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

For a 10-parameter tool with nested objects and no output schema, the description covers the action and the auth gate but omits the return shape (request ID, link, status) and any lifecycle context, which an agent needs since no output schema fills that gap.

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% across all 10 parameters, including enums and nested action_context, so the schema carries the semantic load. The description's asset example ({ "type": "email" }) only restates what the schema already documents, so it adds no meaning beyond the structured field. Baseline 3 is appropriate.

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 and resource ('Create a new verification request') and clarifies the goal ('ask another user to share verified assets'), which is more than a name restatement. However, it never distinguishes itself from the many near-identical siblings in this namespace (create_verification_request, create_verification, create_authorization, create_confirmation, create_hitl), so an agent cannot tell which creation tool to pick from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The ACCESS paragraph gives a genuine prerequisite (needs a Proof account; set PROOF_API_KEY or sign in via start_login, which opens this tool). That is useful when-to-use context, but it is auth onboarding rather than routing guidance — nothing says when to use this over create_verification_request or the other request-creating siblings.

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

Deploy Server

create_user_request

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools