Skip to main content
Glama

revoke_proof

Destructive

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. A domain CONTROL proof (a ph_ctl_* of a domain) also revokes, for good, every delegation issued from it; for a domain you own, every proof of the domain is revoked and the domain needs re-verification. The API key needs proofs:write, plus delegations:write while the revocation reaches live delegations — for a domain you own, any live delegation of the domain, whichever of its handles you name (the refusal names the scope and the count). A handle revoked before the domain was verified again does not reach the new proof: revoke that one by its own handle. Otherwise it revokes the PROOF only — the asset or consent it is about stays. Need a temporary stop? Use suspend_proof instead. Cannot be undone.

ACCESS: needs a Proof account. Authenticate this client (Claude Code: /mcp → Authenticate), then call this tool again. start_login 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_proof"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesPublic proof handle (ph_ctl_* / ph_dlg_*) or verification ID
reasonNoWhy the proof is revoked, one of: user_request, fraud, key_compromise, asset_transferred, other. A delegation proof (ph_dlg_*) refuses asset_transferred. The API refuses any other value. Defaults to user_request.

Output Schema

NameRequiredDescriptionDefault
reasonNo
successNo
proof_idNoPublic proof handle (`ph_ctl_*`/`ph_dlg_*`). Present when the proof was addressed by handle.
principalNoControl proofs only: the domain the proof is about.
proof_typeNoWhich record carries the revoked proof (`verification`, `user_asset`, `verification_request`, `delegation`, …). Present when the proof was addressed by handle.
revoked_atNo
owned_domainNoControl proofs only: true when the account OWNS the domain (a Domain row or a domain asset for the name) and the whole-domain cascade ran — every proof of the domain and every delegation issued from it revoked, the domain demoted to `reverification_required`. False for a bare verification of somebody else's domain: that proof and the delegations anchored on it only.
domain_statusNoControl proofs only: the Domain row's status after the act (`reverification_required` after the cascade); null when the account has no Domain row for the name.
verification_idNoPresent only when the revoked proof belongs to a verification.
delegations_revokedNoControl proofs only: the delegations revoked with the proof. Re-verifying the domain does not bring them back.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / reason / description
      Previous value: -"Reason for revocation"New value: +"Why the proof is revoked, one of: user_request, fraud, key_compromise, asset_transferred, other. A delegation proof (ph_dlg_*) refuses asset_transferred. The API refuses any other value. Defaults to user_request."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "delegations_revoked": {
      +      "description": "Control proofs only: the delegations revoked with the proof. Re-verifying the domain does not bring them back."
      +    },
      +    "domain_status": {
      +      "description": "Control proofs only: the Domain row's status after the act (`reverification_required` after the cascade); null when the account has no Domain row for the name."
      +    },
      +    "owned_domain": {
      +      "description": "Control proofs only: true when the account OWNS the domain (a Domain row or a domain asset for the name) and the whole-domain cascade ran — every proof of the domain and every delegation issued from it revoked, the domain demoted to `reverification_required`. False for a bare verification of somebody else's domain: that proof and the delegations anchored on it only."
      +    },
      +    "principal": {
      +      "description": "Control proofs only: the domain the proof is about."
      +    },
      +    "proof_id": {
      +      "description": "Public proof handle (`ph_ctl_*`/`ph_dlg_*`). Present when the proof was addressed by handle."
      +    },
      +    "proof_type": {
      +      "description": "Which record carries the revoked proof (`verification`, `user_asset`, `verification_request`, `delegation`, …). Present when the proof was addressed by handle."
      +    },
      +    "reason": {},
      +    "revoked_at": {},
      +    "success": {},
      +    "verification_id": {
      +      "description": "Present only when the revoked proof belongs to a verification."
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description provides massive behavioral context beyond standard annotations, detailing complex cascading effects such as domain proofs revoking all delegated proofs and the irreversibility of the action ('Cannot be undone'). This is essential for a destructive, high-impact tool.

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

Conciseness3/5

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

The definition is extremely verbose and dense, running several paragraphs long. While the information is necessary for the tool's complexity, the length requires significant cognitive load and could be improved by prioritizing the most common use case over complex edge cases.

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?

Given the highly technical nature and cascading effects of proof revocation (especially concerning domains and API scope), the description is extremely complete. It addresses every possible failure mode or prerequisite an agent might encounter before calling the tool.

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

Parameters5/5

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

While schema coverage is 100%, the description adds crucial semantic constraints. It explicitly states that the `id` can be a handle OR a verification ID and specifies behavioral rules for the `reason` parameter based on the type of proof (e.g., delegation proofs refusing 'asset_transferred').

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?

The description clearly states the resource (Proof) and the action (Revoke). It is highly specific about where the revocation takes effect (revocation list, status endpoint), which greatly aids an agent in understanding the full scope of the function.

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?

It provides explicit guidance on prerequisites (required API scopes like proofs:write and delegations:write), necessary operational choices (handle vs. verification ID), and critical behavioral alternatives like using `suspend_proof` instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.