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

@proof-holdings/mcp-server

Official

revoke_authorization

Destructive

Revoke an active or pending authorization by ID to withdraw unwanted access; optionally provide a reason for the revocation.

Instructions

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 Schema

NameRequiredDescriptionDefault
idYesAuthorization ID to revoke
reasonNoReason for revocation

Output Schema

NameRequiredDescriptionDefault
idYesMongoDB ObjectId
bsuidNoWhatsApp Business-Scoped User ID
labelNoOwner-assigned human label for this approver (F22); null when unset. Surfaces lead with it, falling back to the masked recipient.
phoneNo
scopeYesScope of the authorization. `identity_challenge` is the Proof of Me scope.
statusYesStatus of an authorization
channelYesChannel authorized for sending confirmations
hitl_idNo
enrolledYesWhether the approver has enrolled an encryption key. A confirmation can be sealed to an approver only once this is true; consent alone (`status: active`) is not enough.
circle_idNo
denied_atNoWhen the recipient refused — the mirror of `authorized_at` for a `denied` row (a challenger cancellation stamps it too). Absent unless the authorization was denied; before it existed such a row carried no decision time at all, only `updated_at`.
recipientNoChannel-specific recipient identifier (chat_id for Telegram, phone or BSUID for WhatsApp)
created_atYes
expires_atYes
revoked_atNo
updated_atYes
proof_tokenNoSigned proof of the recipient's decision, minted when they approved or refused, for both scopes. Absent while no decision has been made.
last_used_atNo
authorized_atNo
business_nameYes
verification_idNoMongoDB ObjectId
revocation_reasonNo
confirmations_sentYes
recipient_display_nameYesThe approver's own messenger name ("First Last @username"), captured when they approved over Telegram; null when none was captured. Chosen by the approver, not verified.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.2
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "description": "Authorization granting permission to send confirmations via a specific channel",
      +  "properties": {
      +    "authorized_at": {
      +      "type": "string"
      +    },
      +    "bsuid": {
      +      "description": "WhatsApp Business-Scoped User ID",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "business_name": {
      +      "type": "string"
      +    },
      +    "channel": {
      +      "description": "Channel authorized for sending confirmations",
      +      "type": "string"
      +    },
      +    "circle_id": {
      +      "allOf": [
      +        {
      +          "type": "string"
      +        },
      +        {}
      +      ]
      +    },
      +    "confirmations_sent": {
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "created_at": {
      +      "type": "string"
      +    },
      +    "denied_at": {
      +      "description": "When the recipient refused — the mirror of `authorized_at` for a `denied` row (a challenger cancellation stamps it too). Absent unless the authorization was denied; before it existed such a row carried no decision time at all, only `updated_at`.",
      +      "type": "string"
      +    },
      +    "enrolled": {
      +      "description": "Whether the approver has enrolled an encryption key. A confirmation can be sealed to an approver only once this is true; consent alone (`status: active`) is not enough.",
      +      "type": "boolean"
      +    },
      +    "expires_at": {
      +      "type": "string"
      +    },
      +    "hitl_id": {
      +      "allOf": [
      +        {
      +          "type": "string"
      +        },
      +        {}
      +      ]
      +    },
      +    "id": {
      +      "description": "MongoDB ObjectId",
      +      "type": "string"
      +    },
      +    "label": {
      +      "description": "Owner-assigned human label for this approver (F22); null when unset. Surfaces lead with it, falling back to the masked recipient.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "last_used_at": {
      +      "type": "string"
      +    },
      +    "phone": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "proof_token": {
      +      "description": "Signed proof of the recipient's decision, minted when they approved or refused, for both scopes. Absent while no decision has been made.",
      +      "type": "string"
      +    },
      +    "recipient": {
      +      "description": "Channel-specific recipient identifier (chat_id for Telegram, phone or BSUID for WhatsApp)",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "recipient_display_name": {
      +      "description": "The approver's own messenger name (\"First Last @username\"), captured when they approved over Telegram; null when none was captured. Chosen by the approver, not verified.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "revocation_reason": {
      +      "type": "string"
      +    },
      +    "revoked_at": {
      +      "type": "string"
      +    },
      +    "scope": {
      +      "description": "Scope of the authorization. `identity_challenge` is the Proof of Me scope.",
      +      "type": "string"
      +    },
      +    "status": {
      +      "description": "Status of an authorization",
      +      "type": "string"
      +    },
      +    "updated_at": {
      +      "type": "string"
      +    },
      +    "verification_id": {
      +      "description": "MongoDB ObjectId",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "id",
      +    "status",
      +    "channel",
      +    "scope",
      +    "business_name",
      +    "recipient_display_name",
      +    "enrolled",
      +    "expires_at",
      +    "confirmations_sent",
      +    "created_at",
      +    "updated_at"
      +  ],
      +  "type": "object"
      +}
  2. First observedv1.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Beyond readOnlyHint=false and destructiveHint=true, the description adds the status precondition and concrete account, API-key, and server-restart requirements. It still omits whether revocation is irreversible, what capabilities it invalidates, and how attempts to revoke other statuses behave.

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 action and eligibility rule are front-loaded, and the ACCESS label makes the setup guidance easy to scan. The first two sentences partially repeat the active/pending limitation, and the setup instructions could be slightly tighter.

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

Completeness4/5

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

For a simple two-parameter destructive mutation with an output schema, the status restriction and access prerequisites cover most selection and invocation needs. Explaining revocation's consequences or permanence and providing an ID-discovery or related-tool pointer would make it more complete.

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 description coverage is 100%, and both id and reason already have clear descriptions, so the baseline score applies. The description adds no ID source or format and no guidance on when a revocation reason should be supplied.

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

Purpose4/5

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

"Revoke an active or pending authorization" gives a specific action, resource, and eligibility scope. It does not explicitly distinguish this operation from related siblings such as revoke_delegation, revoke_proof, or cancel_verification_request.

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

Usage Guidelines4/5

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

The active/pending-only rule provides explicit when and when-not guidance, while the ACCESS section supplies prerequisites and warns that start_login is insufficient. It does not recommend an alternative for ineligible authorizations or point to list_authorizations or get_authorization for finding and checking an authorization.

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