# Proof Holdings (npm · @proof-holdings/mcp-server) One API, all things verified — control, delegation, human approval, anti-impersonation. - Trust score: 73/100 (medium) - Change this week: +4 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-09-25 ## Components - remote · `api.proof.holdings`: 35/100, [markdown](https://verifymcp.io/servers/holdings-proof-mcp-server/api.md), [page](https://verifymcp.io/servers/holdings-proof-mcp-server/api) - npm · `@proof-holdings/mcp-server`: 73/100 (this document), [markdown](https://verifymcp.io/servers/holdings-proof-mcp-server/proof-holdings-mcp-server.md), [page](https://verifymcp.io/servers/holdings-proof-mcp-server/proof-holdings-mcp-server) ## Channel facts - Registry: `npm` - Package: `@proof-holdings/mcp-server` - Version: `1.1.0` - Transport: `stdio` ## Trust breakdown 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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-09-25. - **Supply Chain Security**: 98/100 - No malware found by supply-chain analysis. - No known CVEs affecting this package version or its production dependencies. - No install/post-install scripts declared. - 42 of 126 dependencies flagged as unhealthy. - **Provenance & Transparency**: 45/100 - Source repository is publicly reachable at the declared URL. - Provenance check failed: no build-provenance attestation is published. - Clear OSI-approved license (MIT). - Actively maintained (last published 15 days ago). - Disclosure check failed: no security disclosure policy was found in the source repository. - **Schema Quality & AI Usability**: 74/100 - AI-judged instruction clarity (excellent). - 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. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 53/100 - Stability observed for 16 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 100/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 100% of tool parameters carry a description. - **Tool Safety**: 25/100 - 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. - 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. - An AI judge read all 177 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### 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. ### Claude ```bash claude mcp add holdings-proof-mcp-server -- npx -y @proof-holdings/mcp-server ``` ### Cursor ```json { "mcpServers": { "holdings-proof-mcp-server": { "command": "npx", "args": [ "-y", "@proof-holdings/mcp-server" ] } } } ``` ### VS Code ```json { "servers": { "holdings-proof-mcp-server": { "command": "npx", "args": [ "-y", "@proof-holdings/mcp-server" ] } } } ``` ### Codex ```bash codex mcp add holdings-proof-mcp-server -- npx -y @proof-holdings/mcp-server ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "holdings-proof-mcp-server": { "type": "local", "command": [ "npx", "-y", "@proof-holdings/mcp-server" ], "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add holdings-proof-mcp-server --command npx --arg -y --arg @proof-holdings/mcp-server ``` ### Hermes ```yaml mcp_servers: holdings-proof-mcp-server: command: "npx" args: ["-y", "@proof-holdings/mcp-server"] ``` ### Netclaw ```json { "McpServers": { "holdings-proof-mcp-server": { "Transport": "stdio", "Command": "npx", "Arguments": [ "-y", "@proof-holdings/mcp-server" ] } } } ``` ### Vellum ```bash assistant mcp add holdings-proof-mcp-server -t stdio -c npx -a -y @proof-holdings/mcp-server ``` ### Other ```json { "mcpServers": { "holdings-proof-mcp-server": { "command": "npx", "args": [ "-y", "@proof-holdings/mcp-server" ] } } } ``` ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-09-25 (score 73, +1) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-09-23 (score 72, +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. ### 2026-09-21 (score 71, +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. ### 2026-09-19 (score 70, +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. ### 2026-09-17 (score 69, +4) - [functional improvement] Stability: unverified → 0.27 ### 2026-09-09 (score 65) First indexed and scored. ## MCP tools (176) ### `create_verification` (~453 tokens) 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. Input parameters: - `bot_token` (string): Telegram bot token (required for channel "telegram_bot_token") - `channel` (string, required): 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, required): 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, required): Asset type being verified ### `get_verification` (~71 tokens) Get a verification by ID. Returns the full verification object including status, channel, and proof token if verified. 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 parameters: - `id` (string, required): Verification ID ### `list_verifications` (~105 tokens) List verifications with optional filters. Returns paginated results. 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 parameters: - `channel` (string): Filter by channel - `external_user_id` (string): Filter by external user ID - `limit` (integer): Items per page - `page` (integer): Page number - `status` (string): Filter by status ### `trigger_verification` (~62 tokens) Trigger a DNS/HTTP verification check for a pending domain verification. 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 parameters: - `id` (string, required): Verification ID ### `submit_verification_code` (~169 tokens) Submit an OTP/challenge code for a pending verification. Accepted ONLY where we delivered the code out-of-band to the party being verified: type "email", and type "domain" with channel "email". Any other pair answers 400 unsupported_for_type and completes elsewhere — use trigger_verification (POST /verifications/:id/verify) for a domain over dns/http/auto; a phone completes when the code reaches us FROM that number; social completes through its OAuth callback; a telegram_bot is already verified at creation. 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 parameters: - `code` (string, required): The OTP or challenge code to submit - `id` (string, required): Verification ID ### `resend_verification` (~66 tokens) Resend a verification message (email channel only). Generates and sends a new code. 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 parameters: - `id` (string, required): Verification ID ### `test_verify` (~73 tokens) Auto-complete a verification in test mode (pk_test_* API keys only). Useful for testing flows without real OTP delivery. 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 parameters: - `id` (string, required): Verification ID ### `list_verified_users` (~75 tokens) List verified users grouped by external_user_id. Shows all verifications per user. 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 parameters: - `limit` (integer): Items per page - `page` (integer): Page number ### `get_verified_user` (~67 tokens) Get a single verified user and their verifications by external user ID. 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 parameters: - `external_user_id` (string, required): The external user ID ### `start_domain_verification` (~111 tokens) Start a B2B domain verification. Creates a verification record and returns DNS/HTTP instructions for the customer to complete. 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 parameters: - `customer_id` (string): Customer identifier for B2B tracking - `domain` (string, required): Domain to verify (e.g. example.com) - `verification_method` (string): Verification method (default: manual_dns) ### `check_domain_verification` (~73 tokens) 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. Input parameters: - `id` (string, required): Domain verification ID ### `wait_for_verification` (~207 tokens) Poll a verification until it reaches a terminal state (verified, failed, expired, revoked, or cancelled). Uses exponential backoff (2s initial, 1.5x, 30s max) with jitter. A multi-channel verification that lost the race is "cancelled" and one whose proof was withdrawn is "revoked"; both are final, so the wait returns rather than polling on. 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 parameters: - `id` (string, required): Verification ID to poll - `timeout_seconds` (integer): Maximum wait time in seconds (default: 50, max: 300). Keep it under your MCP client's request timeout (the SDK default is 60 s) — a longer wait is cut off by the client while the server is still poll… ### `create_multi_channel_verification` (~315 tokens) 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_) 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. Input parameters: - `channels` (array, required): 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, required): Phone number in E.164 format - `proof_expiry_days` (integer): Per-request proof expiry override in days (1-365) - `type` (string, required): Asset type — only "phone" is supported ### `get_multi_channel_verification_status` (~112 tokens) Get the status of a multi-channel verification group by its group_id. Returns the aggregate status (pending/verified/expired), the winning_channel once one completes, per-channel statuses, and the proof token (with expires_at) when the group is verified. 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 parameters: - `group_id` (string, required): Multi-channel verification group ID (format vg_) ### `create_verification_request` (~252 tokens) 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. Input parameters: - `action_context` (object): Context displayed to user during verification - `action_type` (string): Purpose of the verification (default: verification) - `assets` (array, required): 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 ### `get_verification_request` (~68 tokens) Get a verification request by ID. Returns the request with all its asset verification statuses. 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 parameters: - `id` (string, required): Verification request ID ### `get_request_proofs` (~73 tokens) Get proof tokens for verified assets in a verification request. Returns proof tokens that can be used for offline verification. 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 parameters: - `id` (string, required): Verification request ID ### `list_verification_requests` (~117 tokens) List verification requests with optional filters. Returns paginated results. 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 parameters: - `limit` (integer): Items per page - `page` (integer): Page number - `reference_id` (string): Filter by reference ID - `status` (string): Filter by status. 'active' = live (not-yet-expired) pending or partial requests; persisted statuses are time-aware. ### `get_request_by_reference` (~66 tokens) Get a verification request by its reference ID (your unique identifier). 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 parameters: - `reference_id` (string, required): Your unique reference ID ### `cancel_verification_request` (~64 tokens) 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. Input parameters: - `id` (string, required): Verification request ID ### `wait_for_request` (~167 tokens) Poll a verification request until it reaches a terminal state (completed, expired, or cancelled). Uses exponential backoff (2s initial, 1.5x, 30s max) with jitter. 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 parameters: - `id` (string, required): Verification request ID to poll - `timeout_seconds` (integer): Maximum wait time in seconds (default: 50, max: 300). Keep it under your MCP client's request timeout (the SDK default is 60 s) — a longer wait is cut off by the client while the server is still poll… ### `validate_proof` (~119 tokens) Validate a proof token online. Checks the token signature, expiry, and revocation status against the server, and optionally that the proof is about the identifier you expect. Public endpoint — no API key required. Input parameters: - `identifier` (string): Optional: the identifier this proof should be about (phone, email, domain, ...). When supplied, a proof about anything else answers valid:false with reason "identifier_mismatch"; a proof of an encryp… - `proof_token` (string, required): The JWT proof token to validate ### `get_proof_status` (~110 tokens) Get the status of a proof by its public handle (ph_ctl_* / ph_dlg_*) or a verification ID. Returns whether the proof is active, suspended, expired, or revoked — a live proof reads "active". 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 parameters: - `id` (string, required): Public proof handle (ph_ctl_* / ph_dlg_*) or verification ID ### `revoke_proof` (~164 tokens) Revoke a proof by its public handle (ph_ctl_* / ph_dlg_*) or a verification ID — the same addresses get_proof_status takes. The proof token will no longer validate anywhere: the status endpoint, the public validator, the revocation list and the Token Status List all report it revoked. This action is irreversible. It revokes the PROOF only — the asset, consent or delegation the proof is about is not withdrawn. 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 parameters: - `id` (string, required): Public proof handle (ph_ctl_* / ph_dlg_*) or verification ID - `reason` (string): Reason for revocation ### `list_revoked_proofs` (~38 tokens) Get the revocation list for offline proof validation. Returns a signed list of all revoked proof IDs, cacheable for 5 minutes. ### `create_session` (~241 tokens) 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. Input parameters: - `callback_url` (string): URL to redirect after verification - `channel` (string, required): Verification channel - `external_user_id` (string): Your application user ID - `metadata` (object): Custom key-value metadata - `phone_number` (string, required): Phone number in E.164 format - `template_id` (string): Custom template ID ### `get_session` (~68 tokens) Get a session by ID. Returns the session status, verification details, and proof token if verified. 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 parameters: - `id` (string, required): Session ID ### `wait_for_session` (~165 tokens) Poll a session until it reaches a terminal state (verified, failed, or expired). Uses exponential backoff (2s initial, 1.5x, 30s max) with jitter. 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 parameters: - `id` (string, required): Session ID to poll - `timeout_seconds` (integer): Maximum wait time in seconds (default: 50, max: 300). Keep it under your MCP client's request timeout (the SDK default is 60 s) — a longer wait is cut off by the client while the server is still poll… ### `list_assets` (~99 tokens) List all verified assets for the authenticated user. Assets are verified identities (phones, emails, domains). 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 parameters: - `limit` (integer): Items per page - `page` (integer): Page number - `status` (string): Filter by status - `type` (string): Filter by asset type ### `get_asset` (~69 tokens) 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. Input parameters: - `id` (string, required): Asset ID ### `revoke_asset` (~71 tokens) Revoke a verified asset by ID. The asset will be marked as revoked and associated proofs will no longer validate. 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 parameters: - `id` (string, required): Asset ID ### `get_current_user` (~65 tokens) Get the current authenticated user. Returns account details, plan, and settings for the API key owner. 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. ### `list_auth_sessions` (~76 tokens) List all active authentication sessions for the current user. Shows session details including channel, user agent, and expiry. When called via API key, no session is marked as is_current. 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. ### `revoke_auth_session` (~84 tokens) Revoke a specific authentication session by ID. When called via JWT, cannot revoke the current session. When called via API key, any session can be revoked. 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 parameters: - `session_id` (string, required): Session ID to revoke ### `get_usage` (~93 tokens) Get usage metrics for the authenticated account. Shows verification counts, API calls, and quota usage. 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 parameters: - `months` (integer): Number of months of history - `period` (string): Month to query in YYYY-MM format (e.g. 2026-01) ### `get_platform_summary` (~127 tokens) Get a one-call account snapshot: quota with end-of-month projection, request health (pending/completed/expired counts + success rate), per-channel completion rates, HITL counts, and active API key count. The same data the dashboard home renders. The hitl_channels sub-object requires the hitl:read scope. 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 parameters: - `environment` (string): Scope request/channel/HITL metrics to test or production data (default: production) ### `get_settings` (~59 tokens) Get account settings including branding configuration (business name, logo, colors, support email, email theme). 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. ### `update_settings` (~59 tokens) Update account settings. Currently supports branding configuration. 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 parameters: - `branding` (object): Branding settings to update ### `export_data` (~67 tokens) 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. ### `search` (~160 tokens) Prefix-anchored global account search across six resource buckets (verification_requests, verifications, hitl, confirmations, authorizations, api_keys). Case-sensitive prefix match over indexed plaintext fields only; recipient identifiers are masked. Results are scoped to the authenticated account. 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 parameters: - `environment` (string): Scope results to test or production data (default: production) - `limit` (integer): Max results per bucket (default 10, max 25) - `q` (string, required): Prefix-anchored search query (minimum 3 characters) - `type` (string): Narrow the search to a single result bucket ### `get_self_api_key` (~109 tokens) Get the calling API key's own redacted metadata (id, name, key_prefix, environment, scopes, last_used_at, revoked_at, created_at) for agent self-inspection. Never returns the key hash or full secret. Requires API-key auth — a JWT session has no single-key context (returns 400 api_key_required). 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. ### `get_api_key_usage` (~144 tokens) 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. Input parameters: - `environment` (string): Scope metrics to test or production data (default: production) - `id` (string, required): The API key id to fetch usage for ### `list_templates` (~58 tokens) List all custom message templates for the authenticated account. Returns templates organized by 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. ### `get_default_templates` (~60 tokens) Get all default message templates. These are the built-in templates used when no custom template is set. 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. ### `get_template` (~88 tokens) Get a specific template by channel and message type. Returns the custom template if set, otherwise the default. 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 parameters: - `channel` (string, required): Message channel - `message_type` (string, required): Message type (e.g. verification_request, login_request) ### `update_template` (~142 tokens) Create or update a custom template for a specific channel and message type. Replaces the default template. 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 parameters: - `body` (string, required): Template body text with variable placeholders - `button_text` (string): Button text (email channel only) - `button_url_template` (string): Button URL template with placeholders - `channel` (string, required): Message channel - `message_type` (string, required): Message type (e.g. verification_request, login_request) - `subject` (string): Email subject line (email channel only) ### `delete_template` (~84 tokens) 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. Input parameters: - `channel` (string, required): Message channel - `message_type` (string, required): Message type (e.g. verification_request, login_request) ### `preview_template` (~121 tokens) Preview a template with sample data before saving. Shows how the message will look with placeholder variables filled in. 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 parameters: - `body` (string, required): Template body text - `button_text` (string): Button text - `button_url_template` (string): Button URL template - `channel` (string, required): Message channel - `message_type` (string, required): Message type - `subject` (string): Email subject line ### `render_template` (~85 tokens) Render a template with provided variables. Returns the fully rendered message content. 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 parameters: - `channel` (string, required): Message channel - `message_type` (string, required): Message type - `variables` (object): Variables to substitute into the template ### `get_webhook_stats` (~58 tokens) Get webhook delivery statistics including total deliveries, success/failure counts, and recent activity. 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. ### `list_webhook_deliveries` (~110 tokens) List webhook delivery attempts with pagination and filtering. Shows delivery status, response codes, and 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. Input parameters: - `event_type` (string): Filter by event type (e.g. verification.completed) - `limit` (integer): Items per page - `page` (integer): Page number - `status` (string): Filter by delivery status ### `get_webhook_delivery` (~70 tokens) Get details of a single webhook delivery attempt including request/response payloads and retry history. 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 parameters: - `id` (string, required): Webhook delivery ID ### `retry_webhook_delivery` (~74 tokens) Retry a failed webhook delivery. Creates a new delivery attempt with the same payload to the configured endpoint. 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 parameters: - `id` (string, required): Webhook delivery ID to retry ### `get_subscription` (~56 tokens) Get the current subscription details including plan, status, billing period, and usage limits. 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. ### `list_profiles` (~55 tokens) List all profiles for the authenticated account. Returns all profiles including primary and secondary. 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. ### `create_profile` (~158 tokens) 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. Input parameters: - `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 ### `get_profile` (~71 tokens) Get a specific profile by ID. Returns full profile details including theme, custom links, and verification display 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. Input parameters: - `profile_id` (string, required): Profile ID ### `update_profile` (~211 tokens) Update a profile by ID. Supports changing display info, theme, custom links, and verification display 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. Input parameters: - `avatar_url`: Avatar (base64 or URL, null to remove) - `bio` (string): Profile bio - `business_name` (string): Business name - `custom_links` (array): Custom links (max 20) - `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 - `profile_id` (string, required): Profile ID - `show_proof_channels` (boolean): Show proof channels on public profile - `show_verification_dates` (boolean): Show verification dates on public profile - `theme` (object): Profile theme settings ### `delete_profile` (~67 tokens) 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. Input parameters: - `profile_id` (string, required): Profile ID ### `set_primary_profile` (~69 tokens) Set a profile as the primary profile. The previous primary profile becomes secondary. 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 parameters: - `profile_id` (string, required): Profile ID to set as primary ### `list_profile_templates` (~70 tokens) List all templates for a profile. Returns templates organized by channel and message type, merged with defaults. 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 parameters: - `profile_id` (string, required): Profile ID ### `update_profile_template` (~162 tokens) Create or update a custom template for a specific profile, 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. Input parameters: - `body` (string, required): Template body text with variable placeholders - `button_text` (string): Button text (email channel only) - `button_url_template` (string): Button URL template with placeholders - `channel` (string, required): Message channel - `is_active` (boolean): Whether the template is active - `profile_id` (string, required): Profile ID - `subject` (string): Email subject line (email channel only) - `type` (string, required): Message type (e.g. verification_request, login_request) ### `delete_profile_template` (~95 tokens) 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. Input parameters: - `channel` (string, required): Message channel - `profile_id` (string, required): Profile ID - `type` (string, required): Message type (e.g. verification_request, login_request) ### `preview_profile_template` (~133 tokens) Preview a profile template with sample data before saving. Shows how the message will look with placeholder variables filled in. 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 parameters: - `body` (string, required): Template body text - `button_text` (string): Button text - `button_url_template` (string): Button URL template - `channel` (string, required): Message channel - `message_type` (string, required): Message type - `profile_id` (string, required): Profile ID - `subject` (string): Email subject line ### `update_profile_proofs` (~90 tokens) Update which verified assets (proofs) are displayed on a specific profile. Controls visibility, privacy masking, ordering, and labels. 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 parameters: - `profile_id` (string, required): Profile ID - `proofs` (array, required): Proofs to display on profile ### `get_my_profile` (~62 tokens) Get the current user's primary profile. Returns profile details, theme, custom links, and public proof display 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. ### `update_my_profile` (~167 tokens) Update the current user's primary profile. Supports display name, bio, avatar, theme, custom links, and verification display 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. Input parameters: - `avatar_url`: Avatar (HTTPS URL or base64 data URI, null to remove) - `bio` (string): Profile bio - `custom_links` (array): Custom links (max 20) - `display_name` (string): Display name - `is_public` (boolean): Whether the profile is publicly visible - `show_proof_channels` (boolean): Show proof channels - `show_verification_dates` (boolean): Show verification dates - `theme` (object): Profile theme settings ### `get_profile_assets` (~61 tokens) Get available verified assets that can be displayed on the user's profile. Returns assets eligible for public proof display. 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. ### `list_emails` (~55 tokens) List all email addresses associated with the authenticated account. 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. ### `remove_email` (~74 tokens) Remove an email address from the account by ID. May require 2FA verification for sensitive operations. 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 parameters: - `id` (string, required): Email record ID ### `set_primary_email` (~71 tokens) Set an email address as the primary email for the account. 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 parameters: - `id` (string, required): Email record ID to set as primary ### `start_add_email` (~79 tokens) Start adding a new email address. Sends an OTP code to the email. Returns a session ID to verify with. 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 parameters: - `email` (string, required): Email address to add ### `get_add_email_status` (~71 tokens) 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. Input parameters: - `session_id` (string, required): Add-email session ID ### `verify_email_otp` (~92 tokens) Submit the OTP code to verify an email addition. Completes the add-email flow if the code is correct. 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 parameters: - `code` (string, required): OTP code received via email - `session_id` (string, required): Add-email session ID ### `resend_email_otp` (~70 tokens) Resend the OTP code for an in-progress email addition. 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 parameters: - `session_id` (string, required): Add-email session ID ### `list_phones` (~55 tokens) List all phone numbers associated with the authenticated account. 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. ### `remove_phone` (~74 tokens) Remove a phone number from the account by ID. May require 2FA verification for sensitive operations. 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 parameters: - `id` (string, required): Phone record ID ### `set_primary_phone` (~71 tokens) Set a phone number as the primary phone for the account. 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 parameters: - `id` (string, required): Phone record ID to set as primary ### `start_add_phone` (~105 tokens) Start adding a new phone number. Uses reverse OTP: the system sends a message and the user replies. Returns a session ID, deep_link, qr_code (base64 PNG), and qr_text (UTF-8 text QR for terminal display). 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 parameters: - `channel` (string, required): Channel for phone verification ### `get_add_phone_status` (~76 tokens) 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. Input parameters: - `session_id` (string, required): Add-phone session ID ### `list_api_keys` (~64 tokens) List all API keys for the authenticated account. Returns key metadata (not the secret key values). 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. ### `create_api_key` (~294 tokens) 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. Input parameters: - `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 ### `revoke_api_key` (~148 tokens) Revoke an API key by ID. The key will immediately stop working. This action cannot be undone. Agent usage: This operation requires 2FA. Before calling, complete the 2FA flow: (1) call start_2fa with action_type "api_key_revoke", (2) wait for user to verify the code, (3) poll get_2fa_status until "verified", (4) then call revoke_api_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. Input parameters: - `id` (string, required): API key ID to revoke ### `regenerate_api_key` (~175 tokens) Regenerate an API key, issuing a new secret while keeping the same ID and settings. The old key stops working immediately. The new secret is returned ONLY in this response. Note: the secret will be visible in the AI conversation context. Agent usage: This operation requires 2FA. Before calling, complete the 2FA flow: (1) call start_2fa with action_type "api_key_regenerate", (2) wait for user to verify the code, (3) poll get_2fa_status until "verified", (4) then call regenerate_api_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. Input parameters: - `id` (string, required): API key ID to regenerate ### `start_2fa` (~442 tokens) Start a two-factor authentication challenge for a sensitive operation. Sends a verification code via the chosen channel. Returns a session ID, and for messaging channels: deep_link, qr_code (base64 PNG), and qr_text (UTF-8 text QR for terminal display). Agent usage — full 2FA flow: (1) Call start_2fa with the appropriate action_type and channel. (2) Present the challenge, and do NOT announce a message the server did not send: email is the ONLY channel it dispatches on. On telegram/whatsapp the user opens `deep_link` and sends the message themselves; on sms they send `sms_message` to a number from `sms_dids`; the response's own `instructions` field says which. On email, a 200 carrying `requires_email_selection: true` and `available_emails` means nothing was sent and no session exists — ask which address and call again with `email_id`. For telegram/whatsapp, pass `deep_link` to render_auth_link; for sms, show `sms_message`. Never hand `qr_text` to a link renderer — it is the link already rendered as QR art, so print it verbatim inside a fenced code block only when a real terminal needs the QR. (3) Poll get_2fa_status with the returned session_id until status is "verified" (the user enters the code on their device) or "expired". (4) If verified, proceed with the protected operation (e.g. create_api_key). If expired, inform the user and offer to restart. Typical channels: "telegram" or "email". For email, the user may receive a magic link instead of a code — the backend handles this automatically. 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 parameters: - `action_type` (string, required): The sensitive action requiring 2FA - `channel` (string, required): Channel to receive the verification code - `email_id` (string): Specific email ID for email channel (optional) ### `get_2fa_status` (~142 tokens) 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. Input parameters: - `session_id` (string, required): 2FA session ID ### `verify_2fa` (~89 tokens) Submit a verification code to complete a 2FA challenge. Rate limited to 10 attempts per minute. 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 parameters: - `code` (string, required): Verification code - `session_id` (string, required): 2FA session ID ### `verify_2fa_magic_link` (~90 tokens) Complete a 2FA challenge using a magic link token (received via email). No code submission needed — the token itself is the proof. 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 parameters: - `token` (string, required): Magic link token from the verification email ### `wait_for_2fa` (~252 tokens) Poll a 2FA session until the user completes the challenge. Uses exponential backoff (2s initial, 1.5x, 30s max) with jitter. Agent usage: Call this after start_2fa with the returned session_id. Terminal states: "verified" (challenge completed — proceed with the protected operation), "expired" (offer to restart with start_2fa). Before polling, present start_2fa's challenge: pass its `deep_link` to render_auth_link on telegram/whatsapp, or show its `sms_message` on sms. 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 parameters: - `session_id` (string, required): 2FA session ID from start_2fa - `timeout_seconds` (integer): Maximum wait time in seconds (default: 50, max: 600). Keep it under your MCP client's request timeout (the SDK default is 60 s) — a longer wait is cut off by the client while the server is still poll… ### `list_domains` (~59 tokens) List all domains for the authenticated account. Returns domain metadata including verification status. 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. ### `add_domain` (~107 tokens) 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. Input parameters: - `domain` (string, required): 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 ### `get_domain` (~73 tokens) Get details of a specific domain by ID, including verification status, DNS records, and provider connections. 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 parameters: - `id` (string, required): Domain ID ### `delete_domain` (~67 tokens) 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. Input parameters: - `id` (string, required): Domain ID to delete ### `verify_domain` (~71 tokens) Trigger domain verification. Checks DNS records or other verification method to confirm domain ownership. 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 parameters: - `id` (string, required): Domain ID to verify ### `connect_cloudflare` (~99 tokens) 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. Input parameters: - `api_token` (string, required): Cloudflare API token with DNS edit permissions - `id` (string, required): Domain ID ### `connect_godaddy` (~109 tokens) 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. Input parameters: - `api_key` (string, required): GoDaddy API key - `api_secret` (string, required): GoDaddy API secret - `id` (string, required): Domain ID ### `connect_dns_provider` (~102 tokens) 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. Input parameters: - `credentials` (object, required): Provider-specific credential key-value pairs - `id` (string, required): Domain ID - `provider` (string, required): DNS provider identifier ### `add_verification_provider` (~104 tokens) 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. Input parameters: - `credentials` (object, required): Provider-specific credential key-value pairs - `id` (string, required): Domain ID - `provider` (string, required): DNS provider identifier ### `get_dns_providers` (~62 tokens) Get metadata for all supported DNS providers, including required credential fields and documentation links. 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. ### `verify_domain_with_credentials` (~74 tokens) Verify a pending domain using previously stored DNS credentials. Use when credentials are already connected. 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 parameters: - `id` (string, required): Domain ID to verify ### `check_domain_credentials` (~79 tokens) 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. Input parameters: - `id` (string, required): Domain ID to check credentials for ### `start_domain_email_verification` (~95 tokens) Start domain verification via corporate email. Sends a verification code to a standard admin email address at the domain. 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 parameters: - `email_prefix` (string): Email prefix to send verification to (default: admin) - `id` (string, required): Domain ID ### `confirm_domain_email_code` (~82 tokens) 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. Input parameters: - `code` (string, required): Verification code from the email - `id` (string, required): Domain ID ### `resend_domain_email` (~84 tokens) Resend the domain verification email. Rate limited to 3 requests per minute. 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 parameters: - `email_prefix` (string): Email prefix to resend verification to - `id` (string, required): Domain ID ### `setup_domain_email` (~91 tokens) Set up email sending for a verified domain. Configures the domain for sending verification emails from a custom 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. Input parameters: - `from_email` (string): Custom from email address for the domain - `id` (string, required): Domain ID ### `check_domain_email_status` (~71 tokens) 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. Input parameters: - `id` (string, required): Domain ID ### `list_dns_credentials` (~64 tokens) List all stored DNS provider credentials for the authenticated account. Returns credential metadata (not secret values). 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. ### `create_dns_credential` (~103 tokens) 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. Input parameters: - `credentials` (object, required): Provider-specific credential key-value pairs - `provider` (string, required): DNS provider identifier (e.g. cloudflare, route53, digitalocean) ### `delete_dns_credential` (~77 tokens) 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. Input parameters: - `id` (string, required): DNS credential ID to delete ### `list_my_requests` (~54 tokens) List verification requests created by the authenticated user. 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. ### `list_incoming_requests` (~58 tokens) List incoming verification requests where the authenticated user is the subject. 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. ### `create_user_request` (~220 tokens) 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. Input parameters: - `action_context` (string): Additional context about why assets are needed - `action_type` (string): Purpose of the request (default: verification) - `assets` (array, required): 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 ### `claim_request_assets` (~64 tokens) 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. Input parameters: - `id` (string, required): Verification request ID ### `cancel_user_request` (~69 tokens) 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. Input parameters: - `id` (string, required): Verification request ID to cancel ### `extend_request` (~66 tokens) 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. Input parameters: - `id` (string, required): Verification request ID to extend ### `share_request_email` (~67 tokens) Send an email notification to the subject of a 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. Input parameters: - `id` (string, required): Verification request ID ### `start_user_domain_verification` (~98 tokens) Start a self-service domain verification session. The user proves ownership of a domain via DNS or HTTP challenge. 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 parameters: - `channel` (string): Verification channel (default: dns) - `domain` (string, required): Domain name to verify (e.g. example.com) ### `get_user_domain_verification_status` (~74 tokens) Get the current status of a domain verification session, including challenge details. 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 parameters: - `session_id` (string, required): Domain verification session ID ### `check_user_domain_verification` (~77 tokens) 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. Input parameters: - `session_id` (string, required): Domain verification session ID ### `claim_username` (~91 tokens) 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. Input parameters: - `username` (string, required): Username to claim (3-30 chars, alphanumeric and underscores) ### `update_public_proofs` (~83 tokens) Update which verified proofs are visible on the user's public profile, including visibility, masking, and display order. 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 parameters: - `proofs` (array, required): Array of proof display configurations (max 50) ### `create_authorization` (~237 tokens) 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. Input parameters: - `bsuid` (string): WhatsApp Business-Scoped User ID (alternative to phone for WhatsApp channel) - `business_name` (string, required): Business name displayed to user during authorization - `business_profile_id` (string): Public profile ID for branding - `channel` (string, required): Channel for sending confirmations - `expires_in` (integer): Expiry in seconds (max 90 days, default 90 days) - `hitl_id` (string, required): HITL configuration ID to link this authorization to - `phone` (string, required): Target phone number in E.164 format (e.g., +15551234567) - `recipient` (string, required): Channel-specific recipient identifier (chat_id for Telegram, phone/BSUID for WhatsApp) - `scope` (string): Authorization scope (default: confirmations) ### `get_authorization` (~68 tokens) Get an authorization by ID. Returns the current state of the authorization including status and usage statistics. 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 parameters: - `id` (string, required): Authorization ID ### `list_authorizations` (~103 tokens) List authorizations with optional filters. Returns paginated results. 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 parameters: - `channel` (string): Filter by channel - `limit` (integer): Items per page - `page` (integer): Page number - `phone` (string): Filter by phone number - `status` (string): Filter by authorization status ### `revoke_authorization` (~86 tokens) Revoke an active or pending authorization. Only authorizations with status "active" or "pending" can be revoked. 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 parameters: - `id` (string, required): Authorization ID to revoke - `reason` (string): Reason for revocation ### `export_authorizations` (~115 tokens) 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. Input parameters: - `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) ### `create_confirmation` (~416 tokens) 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. Input parameters: - `hitl_id` (string, required): HITL config ID whose channels will receive the approval request - `message` (string, required): Human-readable description of what needs approval - `proof_expiry_days` (integer): Per-request proof expiry override in days (7, 30, 90, or 365) ### `get_confirmation` (~67 tokens) Get a confirmation by ID. Returns the full confirmation including status, response, and proof token. 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 parameters: - `id` (string, required): Confirmation ID ### `list_confirmations` (~103 tokens) List confirmations with optional filters. Returns paginated results with status and HITL config filtering. 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 parameters: - `hitl_id` (string): Filter by HITL config ID - `limit` (integer): Items per page - `page` (integer): Page number - `status` (string): Filter by confirmation status ### `get_confirmation_approval_link` (~75 tokens) Generate a fresh approval link for a pending confirmation. The link expiry inherits the confirmation timeout. Only works for pending confirmations. 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 parameters: - `id` (string, required): Confirmation ID ### `wait_for_confirmation` (~291 tokens) Poll a confirmation until the approver responds. Uses exponential backoff (2s initial, 1.5x, 30s max) with jitter. Agent usage: Call this after create_confirmation with the returned confirmation ID. Terminal states: "approved" (action authorized — check the proof_token), "denied" (action rejected). While "pending", the approver has not yet responded. This poll returns no link — the approval request is delivered to the approver's own channel. If the approver needs one anyway, call get_confirmation_approval_link for a fresh `approval_url`; it needs the confirmation to be still pending — the state this tool waits in — and also refuses once `timeout_at` has passed, so a long wait can outlive the link even while the status has not moved. 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 parameters: - `id` (string, required): Confirmation ID from create_confirmation - `timeout_seconds` (integer): Maximum wait time in seconds (default: 50, max: 600). Keep it under your MCP client's request timeout (the SDK default is 60 s) — a longer wait is cut off by the client while the server is still poll… ### `create_hitl` (~172 tokens) 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. Input parameters: - `channels` (array, required): Messaging channels for approval requests (telegram or whatsapp) - `name` (string, required): Human-readable name for this HITL config - `timeout_seconds` (integer): Default timeout in seconds (60–86400, default: 3600) ### `get_hitl` (~70 tokens) Get a HITL config by ID. Returns the config including channels, timeout, and 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. Input parameters: - `id` (string, required): HITL config ID ### `list_hitls` (~100 tokens) List HITL configs with optional filters. Returns paginated results. 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 parameters: - `environment` (string): Filter by environment (production or test) - `limit` (integer): Items per page - `page` (integer): Page number - `status` (string): Filter by status (active or archived) ### `update_hitl` (~103 tokens) Update a HITL config. Can change name, channels, or timeout. 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 parameters: - `channels` (array): Updated channels - `id` (string, required): HITL config ID - `name`: New name (null to clear) - `timeout_seconds` (integer): Updated timeout in seconds (60–86400) ### `delete_hitl` (~76 tokens) 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. Input parameters: - `id` (string, required): HITL config ID to delete ### `request_hitl_authorization` (~313 tokens) Request authorization for a HITL config. Sends consent requests to all configured channels (Telegram/WhatsApp). Users must approve before confirmations can be sent. Agent usage: This must be completed before create_confirmation will work for this HITL config. The consent request is DELIVERED to each channel — the response carries no link to show. It returns `authorizations` — one entry per resolved recipient, each with its `channel`, `recipient`, `authorization_id` and `status` — plus a `message`. Read the entries rather than assuming: `status: 'pending'` means consent was just sent and the user must approve in Telegram/WhatsApp itself, while `status: 'active'` means that recipient had already authorized and nothing was sent to them. An EMPTY array does not mean everyone is authorized — it means no recipient could be resolved at all (usually a HITL config bound to a missing or inactive circle, or channels whose recipient is blank), so nobody was asked and waiting for an approval would hang forever. Do not relay `message` on that branch: it reads 'All channels already have active or pending authorizations', which is exactly the wrong conclusion. Read the array. After requesting, you can proceed once the user confirms they have approved. 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 parameters: - `id` (string, required): HITL config ID to request authorization for ### `create_chat_id_discovery` (~191 tokens) 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. ### `poll_chat_id_discovery` (~84 tokens) Poll a chat ID discovery token. Returns the discovered Telegram chat ID, user ID, and username once the user interacts with the bot. 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 parameters: - `token` (string, required): Discovery token from create_chat_id_discovery ### `wait_for_chat_id_discovery` (~245 tokens) Poll a chat ID discovery token until the user interacts with the Telegram bot. Uses exponential backoff (2s initial, 1.5x, 30s max) with jitter. Agent usage: Call this after create_chat_id_discovery. Present the discovery response's `deep_link` with render_auth_link first, then poll with the returned token. Terminal states: "completed" (chat_id discovered — use it when creating a HITL config with a Telegram channel), "expired". While "pending", the user has not yet opened the Telegram link. 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 parameters: - `timeout_seconds` (integer): Maximum wait time in seconds (default: 50, max: 600). Keep it under your MCP client's request timeout (the SDK default is 60 s) — a longer wait is cut off by the client while the server is still poll… - `token` (string, required): Discovery token from create_chat_id_discovery ### `get_hitl_keys` (~83 tokens) Get the encryption keypair for a HITL config. Returns public key, encrypted private key, KDF salt, and key ID (kid). 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 parameters: - `hitl_id` (string, required): HITL config ID ### `upload_hitl_keys` (~173 tokens) Upload an encryption keypair for a HITL config. The server validates the RSA-4096 public key and computes the key ID. Note: the encrypted_private_key is already encrypted client-side with the user's password — the server never sees the password. 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 parameters: - `encrypted_private_key` (string, required): JSON-serialized encrypted private key envelope (PBKDF2-SHA256+AES-256-GCM) - `hitl_id` (string, required): HITL config ID - `kdf_salt` (string, required): Base64url-encoded PBKDF2 salt - `public_key` (string, required): PEM-encoded RSA-4096 SPKI public key ### `delete_hitl_keys` (~76 tokens) 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. Input parameters: - `hitl_id` (string, required): HITL config ID ### `add_challenger` (~184 tokens) 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. Input parameters: - `channel` (string, required): Messenger channel the challenger uses - `hitl_id` (string, required): HITL config ID to enroll the challenger on - `name` (string, required): Display name of the challenger - `whatsapp_phone` (string): E.164 phone with country code (required for the whatsapp channel) ### `list_challengers` (~67 tokens) List the Proof-Me challengers enrolled on a HITL 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. Input parameters: - `hitl_id` (string, required): HITL config ID ### `remove_challenger` (~88 tokens) Remove a Proof-Me challenger from a HITL config. Removing the last challenger disables Proof-Me on the 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. Input parameters: - `challenger_id` (string, required): Challenger ID to remove - `hitl_id` (string, required): HITL config ID ### `invite_challenger` (~107 tokens) Mint a single-use Proof-Me enrollment invite for a challenger. Returns Telegram + WhatsApp deep links and a QR code; the challenger taps the channel-matched link to bind their messenger identity to the 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. Input parameters: - `challenger_id` (string, required): Challenger ID to invite - `hitl_id` (string, required): HITL config ID ### `trigger_drill` (~103 tokens) Fire an on-demand Proof-Me drill against one enrolled challenger — a real cross-channel identity challenge carrying the scheduled-safety-check label. 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. Input parameters: - `challenger_id` (string, required): Challenger ID to drill - `hitl_id` (string, required): HITL config ID ### `create_identity_challenge` (~159 tokens) 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. Input parameters: - `challenger_id` (string, required): Enrolled challenger initiating the check - `hitl_id` (string, required): HITL config that holds the challenger - `suspicious_channel` (string): Channel the suspicious contact reached the challenger on; defaults to the challenger channel ### `get_identity_challenge` (~83 tokens) Get a Proof-Me identity challenge by ID. Returns status, the channel the CONFIRM ran on, and the proof token once confirmed. Poll this for resolution. 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 parameters: - `id` (string, required): Identity challenge ID ### `create_circle` (~190 tokens) 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. Input parameters: - `members` (array): Initial members (name + optional declared channels) - `name` (string, required): 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 ### `list_circles` (~148 tokens) List Circles with optional filters. Archived Circles are excluded by default; pass status="archived" to surface them. Returns paginated results. 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 parameters: - `environment` (string): Filter by environment (production or test) - `limit` (integer): Items per page (default 20, max 100) - `page` (integer): Page number (default 1) - `profile_id` (string): Filter by bound public profile (sub-account) - `status` (string): Filter by status (archived excluded unless requested) ### `get_circle` (~81 tokens) Get a Circle by ID. Returns the Circle including its members and per-member channel presence booleans (an identifier is NEVER returned — SEC-PM-006). 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 parameters: - `id` (string, required): Circle ID ### `update_circle` (~82 tokens) Update a Circle's name. Only the display name is mutable — the profile/identity binding is create-only. 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 parameters: - `id` (string, required): Circle ID - `name` (string): New name for the Circle ### `delete_circle` (~84 tokens) 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. Input parameters: - `id` (string, required): Circle ID to archive ### `add_circle_member` (~152 tokens) 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. Input parameters: - `id` (string, required): Circle ID to add the member to - `name` (string, required): Display name of the member - `whatsapp_phone` (string): E.164 WhatsApp phone with a leading + (optional, declared) ### `list_circle_members` (~87 tokens) List a Circle's members. Each member carries channel-presence booleans only (has_telegram / has_whatsapp) — an identifier is NEVER returned (SEC-PM-006). 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 parameters: - `id` (string, required): Circle ID ### `invite_circle_member` (~101 tokens) Mint a single-use enrollment invite for a Circle member. Returns Telegram + WhatsApp deep links and a QR code; the member taps the channel-matched link to bind their messenger identity to the Circle. 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 parameters: - `id` (string, required): Circle ID - `member_id` (string, required): Member ID to invite ### `create_circle_member_drill` (~107 tokens) 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. Input parameters: - `id` (string, required): Circle ID - `member_id` (string, required): Member ID to drill ### `remove_circle_member` (~85 tokens) Remove a member from a Circle. Deletes the member's channels and revokes any live authorizations that routed through them. 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 parameters: - `id` (string, required): Circle ID - `member_id` (string, required): Member ID to remove ### `add_circle_member_channel` (~143 tokens) 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. Input parameters: - `channel` (string, required): Channel type (telegram or whatsapp) - `id` (string, required): Circle ID - `identifier` (string, required): Telegram chat id, or E.164 WhatsApp phone with a leading + - `member_id` (string, required): Member ID to add the channel to ### `list_circle_member_channels` (~92 tokens) List a Circle member's channels. Returns channel metadata only (channel, status, verified_at) — an identifier is NEVER returned (SEC-PM-006). 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 parameters: - `id` (string, required): Circle ID - `member_id` (string, required): Member ID ### `remove_circle_member_channel` (~93 tokens) Remove a channel from a Circle member. Removing the last channel is allowed (the member simply becomes unreachable). 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 parameters: - `channel_id` (string, required): Channel ID to remove - `id` (string, required): Circle ID - `member_id` (string, required): Member ID ### `create_delegation` (~276 tokens) 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. Input parameters: - `control_proof` (string, required): Public handle (ph_ctl_<32 hex>) of YOUR active domain control proof - `delegate` (object, required): The typed artifact being authorized - `expires_in` (integer): Lifetime in seconds (must not exceed the control proof's remainder) - `scope` (array, required): 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. ### `list_delegations` (~224 tokens) List your own delegations with optional filters. Each item carries the DERIVED effective_status/is_valid beside its stored status — read effective_status, since status records only whether the owner revoked the delegation themselves, so a delegation still reads active there after its domain control proof was revoked, suspended or expired, and after its OWN lifetime ran out. effective_status accounts for all of those: it reports expired once either lifetime has passed, whichever is earlier. Tokens are not included in the list — use get_delegation for the stored token. There is no public enumeration of third-party delegations. 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 parameters: - `limit` (integer): Items per page - `page` (integer): Page number - `status` (string): Filter by the delegation's OWN stored status (active|revoked). Does NOT filter the derived effective_status — status=active still returns delegations whose control proof died, and ones that simply ra… ### `get_delegation` (~137 tokens) Get one of your delegations by Mongo id or ph_dlg_* handle. Returns the stored publishable token plus the DERIVED effective_status/is_valid — the delegation is only as live as the control proof it stands on (a revoked, suspended or expired domain proof invalidates it) and never outlives its own expires_at, whichever comes first. 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 parameters: - `id` (string, required): Delegation ID (24-hex Mongo id or ph_dlg_<32 hex> handle) ### `revoke_delegation` (~174 tokens) Revoke ONE delegation. The domain control proof and sibling delegations stay valid; the revocation is mirrored into the proof registry so the CRL, status list and public status lookup all see it. Idempotent: a repeat revoke answers success with the same body, both here and through revoke_proof with the ph_dlg_ handle — unlike a PROOF, where a repeat answers already_revoked. The result carries the DERIVED effective_status/is_valid beside the stored 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. Input parameters: - `id` (string, required): Delegation ID (24-hex Mongo id or ph_dlg_<32 hex> handle) - `reason` (string): Reason for revocation ### `verify_delegation` (~519 tokens) Verify a Proof of Delegation — the attestation that a domain authorized a specific agent artifact. Pass either the artifact's card (MCP server.json / A2A agent card) or a raw delegation token, PLUS two facts you established yourself: the artifact identity you resolved (the package you are installing, the endpoint you are calling) and the domain you expect to stand behind it. Both are required — a token can be copied into someone else's card, and any domain owner can mint a valid delegation naming someone else's package, so a verdict without both pins would mean 'some domain said something about some artifact'. WHERE THE IDENTITY MAY COME FROM: it is the artifact you are acting on, and never a value read from inside the artifact you are checking. A name in the artifact's own package.json, card or manifest is self-declared and editable by whoever ships it, so checking it against the delegation compares the artifact with itself. Resolve it afresh at call time instead of reusing a value from earlier in this conversation, which may already be stale. When no independently resolvable identity exists — a local or unpublished artifact — you have nothing to compare against, and that is the honest answer: report it rather than a mismatch, because a mismatch here reads as an accusation against the domain named in the delegation. The verifier walks signature → principal → delegate → revocation status, including the cascade down to the domain control proof. Requires no API key. What a verified result means: the expected domain's controller authorized this artifact for these scopes — NOT that the artifact is safe, audited or endorsed. Input parameters: - `card` (object): The MCP server card or A2A agent card to read the delegation from - `check_status` (boolean): Default true. When false the signature and claims are checked but revocation is NOT — treat the result as "not revoked-checked", never as "not revoked". - `delegate` (object, required): The artifact identity you resolved independently. Required: this comparison is what defeats a copied token. - `expected_principal` (string, required): Required. The domain you expect to have authorized this artifact (e.g. postmarkapp.com) — an issuer binds the artifact to nothing, so any domain owner can mint a valid delegation for someone else's p… - `required_scopes` (array): Capability scopes the delegation must grant - `token` (string): A raw delegation token, when you already have it instead of a card ### `verify_delegations` (~353 tokens) Batch-verify up to 50 Proof of Delegation artifacts in one call — the inventory half of the checker (h-proof-checker-mcp): re-check everything you already trust instead of one verify_delegation call per artifact. Each item takes the same shape verify_delegation requires (card XOR token, delegate, expected_principal, optional required_scopes) and follows the same rule about where identity comes from: each `delegate` is the artifact you are acting on, never a value read from inside the artifact you are checking, and resolved afresh at call time. Items are verified INDEPENDENTLY — no cross-item state, nothing persisted, one item failing never affects another item's result. This tool does NOT discover what you have installed and does NOT fetch anything on your behalf: it verifies material you already hold, the same trust boundary verify_delegation draws. Revocation is always checked (there is no check_status:false here — the point of a batch re-check is to see what changed since you last looked). Each result carries an `outcome`: confirmed_valid (verified), confirmed_invalid (a genuine negative verdict — revoked, expired, mismatched, malformed, and similar), no_claim_found (the artifact publishes no delegation at all — an absence, never an accusation), or unconfirmed (we could not reach the issuer or otherwise get a confident answer right now — NEVER treat this as a bad verdict). Requires no API key. `checked_at` on each result is the moment THAT item's own check completed, not one timestamp shared across the call. Input parameters: - `items` (array, required): 1-50 artifacts to verify in this call, each shaped like a verify_delegation call ### `start_login` (~470 tokens) Start a login session by sending an authentication challenge to the user's chosen channel (Telegram, WhatsApp, SMS, or email). Returns a session ID and, FOR TELEGRAM AND WHATSAPP ONLY, deep_link, qr_code (base64 PNG) and qr_text (UTF-8 text QR for terminal display); on sms it returns sms_message with sms_dids instead, and on email nothing to display. Agent usage: (1) Call start_login with the desired channel and phone_number (for SMS) or email (for email). (2) Present the challenge, and WHICH FIELD depends on the channel. On telegram/whatsapp pass `deep_link` to render_auth_link, which prints the clickable link and a QR code; in a chat client the link is what the user acts on, since they are usually on the same machine. On sms `deep_link` is an EMPTY STRING and render_auth_link will reject it — show `sms_message` and let the user pick a number from `sms_dids`. `suggested_region` is always set, but the matching ENTRY in `sms_dids` may be missing (europe and israel appear only when a number is configured) or present with an empty `did`, so offer that region first only when `sms_dids[suggested_region]` exists and carries a number, and otherwise offer whatever the object does. On email there is no link either — check `email_sent` before telling the user to open their mail: on a delivery failure it is false and `email_error` says why, and waiting on an inbox nothing reached is the wrong next step. Never hand `qr_text` to a link renderer — it is the link already rendered as QR art, so print it verbatim inside a fenced code block or not at all, because its rows stop scanning the moment one wraps or a blank line lands between them. (3) Call wait_for_login with the returned session ID to poll until the user completes authentication. Terminal states: "verified" (login succeeded), "failed", "expired". Input parameters: - `channel` (string, required): Authentication channel - `email` (string): Email address (required for email channel) - `phone_number` (string): Phone number in E.164 format (required for SMS channel) ### `wait_for_login` (~230 tokens) Poll a login session until the user completes authentication. Uses exponential backoff (2s initial, 1.5x, 30s max) with jitter. Agent usage: Call this after start_login with the returned session ID. Terminal states: "verified" (login succeeded — this server keeps the session for this connection and signs your own account records with it: emails, phones, domains, API keys, 2FA, DNS credentials, verification requests, your public profile's username and proof list), "failed", "expired". A result with status "pending" means the wait ran out before the user finished — call this tool again with the same id. Input parameters: - `id` (string, required): Auth session ID from start_login - `timeout_seconds` (integer): Maximum wait time in seconds (default: 50, max: 600). Keep it under your MCP client's request timeout (the SDK default is 60 s) — a longer wait is cut off by the client while the server is still poll… ### `create_account` (~445 tokens) 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. Input parameters: - `channel` (string, required): Authentication channel the user will verify through - `email` (string): Email address. Required for email channel. - `phone_number` (string): E.164 phone number. Required for SMS channel (determines DID routing). ### `send_account_email` (~269 tokens) Deliver the verification email for an account-bootstrap session created with channel "email". Public endpoint (no API key required). Why this is a separate call: create_account deliberately sends NOTHING. A message from proof.holdings arriving in someone's inbox is an act with a person on the other end, so it takes an explicit second step rather than being a side effect of creating a session. ASK THE USER to confirm the address is theirs before calling this — do not call it automatically after create_account. The other channels (telegram, whatsapp, sms) never need this: the user sends the first message themselves (reverse OTP), so nothing is dispatched to them at all. One session sends at most one email, including under concurrent calls. A repeat answers 410 already_sent, which means the material backing the send is gone: usually because the email went out, occasionally because an attempt was interrupted mid-send and nothing was delivered. Do not tell the user a message was sent on the strength of a 410 — create a new session instead. (A session the recipient cancelled via the decline link, or an expired one, answers 404, not 410.) If delivery fails the response carries email_sent=false and the call can be retried. Input parameters: - `id` (string, required): Account session id from create_account ### `wait_for_account_creation` (~223 tokens) Poll an account-bootstrap session until the user completes verification. Uses exponential backoff (2s initial, 1.5x, 30s max) with jitter. Agent usage: Call this after create_account with the returned session id. Terminal states: "verified" (this server keeps the session for this connection; the `user_id` field in the terminal body identifies the authenticated user), "expired". A result with status "pending" means the wait ran out before the user finished — call this tool again with the same id. Works identically whether the underlying flow created a new User or logged in an existing one. Input parameters: - `id` (string, required): Account session id from create_account - `timeout_seconds` (integer): Maximum wait time in seconds (default: 50, max: 600). Keep it under your MCP client's request timeout (the SDK default is 60 s) — a longer wait is cut off by the client while the server is still poll… ### `start_2fa_for_action` (~646 tokens) Start a 2FA challenge that grants the authenticated user permission to perform a sensitive action. The 2FA must complete on a channel DIFFERENT from the user's last login channel (the backend enforces this). On success a grant is stored keyed by the user id and action_type; middleware on the protected endpoint reads the grant and allows the mutation. Destructive action types (api_key_create, api_key_revoke, api_key_regenerate, api_key_view, account_delete, phone_remove, email_remove, revocation_bulk) are capped at 5min TTL and forced single-use by server policy. Configuration scopes (settings_write, profile_update, templates_write) allow up to 24h TTL and caller-chosen single_use — useful for agents making multiple settings mutations in one session. Agent usage: (1) Attempt the sensitive call; if you get `403 2fa_required` note the `action_type`. (2) Call start_2fa_for_action with that action_type and a channel different from the login channel. (3) Present the challenge: on telegram/whatsapp pass `deep_link` to render_auth_link; on sms show `sms_message` and the number to send it to; on email check the response first: with more than one verified email and no `email_id` given, it answers 200 with `requires_email_selection: true` and `available_emails` — NO session was started and nothing was sent, so ask the user which address and call again with `email_id` rather than telling them to open a mailbox. Never hand `qr_text` to a link renderer — it is the link already rendered as QR art. Print it verbatim inside a fenced code block only when a real terminal needs the QR. (4) Call wait_for_2fa until the session is verified. (5) Retry the original sensitive call. 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 parameters: - `action_type` (string, required): The sensitive action the 2FA grant will authorize. Destructive scopes (api_key_*, account_delete, phone_remove, email_remove, revocation_bulk) are capped at 5 min TTL + forced single-use. Configurati… - `channel` (string, required): Channel for the 2FA challenge — must differ from the user's last login channel - `email_id` (string): Optional: specific UserEmail id for email-channel 2FA - `phone_id` (string): Optional: specific UserPhone id for phone-channel 2FA - `single_use` (boolean): Whether the grant is consumed on first use. Server forces true for destructive action types. Defaults to true. - `ttl_seconds` (integer): Requested grant lifetime in seconds. Server caps to 300s for destructive action types, 86400s for configuration scopes. Defaults to 300 if omitted. ### `render_auth_link` (~278 tokens) Render an authorization or verification URL as a clickable link followed by a scannable QR code inside a fenced code block. This is a local computation tool — no HTTP request is made. Agent usage: pass a LINK field from an earlier response — `deep_link` (create_session, create_chat_id_discovery always; start_login, create_account, start_2fa, start_2fa_for_action on telegram/whatsapp ONLY, where on sms and email that field is empty or absent altogether and this tool rejects it either way), `challenge.deep_link` (create_verification, messenger channels only), or `telegram_deep_link` / `whatsapp_deep_link`. Do NOT pass `qr_text` to this tool: that field is a QR code already rendered as text, and this tool takes a link. When a response gives you `qr_text` and no link, print it verbatim inside a fenced code block instead — its rows only scan while they stay adjacent, so a blank line or wrapped row destroys the code. Input parameters: - `label` (string): Optional label to display above the link (e.g. "Verify your phone number") - `url` (string, required): The link to render — e.g. a deep_link response field. Never a qr_text value: that is the link already rendered as QR art. ## Diagnostics Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/holdings-proof-mcp-server/proof-holdings-mcp-server#diagnostics ## Score history - 2026-09-25: 73 - 2026-09-24: 72 - 2026-09-23: 72 - 2026-09-22: 71 - 2026-09-21: 71 - 2026-09-20: 70 - 2026-09-19: 70 - 2026-09-18: 69 - 2026-09-17: 69 - 2026-09-16: 65 - 2026-09-15: 65 - 2026-09-14: 65 - 2026-09-13: 65 - 2026-09-12: 65 - 2026-09-11: 65 - 2026-09-10: 65 - 2026-09-09: 65 ## Common questions ### 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. ## Links - npm package: https://www.npmjs.com/package/@proof-holdings/mcp-server - Socket report: https://socket.dev/npm/package/@proof-holdings/mcp-server - Repository: https://github.com/ProofHoldings/mcp-server - Website: https://proof.holdings/ - Changelog RSS feed: https://verifymcp.io/servers/holdings-proof-mcp-server/proof-holdings-mcp-server.xml - Changelog JSON feed: https://verifymcp.io/servers/holdings-proof-mcp-server/proof-holdings-mcp-server.json - HTML version of this page: https://verifymcp.io/servers/holdings-proof-mcp-server/proof-holdings-mcp-server