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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

revoke_api_key

Destructive

Permanently revoke an API key by its ID to immediately disable access; this irreversible action requires completing 2FA verification first.

Instructions

Revoke an API key by ID. The key will immediately stop working. This action cannot be undone.

Agent usage: This operation requires 2FA. Before calling, complete the 2FA flow: (1) call start_2fa with action_type "api_key_revoke", (2) wait for user to verify the code, (3) poll get_2fa_status until "verified", (4) then call revoke_api_key.

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.

Input Schema

NameRequiredDescriptionDefault
idYesAPI key ID to revoke

Output Schema

NameRequiredDescriptionDefault
messageNo
successYes

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": "Generic success response",
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: the key stops working immediately, the action is irreversible, 2FA is mandatory with a specific action_type, and a Proof account/session is required. Those are exactly the operational facts an agent needs before an irreversible mutation.

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?

Well front-loaded: consequence first, then prerequisites, then access. Sentences earn their place. The access paragraph is slightly muddled in its phrasing ("a session opens this tool"), which is the only reason this isn't a 5.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description fills the remaining gaps: gating requirements, the multi-step 2FA handshake, and the account prerequisite. Nothing essential to correct invocation is missing.

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 single parameter 'id' is already documented as "API key ID to revoke", so the schema carries the meaning. The description only reinforces that revocation targets a key identifier and adds no format, source, or lookup guidance (e.g., obtain IDs from list_api_keys). Baseline 3 applies.

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 resource ("Revoke an API key by ID") and immediately conveys scope through the irreversibility note. Against siblings like create_api_key, regenerate_api_key, list_api_keys, and get_api_key_usage, an agent can tell exactly which key-management operation this is without opening the schema.

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?

Provides an explicit, numbered prerequisite sequence naming the exact sibling tools to call first (start_2fa with action_type "api_key_revoke", then get_2fa_status until "verified"). It also states the account/auth precondition. It does not say when NOT to use it (e.g., prefer regenerate_api_key when rotation rather than revocation is intended), which keeps it just under a 5.

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