@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

regenerate_api_key

Destructive

Issues a replacement API key with the same name, environment, scopes, and sub-account; the old key stops working immediately and the new secret is returned once.

Instructions

Regenerate an API key: issues a new key (a new id and secret) with the same name, environment, scopes and sub-account. The old key stops working immediately; use the id in this response from now on. The new key lists the old one in replaced_key_ids, so its requests and usage stay with it. The new secret is returned ONLY in this response. Note: the secret will be visible in the AI conversation context.

Agent usage: This operation requires 2FA. Before calling, complete the 2FA flow: (1) call start_2fa with action_type "api_key_regenerate", (2) wait for user to verify the code, (3) poll get_2fa_status until "verified", (4) then call regenerate_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

Name	Required	Description	Default
`id`	Yes	API key ID to regenerate

Output Schema

Name	Required	Description
`id`	Yes	MongoDB ObjectId
`key`	Yes	The full API key. Returned only in this response; it cannot be read again.
`name`	Yes
`prefix`	Yes
`scopes`	Yes
`warning`	Yes
`created_at`	Yes
`profile_id`	Yes	Sub-account (PublicProfile) the key is bound to; null for unbound keys.
`environment`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.7.2Nov 6, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "A newly created or regenerated API key, with its full value — the one response that carries it.",
+  "properties": {
+    "created_at": {
+      "type": "string"
+    },
+    "environment": {
+      "type": "string"
+    },
+    "id": {
+      "description": "MongoDB ObjectId",
+      "type": "string"
+    },
+    "key": {
+      "description": "The full API key. Returned only in this response; it cannot be read again.",
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "prefix": {
+      "type": "string"
+    },
+    "profile_id": {
+      "description": "Sub-account (PublicProfile) the key is bound to; null for unbound keys.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "scopes": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "warning": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "key",
+    "name",
+    "prefix",
+    "environment",
+    "scopes",
+    "profile_id",
+    "created_at",
+    "warning"
+  ],
+  "type": "object"
+}

First observedv1.1.0Sep 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructiveHint=true annotation: it discloses that the old key stops working immediately, that the new key's id supersedes the old, that replaced_key_ids links the two so requests and usage carry over, and that the secret is shown only once and will be visible in the AI conversation context. These are exactly the irreversible-side-effect and secret-exposure facts an agent needs before committing.

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-loads the core effect (new key issued, old one dies) before the secondary details, and the numbered 2FA steps are operationally necessary rather than filler. It is somewhat dense with four distinct fact blocks, but each sentence carries non-redundant 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?

An output schema exists, so return-value documentation is unnecessary; the description instead covers the parts structured data cannot: irreversibility, one-time secret exposure, key-lineage behavior, 2FA sequencing, and authentication prerequisites. Nothing an agent needs to invoke this safely 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 parameter is documented as "API key ID to regenerate", so the baseline is already met; the description adds the useful clarification that this is the OLD key's id and that the response returns a new id to use going forward, which prevents passing the newly issued id back in.

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 (regenerate) and resource (API key) and immediately defines the semantics: a new id and secret with the same name, environment, scopes and sub-account. That behavioral footprint distinguishes it from siblings like create_api_key and revoke_api_key without naming them, since neither of those preserves identity/settings this way.

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, ordered prerequisite flow (start_2fa with action_type "api_key_regenerate", user verifies, poll get_2fa_status until "verified", then call this tool) plus account/access setup via PROOF_API_KEY or start_login. What is missing is guidance on when to regenerate versus create a fresh key or revoke an existing one.

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

Deploy Server