@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

revoke_my_proof

Destructive

Revokes all proofs for one phone, email, or domain asset by its asset ID while keeping the asset on your account; the revocation cannot be undone.

Instructions

Revoke EVERY proof of one of your assets (a phone, email or domain), by its asset id from list_my_proofs — the asset stays on the account. A ph_ctl_* / ph_dlg_* handle is one proof, not an asset: revoke that with revoke_proof. Owner only: sign in with start_login (a connection with only an API key is refused user_session_required — a key revokes a proof with revoke_proof instead), then one code: start_2fa_for_action with action_type revocation_bulk and targets [this asset id], wait_for_2fa, and call again. A phone or email: every proof of that number or address is revoked; signing in with it again issues a fresh proof. A domain you own: every proof of the domain and every delegation issued from it are revoked for good, and the domain needs re-verification — re-verifying does NOT bring the delegations back. Need a temporary stop for a domain proof? Use pause_proof instead. Status-checking verifiers see the revocation within about a minute; signature-only verifiers accept a token until it expires. Cannot be undone.

ACCESS: needs a Proof account, signed in: call start_login, show the user its challenge, then wait_for_login, then call this tool again. An API key alone does NOT open this tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "revoke_my_proof"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Asset ID (24 hex characters, from list_my_proofs). A ph_ctl_* / ph_dlg_* handle is a proof: use revoke_proof.

Output Schema

Name	Required	Description
`type`	No
`notice`	No
`outcome`	No	`not_found` is also the answer for an asset the account does not own.
`success`	No	Always `true`
`asset_id`	No
`identifier`	No	Masked for phones and emails; a domain travels in clear.
`domain_status`	No	Domains only: `reverification_required` — the domain stays on the account and needs re-verification before anything can be issued from it.
`revoked_asset_ids`	No	Every asset of the same identifier this call revoked with it, the named one included — a phone holds one asset per channel, a domain one per verification.
`delegations_revoked`	No	Domains only: the delegations revoked with the proofs. Re-verifying does not bring them back.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.10.0Nov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say destructive=true; the description goes far beyond that with the irreversibility ('Cannot be undone'), the fact that the asset itself stays on the account, and the asymmetric per-type effects: phone/email get a fresh proof on next sign-in, while a domain's delegations are revoked permanently and re-verification does NOT restore them. It even discloses downstream propagation timing (status-checking verifiers within ~a minute vs signature-only verifiers accepting until token expiry), which no annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and its scoping caveat are front-loaded in the first sentence, and the per-asset-type consequences are worth their length. The main waste is duplication: the sign-in requirement and the API-key-refusal rule are narrated in the main paragraph and then repeated almost verbatim in the ACCESS block. The single dense paragraph also mixes purpose, authorization, per-type semantics, and timing, which makes it harder to scan than a short structured list would be.

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

Completeness5/5

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

For a destructive, multi-step-authenticated tool this covers everything an agent needs: what is destroyed, what survives, which call sequence to run (start_login → start_2fa_for_action with action_type revocation_bulk → wait_for_2fa → retry), and the irreversibility warning. An output schema exists, so the absence of return-value detail is not a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema's own description already says 'Asset ID (24 hex characters, from list_my_proofs)' and warns that a ph_ctl_*/ph_dlg_* handle belongs to revoke_proof. The description restates essentially the same constraint, so it adds reinforcement rather than new meaning. Baseline 3 is appropriate when the schema carries the parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and scope: 'Revoke EVERY proof of one of your assets (a phone, email or domain), by its asset id from list_my_proofs'. It immediately distinguishes the unit of operation from the sibling: 'A ph_ctl_* / ph_dlg_* handle is one proof, not an asset: revoke that with revoke_proof.' An agent can pick between this and revoke_proof without opening either schema.

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

Usage Guidelines5/5

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

Names the alternative for the per-proof case (revoke_proof), the alternative for the temporary-stop case ('Need a temporary stop for a domain proof? Use pause_proof instead'), and where the id comes from (list_my_proofs). It also spells out the required call sequence and the exclusion that an API-key-only connection is refused, so the agent knows both when to use it and how to get authorized first.

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

Deploy Server