Proof Holdings

regenerate_api_key

Destructive

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. Authenticate this client (Claude Code: /mcp → Authenticate), or sign in with start_login — a session opens this tool — then call this tool again.

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

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.

Changed1 schema field changedNov 2, 2026

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"
+}

Changed1 schema field changedOct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedSep 19, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the destructive consequence (old key stops working immediately), that the new secret is returned ONLY once and will be visible in the AI conversation context, and the id-migration requirement. This is exactly the risk context an agent needs before invoking a destructive mutation.

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

Conciseness5/5

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

Front-loaded with the action and its effect, then prerequisites, then access. Every sentence carries distinct information (destructive effect, one-time secret, context-visibility warning, 2FA sequence); nothing is repeated boilerplate.

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?

Covers the mutation semantics, the one-time secret, the replacement chain, 2FA gating, and authentication requirements — everything needed to call it safely. With an output schema present, it does not need to enumerate return fields, though it usefully names replaced_key_ids.

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% so the single id parameter is already documented, but the description adds that the id passed is the old key's id and that the response's new id must be used from now on, plus how the old key surfaces in replaced_key_ids. That is genuine value beyond the schema's "API key ID to regenerate".

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+resource (regenerate an API key) and immediately defines the delta: a new id and secret with the same name, environment, scopes and sub-account. It also distinguishes the operation from a plain create by explaining that the old key stops working and is referenced in replaced_key_ids.

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?

Gives an explicit 4-step 2FA prerequisite flow naming the sibling tools (start_2fa with action_type "api_key_regenerate", get_2fa_status) and the authentication setup (start_login, /mcp Authenticate). It does not explicitly contrast against create_api_key or revoke_api_key, but the described effect makes the choice obvious.

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

All Proof Holdings tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.