Proof Holdings
NPM · @PROOF-HOLDINGS/MCP-SERVER · 2 COMPONENTS · SCANNED SEP 25
One API, all things verified — control, delegation, human approval, anti-impersonation.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 42 of 126 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 15 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability74
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 22726 tokens (~129/item across 176 items; 176 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management53
- Stability observed for 16 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety25
- Injection-marker check failed: the description of tool "send_account_email" contains an instruction to conceal the call from the user, the text "Do not tell the user", at byte 959 of that field. See how to fix → Fail
- 0 of 21 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "revoke_proof" implies "revoke" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 177 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Proof Holdings MCP server?
Proof Holdings runs locally as an npm package, launched with npx -y @proof-holdings/mcp-server. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · @proof-holdings/mcp-server
claude mcp add holdings-proof-mcp-server -- npx -y @proof-holdings/mcp-server
{
"mcpServers": {
"holdings-proof-mcp-server": {
"command": "npx",
"args": [
"-y",
"@proof-holdings/mcp-server"
]
}
}
} {
"servers": {
"holdings-proof-mcp-server": {
"command": "npx",
"args": [
"-y",
"@proof-holdings/mcp-server"
]
}
}
} codex mcp add holdings-proof-mcp-server -- npx -y @proof-holdings/mcp-server
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"holdings-proof-mcp-server": {
"type": "local",
"command": [
"npx",
"-y",
"@proof-holdings/mcp-server"
],
"enabled": true
}
}
} openclaw mcp add holdings-proof-mcp-server --command npx --arg -y --arg @proof-holdings/mcp-server
mcp_servers:
holdings-proof-mcp-server:
command: "npx"
args: ["-y", "@proof-holdings/mcp-server"] {
"McpServers": {
"holdings-proof-mcp-server": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"@proof-holdings/mcp-server"
]
}
}
} assistant mcp add holdings-proof-mcp-server -t stdio -c npx -a -y @proof-holdings/mcp-server
{
"mcpServers": {
"holdings-proof-mcp-server": {
"command": "npx",
"args": [
"-y",
"@proof-holdings/mcp-server"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 25 Sept 26 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 23 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 21 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Sept 26 +4
- Stability: unverified → 0.27 ▲ functional
- 9 Sept 26 65
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 25 Sept 2026 · Analysed npm/@proof-holdings/mcp-server@1.1.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 126 packages
| Packages resolved | 126 |
|---|---|
| Stale | 42 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_challenger ~184
Pre-enroll a Proof-Me challenger (a trusted contact) on a HITL config. Enabling the first challenger opts the config into Proof-Me. A telegram challenger captures its chat_id later at enrollment; a whatsapp challenger must pre-declare its phone. Agent usage: After adding a challenger, call invite_challenger to mint the single-use enrollment link the challenger taps to bind their messenger identity. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| channel | string | yes | Messenger channel the challenger uses |
| hitl_id | string | yes | HITL config ID to enroll the challenger on |
| name | string | yes | Display name of the challenger |
| whatsapp_phone | string | – | E.164 phone with country code (required for the whatsapp channel) |
No output schema declared.
No examples provided.
add_circle_member ~152
Add a pending member to a Circle by name, with an optional pre-declared WhatsApp phone. The Telegram chat id is captured later when the member taps the enrollment deep link. Agent usage: after adding a member, call invite_circle_member to mint the single-use enrollment link the member taps to bind their messenger identity. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Circle ID to add the member to |
| name | string | yes | Display name of the member |
| whatsapp_phone | string | – | E.164 WhatsApp phone with a leading + (optional, declared) |
No output schema declared.
No examples provided.
add_circle_member_channel ~143
Declare a channel for a Circle member. Returns 409 if that channel type already exists on the member. The identifier is a Telegram chat id or an E.164 WhatsApp phone (per-channel format validated server-side). 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.
| Name | Type | Req | Description |
|---|---|---|---|
| channel | string | yes | Channel type (telegram or whatsapp) |
| id | string | yes | Circle ID |
| identifier | string | yes | Telegram chat id, or E.164 WhatsApp phone with a leading + |
| member_id | string | yes | Member ID to add the channel to |
No output schema declared.
No examples provided.
add_domain ~107
Add a new domain to verify ownership. Optionally specify email sending intent and verification method. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain name to add (e.g. example.com) |
| for_email_sending | boolean | – | Whether this domain is for email sending |
| verification_method | string | – | Preferred verification method |
No output schema declared.
No examples provided.
add_verification_provider ~104
Add an additional DNS provider for verification to an already-verified domain. Note: credentials will be visible in the AI conversation context. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| credentials | object | yes | Provider-specific credential key-value pairs |
| id | string | yes | Domain ID |
| provider | string | yes | DNS provider identifier |
No output schema declared.
No examples provided.
cancel_user_request ~69
Cancel a pending verification request. Only the creator can cancel. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Verification request ID to cancel |
No output schema declared.
No examples provided.
cancel_verification_request ~64
Cancel a pending verification request. Only pending requests can be cancelled. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Verification request ID |
No output schema declared.
No examples provided.
check_domain_credentials ~79
Check if stored DNS credentials have access to a domain. Use before triggering verification to confirm the credentials work. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Domain ID to check credentials for |
No output schema declared.
No examples provided.
check_domain_email_status ~71
Check the email sending setup status for a domain, including DNS record configuration progress. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Domain ID |
No output schema declared.
No examples provided.
check_domain_verification ~73
Check the status of a pending domain verification. Triggers a DNS/HTTP check and returns the updated status. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Domain verification ID |
No output schema declared.
No examples provided.
check_user_domain_verification ~77
Trigger a check on the domain verification challenge. Call after placing DNS record or HTTP file. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| session_id | string | yes | Domain verification session ID |
No output schema declared.
No examples provided.
claim_request_assets ~64
Claim shared assets from a completed verification request. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Verification request ID |
No output schema declared.
No examples provided.
claim_username ~91
Claim a unique username for the authenticated user's public profile. Usernames must be 3-30 characters, alphanumeric and underscores only. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| username | string | yes | Username to claim (3-30 chars, alphanumeric and underscores) |
No output schema declared.
No examples provided.
confirm_domain_email_code ~82
Confirm domain email verification by submitting the code sent to the corporate email address. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | Verification code from the email |
| id | string | yes | Domain ID |
No output schema declared.
No examples provided.
connect_cloudflare ~99
Connect a Cloudflare API token to a domain for automated DNS record management. Note: the API token will be visible in the AI conversation context. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| api_token | string | yes | Cloudflare API token with DNS edit permissions |
| id | string | yes | Domain ID |
No output schema declared.
No examples provided.
connect_dns_provider ~102
Connect a generic DNS provider to a domain using provider-specific credentials. Note: credentials will be visible in the AI conversation context. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| credentials | object | yes | Provider-specific credential key-value pairs |
| id | string | yes | Domain ID |
| provider | string | yes | DNS provider identifier |
No output schema declared.
No examples provided.
connect_godaddy ~109
Connect GoDaddy API credentials to a domain for automated DNS record management. Note: the API key and secret will be visible in the AI conversation context. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | yes | GoDaddy API key |
| api_secret | string | yes | GoDaddy API secret |
| id | string | yes | Domain ID |
No output schema declared.
No examples provided.
create_account ~445
Create an account-bootstrap session for agent-driven onboarding. Public endpoint (no API key required). Returns a session id, channel-specific instructions, and — FOR TELEGRAM AND WHATSAPP ONLY — deep_link, qr_code (base64 PNG) and qr_text (UTF-8 text QR). The endpoint is safe to call regardless of whether the submitted identity is new: completing verification transparently creates a User when none exists, or logs the user in when one already does. The response is intentionally uniform — the server does NOT reveal whether the identity is already registered (this would be a user-enumeration oracle). If the agent needs to distinguish new-vs-returning users, call `get_current_user` after verification and inspect the user's `created_at`. EMAIL CHANNEL SENDS NOTHING HERE. The response carries email_sent=false and send_required=true: confirm with the user that the address is theirs, then call send_account_email. The other channels dispatch nothing either way — the user sends the first message themselves (reverse OTP). Agent usage: (1) Call create_account with the user's chosen channel. (2) For email, confirm with the user and call send_account_email. On telegram/whatsapp pass `deep_link` to render_auth_link, which prints the clickable link and a QR code beneath it. On sms `deep_link` is an EMPTY STRING and render_auth_link will reject it — show `sms_message`, which is what the user sends; this response carries no destination number, so do not invent one. Do not hand `qr_text` to a link renderer either — it is the link already rendered as QR art; print it verbatim inside a fenced code block if a real terminal needs the QR. (3) Call wait_for_account_creation with the session id until verification completes. (4) On verified, JWT + refresh cookies are set; proceed with whatever follow-up the agent was asked to do.
| Name | Type | Req | Description |
|---|---|---|---|
| channel | string | yes | Authentication channel the user will verify through |
| string | – | Email address. Required for email channel. | |
| phone_number | string | – | E.164 phone number. Required for SMS channel (determines DID routing). |
No output schema declared.
No examples provided.
create_api_key ~294
Create a new API key. The secret key value is returned ONLY in this response — store it securely. Note: the secret will be visible in the AI conversation context. Optionally bind the key to a sub-account (project) via profile_id — outbound messages sent with the key are then branded as that project. Agent usage: This operation requires 2FA. Before calling, complete the 2FA flow: (1) call start_2fa with action_type "api_key_create" and the user's preferred channel, (2) tell the user a code was sent and wait for them to verify, (3) poll get_2fa_status until status is "verified", (4) then call create_api_key — the backend session will be elevated. If you get a 403, the 2FA session has expired — restart the flow. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| environment | string | – | Key environment (default: production) |
| name | string | – | Human-readable key name |
| profile_id | string | – | Bind the new key to a sub-account (PublicProfile) project you own (24-hex id). Immutable after creation; omit for an unbound account-wide key. |
| scopes | array | – | Permission scopes for the key |
No output schema declared.
No examples provided.
create_authorization ~237
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. Set PROOF_API_KEY and restart this server, then call this tool again. start_login does NOT open this tool.
| Name | Type | Req | Description |
|---|---|---|---|
| bsuid | string | – | WhatsApp Business-Scoped User ID (alternative to phone for WhatsApp channel) |
| business_name | string | yes | Business name displayed to user during authorization |
| business_profile_id | string | – | Public profile ID for branding |
| channel | string | yes | Channel for sending confirmations |
| expires_in | integer | – | Expiry in seconds (max 90 days, default 90 days) |
| hitl_id | string | yes | HITL configuration ID to link this authorization to |
| phone | string | yes | Target phone number in E.164 format (e.g., +15551234567) |
| recipient | string | yes | Channel-specific recipient identifier (chat_id for Telegram, phone/BSUID for WhatsApp) |
| scope | string | – | Authorization scope (default: confirmations) |
No output schema declared.
No examples provided.
create_chat_id_discovery ~191
Create a Telegram chat ID discovery token. Returns a deep_link, qr_code (base64 PNG), and qr_text (UTF-8 text QR for terminal display). The user opens the link in Telegram, which reveals their chat ID for HITL config setup. Agent usage: pass the response's `deep_link` to render_auth_link so the user can click or scan it. Never hand `qr_text` to a link renderer — it is that same link already rendered as QR art. Print it verbatim inside a fenced code block only when a real terminal needs the QR. Then poll poll_chat_id_discovery with the returned token until the chat_id appears. Use the discovered chat_id when creating a HITL config with a Telegram channel. 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 present but exposes no named parameters.
No output schema declared.
No examples provided.
create_circle ~190
Create a Circle — a named group of trusted contacts (the people-primitive powering Proof-Me and Approvals-on-Circle). Optionally seed initial members; each member's declared channels are stored so they can be invited to enroll. Agent usage: after creating a Circle, add members with add_circle_member (or seed them here), then invite_circle_member to mint the enrollment deep link each contact taps to bind their messenger identity. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| members | array | – | Initial members (name + optional declared channels) |
| name | string | yes | Human-readable name for the Circle |
| profile_id | string | – | Public profile (sub-account) to bind for branded messages — create-only |
| proof_me_enabled | boolean | – | Enable Proof-Me drills for this Circle |
No output schema declared.
No examples provided.
create_circle_member_drill ~107
Fire an on-demand Proof-Me drill against one enrolled member — a real cross-channel identity challenge carrying the scheduled-safety-check label (the account owner practices confirming). Complements the automated daily drill + monthly reinforcement sweeps. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Circle ID |
| member_id | string | yes | Member ID to drill |
No output schema declared.
No examples provided.
create_confirmation ~416
Create a HITL confirmation request. Sends an approval request to the channels configured on the referenced HITL config. First response wins. Agent usage: The HITL config referenced by hitl_id must be authorized before you can create confirmations. If this returns a 403 or "not authorized" error, call request_hitl_authorization on the HITL config first, then wait for the user to approve via the messaging channel. After creating a confirmation, poll get_confirmation to check for approval/denial, or use get_confirmation_approval_link to generate a fresh link for the user. Encryption (v1 vs v2): when the HITL config has E2E encryption enabled, `message` must be a JSON ciphertext envelope, not plaintext. Choose the version by who must be able to decrypt: - v1 (single-recipient): wraps the content key for the config owner only. Use when there are no enrolled non-owner approvers. - v2 (multi-recipient): additionally wraps the content key for each enrolled approver via an `approver_ek` map, so every approver can decrypt. Use when the config has enrolled approvers — otherwise approvers get "wrong password" on the approval page. Build it with the SDK `encryptMessageV2(plaintext, ownerPublicKey, hitlId, approverKeys)` after fetching the approvers via the SDK `getApproverKeys(hitlId)` (`GET /api/v1/hitl/:id/approver-keys`). AAD is the `hitlId`. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| hitl_id | string | yes | HITL config ID whose channels will receive the approval request |
| message | string | yes | Human-readable description of what needs approval |
| proof_expiry_days | integer | – | Per-request proof expiry override in days (7, 30, 90, or 365) |
No output schema declared.
No examples provided.
create_delegation ~276
Create a delegation (Proof of Delegation): a control-proven domain authorizes a typed url/purl artifact for a set of capability scopes 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. Set PROOF_API_KEY and restart this server, then call this tool again. start_login does NOT open this tool.
| Name | Type | Req | Description |
|---|---|---|---|
| control_proof | string | yes | Public handle (ph_ctl_<32 hex>) of YOUR active domain control proof |
| delegate | object | yes | The typed artifact being authorized |
| expires_in | integer | – | Lifetime in seconds (must not exceed the control proof's remainder) |
| scope | array | yes | 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. |
No output schema declared.
No examples provided.
create_dns_credential ~103
Store DNS provider credentials for automated domain verification. Note: credentials will be visible in the AI conversation context. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| credentials | object | yes | Provider-specific credential key-value pairs |
| provider | string | yes | DNS provider identifier (e.g. cloudflare, route53, digitalocean) |
No output schema declared.
No examples provided.
create_hitl ~172
Create a HITL (Human-in-the-Loop) config. Defines which messaging channels receive approval requests and the default timeout. Agent usage: After creating a HITL config, you must call request_hitl_authorization before it can be used with create_confirmation. For Telegram channels, use create_chat_id_discovery first to discover the user's chat ID, then include it in the channel config. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| channels | array | yes | Messaging channels for approval requests (telegram or whatsapp) |
| name | string | yes | Human-readable name for this HITL config |
| timeout_seconds | integer | – | Default timeout in seconds (60–86400, default: 3600) |
No output schema declared.
No examples provided.
create_identity_challenge ~159
Create a Proof-Me cross-channel identity challenge (CONFIRM) for an enrolled challenger. The account holder approves/denies on a channel different from the one the suspicious contact reached the challenger on. Agent usage: poll get_identity_challenge with the returned ID until it reaches a terminal state (active = confirmed, denied, expired). 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.
| Name | Type | Req | Description |
|---|---|---|---|
| challenger_id | string | yes | Enrolled challenger initiating the check |
| hitl_id | string | yes | HITL config that holds the challenger |
| suspicious_channel | string | – | Channel the suspicious contact reached the challenger on; defaults to the challenger channel |
No output schema declared.
No examples provided.
create_multi_channel_verification ~315
Create a multi-channel phone verification: one phone number challenged over several channels at once (OR / first-wins). The first channel the user completes wins, yields a single proof token, and cancels the losing siblings. Quota is charged per channel. Agent usage: the response includes a `group_id` (format vg_<hex>) and a `channels` array — each block carries a `deep_link` (WhatsApp/Telegram) or an `sms_message` to present to the user — pass the `deep_link` to render_auth_link. A block's `qr_text` is that same link already rendered as QR art, not an alternative address: print it verbatim inside a fenced code block or leave it out. Poll get_multi_channel_verification_status with the group_id to track completion and retrieve the proof token when a channel verifies. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| channels | array | yes | 1-4 unique channels attempted in parallel (first to complete wins) |
| client_metadata | object | – | Custom key-value metadata |
| external_user_id | string | – | Your application user ID for grouping verifications |
| identifier | string | yes | Phone number in E.164 format |
| proof_expiry_days | integer | – | Per-request proof expiry override in days (1-365) |
| type | string | yes | Asset type — only "phone" is supported |
No output schema declared.
No examples provided.
create_profile ~158
Create a new profile with optional display name, bio, avatar, business info, and theme settings. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| avatar_url | string | – | Avatar as base64 data URI or URL (~75KB limit) |
| bio | string | – | Profile bio |
| business_name | string | – | Business name |
| display_name | string | – | Display name |
| is_business | boolean | – | Whether this is a business profile |
| is_primary | boolean | – | Set as primary profile |
| is_public | boolean | – | Whether the profile is publicly visible |
| theme | object | – | Profile theme settings |
No output schema declared.
No examples provided.
create_session ~241
Create a new phone verification session. Returns deep_link, qr_code (base64 PNG), and qr_text (UTF-8 text QR for terminal display). Sessions provide a hosted verification flow with callbacks. Agent usage: After creating a session, pass the response's `deep_link` to render_auth_link so the user can open or scan it. Never hand `qr_text` to a link renderer — it is that link already rendered as QR art. Print it verbatim inside a fenced code block only when a real terminal needs the QR. Then use wait_for_session to poll until the session reaches a terminal state (verified, failed, or expired). 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.
| Name | Type | Req | Description |
|---|---|---|---|
| callback_url | string | – | URL to redirect after verification |
| channel | string | yes | Verification channel |
| external_user_id | string | – | Your application user ID |
| metadata | object | – | Custom key-value metadata |
| phone_number | string | yes | Phone number in E.164 format |
| template_id | string | – | Custom template ID |
No output schema declared.
No examples provided.
create_user_request ~220
Create a new verification request to ask another user to share verified assets. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| action_context | string | – | Additional context about why assets are needed |
| action_type | string | – | Purpose of the request (default: verification) |
| assets | array | yes | Asset type identifiers to request (e.g. email, phone, identity) |
| callback_url | string | – | Webhook URL for request status updates |
| expires_in_hours | integer | – | Hours until request expires (default: 24) |
| partial_ok | boolean | – | Whether partial asset sharing is acceptable (default: false) |
| public_profile_id | string | – | Public profile ID for branding |
| redirect_url | string | – | URL to redirect the subject after completing the request |
| reference_id | string | – | External reference ID for tracking |
| validity_requirement | string | – | Required validity level for shared assets |
No output schema declared.
No examples provided.
create_verification ~453
Create a new identity verification. Initiates a verification flow for an asset identifier (phone number, email, domain, social handle, wallet address, account, or Telegram bot). Agent usage: pass the asset `type`, the delivery `channel`, and the `identifier` (e.g. type "phone", channel "sms", identifier "+37060000000"; or type "email", channel "email", identifier "user@example.com"). The response carries a `challenge` object with the instruction for the chosen channel — except a `telegram_bot` verification made with a LIVE key, which the server completes on the spot and answers with `status: verified` plus a proof token and no challenge at all; with a `pk_test_` key that same call stays pending and does carry a challenge. On the messenger channels it also carries `challenge.deep_link` — pass THAT to render_auth_link to give the user a clickable link and a QR code. This endpoint returns no `qr_text` at all. For OTP-based flows (sms/email), the user receives a code — poll get_verification or use wait_for_verification to track completion. For Telegram/WhatsApp, the user clicks the deep link to verify. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| bot_token | string | – | Telegram bot token (required for channel "telegram_bot_token") |
| channel | string | yes | Verification channel (must match the asset type, e.g. sms/whatsapp/telegram for phone) |
| client_metadata | object | – | Custom key-value metadata |
| dns_provider | object | – | DNS provider credentials (required for channel "auto") |
| email_prefix | string | – | Mailbox prefix for domain email verification |
| external_user_id | string | – | Your application user ID for grouping verifications |
| identifier | string | yes | The asset identifier to verify (E.164 phone, email address, domain, handle, wallet address, ...) |
| proof_expiry_days | integer | – | Per-request proof expiry override in days (1-365) |
| type | string | yes | Asset type being verified |
No output schema declared.
No examples provided.
create_verification_request ~252
Create a multi-asset verification request. Allows verifying multiple assets (phone, email, domain, social, wallet, account, telegram_bot) in a single flow. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| action_context | object | – | Context displayed to user during verification |
| action_type | string | – | Purpose of the verification (default: verification) |
| assets | array | yes | Array of assets to verify (1-10) |
| callback_url | string | – | Webhook URL for status updates (HTTPS only) |
| expires_in | integer | – | Request expiry in seconds (default: 86400, max: 604800) |
| partial_ok | boolean | – | Allow partial completion (default: false) |
| proof_expiry_days | integer | – | Per-request proof expiry override in days (7, 30, 90, or 365) |
| public_profile_id | string | – | Public profile ID for branding |
| redirect_url | string | – | URL to redirect user after verification completes (HTTPS only) |
| reference_id | string | – | Your unique reference ID for this request |
No output schema declared.
No examples provided.
delete_circle ~84
Archive a Circle (soft delete — sets status to archived). It stops appearing in the default list but is recoverable via list_circles with status="archived". 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Circle ID to archive |
No output schema declared.
No examples provided.
delete_dns_credential ~77
Delete a stored DNS provider credential. Domains using this credential will need new credentials for automated verification. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | DNS credential ID to delete |
No output schema declared.
No examples provided.
delete_domain ~67
Remove a domain from the account. This cannot be undone. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Domain ID to delete |
No output schema declared.
No examples provided.
delete_hitl ~76
Delete (archive) a HITL config. Sets status to archived. Cannot be used for new confirmations after deletion. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | HITL config ID to delete |
No output schema declared.
No examples provided.
delete_hitl_keys ~76
Delete the encryption keypair from a HITL config. WARNING: Existing ciphertexts will become permanently unreadable. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| hitl_id | string | yes | HITL config ID |
No output schema declared.
No examples provided.
delete_profile ~67
Delete a profile by ID. Cannot delete the primary profile if it is the only one. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| profile_id | string | yes | Profile ID |
No output schema declared.
No examples provided.
delete_profile_template ~95
Delete a custom profile template, reverting to the default template for that channel and message type. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| channel | string | yes | Message channel |
| profile_id | string | yes | Profile ID |
| type | string | yes | Message type (e.g. verification_request, login_request) |
No output schema declared.
No examples provided.
delete_template ~84
Delete a custom template, reverting to the default template for that channel and message type. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| channel | string | yes | Message channel |
| message_type | string | yes | Message type (e.g. verification_request, login_request) |
No output schema declared.
No examples provided.
export_authorizations ~115
Export authorizations as CSV or JSON. Supports date range and status filtering. Maximum 10,000 records. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | – | Export format (default: json) |
| from | string | – | Start date filter (ISO 8601) |
| status | string | – | Filter by status |
| to | string | – | End date filter (ISO 8601) |
No output schema declared.
No examples provided.
export_data ~67
Export all account data (GDPR Article 20 - Right to Data Portability). Rate limited to 1 export per 24 hours. 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 present but exposes no named parameters.
No output schema declared.
No examples provided.
extend_request ~66
Extend the expiration time of a pending verification request. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Verification request ID to extend |
No output schema declared.
No examples provided.
get_2fa_status ~142
Check the status of a 2FA session by session ID. Returns whether the challenge has been completed, is pending, or has expired. Agent usage: Poll this after calling start_2fa. Check every few seconds. Terminal states: "verified" (proceed with protected operation), "expired" (restart with start_2fa). While "pending", the user has not yet entered their code. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| session_id | string | yes | 2FA session ID |
No output schema declared.
No examples provided.
get_add_email_status ~71
Check the status of an in-progress email addition by session ID. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| session_id | string | yes | Add-email session ID |
No output schema declared.
No examples provided.
get_add_phone_status ~76
Check the status of an in-progress phone addition by session ID. Poll until terminal state. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| session_id | string | yes | Add-phone session ID |
No output schema declared.
No examples provided.
get_api_key_usage ~144
Get per-API-key usage for a given key id: verification counts by type/channel/status, plus verification-request/confirmation/authorization totals, and attribution context (attribution_cutoff_at, attributed_fraction). Counts only — no recipient identifiers. Scoped to the authenticated account; an API-key caller may read only its own key. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| environment | string | – | Scope metrics to test or production data (default: production) |
| id | string | yes | The API key id to fetch usage for |
No output schema declared.
No examples provided.
get_asset ~69
Get a single verified asset by ID. Returns details including type, value, status, and verification timestamps. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Asset ID |
No output schema declared.
No examples provided.
What is the Proof Holdings MCP server?
Proof Holdings is an MCP server listed in the public MCP registry as holdings.proof/mcp-server. One API, all things verified, control, delegation, human approval, anti-impersonation. This page covers its npm package (@proof-holdings/mcp-server).
Is the Proof Holdings MCP server safe to use?
Proof Holdings scores 73 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 25 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Proof Holdings MCP server expose?
Proof Holdings exposes 176 tools: create_verification, get_verification, list_verifications, trigger_verification, submit_verification_code, and 171 more. Their descriptions and schemas cost roughly 22,440 tokens of context every time the server is loaded.
Is the Proof Holdings MCP server still maintained?
Proof Holdings is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the Proof Holdings MCP server under?
Proof Holdings declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.