Skip to main content
Glama
Sign In
@proof-holdings/mcp-server

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

pause_proof

Destructive

Suspend an active proof by public handle or verification ID to mark it invalid without revoking it; resume it to restore access.

Instructions

Pause a proof by its public handle (ph_ctl_* / ph_dlg_*) or a verification ID — a reversible stop, undone with resume_proof. While paused the proof is invalid: the status endpoint, the public validator and the Token Status List report it suspended; it is deliberately NOT put on the revocation list. Only an active proof can be paused (already_suspended, proof_expired or proof_revoked otherwise). Pausing a delegation (ph_dlg_*) stops a live publisher's tools: an MCP server running the Proof delegation gate refuses its tool calls once its next status check sees the pause (self-refusal). Pausing a domain CONTROL proof hides every delegation issued from it until it is resumed; nothing is revoked. The API key needs proofs:write, plus delegations:write for a ph_dlg_* or while delegations under a control proof are live.

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.

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": "pause_proof"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesPublic proof handle (ph_ctl_* / ph_dlg_*) or verification ID

Output Schema

NameRequiredDescriptionDefault
statusNo`suspended` after a suspend, `active` after an unsuspend
proof_idNoPublic proof handle (`ph_ctl_<32 hex>`)
suspended_atNoWhen the suspension began; null after an unsuspend
status_list_uriNoThe Token Status List where this change is published

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.10.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description goes well beyond them: cascade effects (control-proof pause hides all delegations; delegation pause causes self-refusal in gated MCP servers), how status surfaces report 'suspended' while staying off the revocation list, and required scopes (proofs:write, delegations:write). The one wrinkle is that destructiveHint=true is softened to 'reversible... nothing is revoked', but that is nuance rather than contradiction, so no flag. Deduction only because the permission/scope detail is buried in a trailing block rather than surfaced with the side effects.

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?

Front-loaded with verb, resource, and reversibility, then preconditions, then consequences, then access prerequisites — a sensible ordering. It is dense and long, with mild repetition ('deliberately NOT put on the revocation list' vs 'nothing is revoked'), but essentially every sentence carries operator-relevant information.

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 mutating tool with cascade side effects, it covers preconditions, error states, downstream consequences on three status surfaces, permission requirements, and setup access. An output schema exists, so return values need not be explained, and nothing material is missing.

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

Parameters4/5

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

Schema coverage is 100% and the single 'id' parameter is documented there, so the baseline is 3. The description earns an extra point by attaching behavioral meaning to the handle prefixes — ph_dlg_* pauses a live publisher's tools, ph_ctl_* hides every delegation issued under it — which the schema does not convey.

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?

Opens with a specific verb+resource ('Pause a proof') plus the identifier forms it accepts, and immediately names the inverse operation ('undone with resume_proof'). It also draws the key distinction from revocation, which is the nearest sibling behavior an agent might otherwise confuse it with.

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?

Explicit preconditions ('Only an active proof can be paused') with the exact failure outcomes (already_suspended, proof_expired, proof_revoked), an explicit alternative (resume_proof for undo, revoke_proof implicitly contrasted), and even an anti-pattern note that start_login does NOT unlock the tool. Nothing is left to inference.

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

Deploy Server

Other Tools