Proof Holdings
NPM · @PROOF-HOLDINGS/MCP-SERVER · 2 COMPONENTS · SCANNED SEP 25
One API, all things verified — control, delegation, human approval, anti-impersonation.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 42 of 126 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 15 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability74
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 22726 tokens (~129/item across 176 items; 176 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management53
- Stability observed for 16 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety25
- Injection-marker check failed: the description of tool "send_account_email" contains an instruction to conceal the call from the user, the text "Do not tell the user", at byte 959 of that field. See how to fix → Fail
- 0 of 21 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "revoke_proof" implies "revoke" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 177 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Proof Holdings MCP server?
Proof Holdings runs locally as an npm package, launched with npx -y @proof-holdings/mcp-server. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · @proof-holdings/mcp-server
claude mcp add holdings-proof-mcp-server -- npx -y @proof-holdings/mcp-server
{
"mcpServers": {
"holdings-proof-mcp-server": {
"command": "npx",
"args": [
"-y",
"@proof-holdings/mcp-server"
]
}
}
} {
"servers": {
"holdings-proof-mcp-server": {
"command": "npx",
"args": [
"-y",
"@proof-holdings/mcp-server"
]
}
}
} codex mcp add holdings-proof-mcp-server -- npx -y @proof-holdings/mcp-server
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"holdings-proof-mcp-server": {
"type": "local",
"command": [
"npx",
"-y",
"@proof-holdings/mcp-server"
],
"enabled": true
}
}
} openclaw mcp add holdings-proof-mcp-server --command npx --arg -y --arg @proof-holdings/mcp-server
mcp_servers:
holdings-proof-mcp-server:
command: "npx"
args: ["-y", "@proof-holdings/mcp-server"] {
"McpServers": {
"holdings-proof-mcp-server": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"@proof-holdings/mcp-server"
]
}
}
} assistant mcp add holdings-proof-mcp-server -t stdio -c npx -a -y @proof-holdings/mcp-server
{
"mcpServers": {
"holdings-proof-mcp-server": {
"command": "npx",
"args": [
"-y",
"@proof-holdings/mcp-server"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 25 Sept 26 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 23 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 21 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Sept 26 +4
- Stability: unverified → 0.27 ▲ functional
- 9 Sept 26 65
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 25 Sept 2026 · Analysed npm/@proof-holdings/mcp-server@1.1.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 126 packages
| Packages resolved | 126 |
|---|---|
| Stale | 42 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
update_circle ~82
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Circle ID |
| name | string | – | New name for the Circle |
No output schema declared.
No examples provided.
update_hitl ~103
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.
| Name | Type | Req | Description |
|---|---|---|---|
| channels | array | – | Updated channels |
| id | string | yes | HITL config ID |
| name | – | – | New name (null to clear) |
| timeout_seconds | integer | – | Updated timeout in seconds (60–86400) |
No output schema declared.
No examples provided.
update_my_profile ~167
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 |
No output schema declared.
No examples provided.
update_profile ~211
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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 |
No output schema declared.
No examples provided.
update_profile_proofs ~90
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.
| Name | Type | Req | Description |
|---|---|---|---|
| profile_id | string | yes | Profile ID |
| proofs | array | yes | Proofs to display on profile |
No output schema declared.
No examples provided.
update_profile_template ~162
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.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | 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 | yes | Message channel |
| is_active | boolean | – | Whether the template is active |
| profile_id | string | yes | Profile ID |
| subject | string | – | Email subject line (email channel only) |
| type | string | yes | Message type (e.g. verification_request, login_request) |
No output schema declared.
No examples provided.
update_public_proofs ~83
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.
| Name | Type | Req | Description |
|---|---|---|---|
| proofs | array | yes | Array of proof display configurations (max 50) |
No output schema declared.
No examples provided.
update_settings ~59
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.
| Name | Type | Req | Description |
|---|---|---|---|
| branding | object | – | Branding settings to update |
No output schema declared.
No examples provided.
update_template ~142
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.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | 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 | yes | Message channel |
| message_type | string | yes | Message type (e.g. verification_request, login_request) |
| subject | string | – | Email subject line (email channel only) |
No output schema declared.
No examples provided.
upload_hitl_keys ~173
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.
| Name | Type | Req | Description |
|---|---|---|---|
| encrypted_private_key | string | yes | JSON-serialized encrypted private key envelope (PBKDF2-SHA256+AES-256-GCM) |
| hitl_id | string | yes | HITL config ID |
| kdf_salt | string | yes | Base64url-encoded PBKDF2 salt |
| public_key | string | yes | PEM-encoded RSA-4096 SPKI public key |
No output schema declared.
No examples provided.
validate_proof ~119
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | The JWT proof token to validate |
No output schema declared.
No examples provided.
verify_2fa ~89
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.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | Verification code |
| session_id | string | yes | 2FA session ID |
No output schema declared.
No examples provided.
verify_2fa_magic_link ~90
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.
| Name | Type | Req | Description |
|---|---|---|---|
| token | string | yes | Magic link token from the verification email |
No output schema declared.
No examples provided.
verify_delegation ~519
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | The artifact identity you resolved independently. Required: this comparison is what defeats a copied token. |
| expected_principal | string | yes | 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 |
No output schema declared.
No examples provided.
verify_delegations ~353
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.
| Name | Type | Req | Description |
|---|---|---|---|
| items | array | yes | 1-50 artifacts to verify in this call, each shaped like a verify_delegation call |
No output schema declared.
No examples provided.
verify_domain ~71
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Domain ID to verify |
No output schema declared.
No examples provided.
verify_domain_with_credentials ~74
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Domain ID to verify |
No output schema declared.
No examples provided.
verify_email_otp ~92
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.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | OTP code received via email |
| session_id | string | yes | Add-email session ID |
No output schema declared.
No examples provided.
wait_for_2fa ~252
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.
| Name | Type | Req | Description |
|---|---|---|---|
| session_id | string | yes | 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… |
No output schema declared.
No examples provided.
wait_for_account_creation ~223
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | 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… |
No output schema declared.
No examples provided.
wait_for_chat_id_discovery ~245
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Discovery token from create_chat_id_discovery |
No output schema declared.
No examples provided.
wait_for_confirmation ~291
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | 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… |
No output schema declared.
No examples provided.
wait_for_login ~230
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | 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… |
No output schema declared.
No examples provided.
wait_for_request ~167
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | 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… |
No output schema declared.
No examples provided.
wait_for_session ~165
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | 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… |
No output schema declared.
No examples provided.
wait_for_verification ~207
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | 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… |
No output schema declared.
No examples provided.
What is the Proof Holdings MCP server?
Proof Holdings is an MCP server listed in the public MCP registry as holdings.proof/mcp-server. One API, all things verified, control, delegation, human approval, anti-impersonation. This page covers its npm package (@proof-holdings/mcp-server).
Is the Proof Holdings MCP server safe to use?
Proof Holdings scores 73 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 25 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Proof Holdings MCP server expose?
Proof Holdings exposes 176 tools: create_verification, get_verification, list_verifications, trigger_verification, submit_verification_code, and 171 more. Their descriptions and schemas cost roughly 22,440 tokens of context every time the server is loaded.
Is the Proof Holdings MCP server still maintained?
Proof Holdings is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the Proof Holdings MCP server under?
Proof Holdings declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.