portkey-admin-mcp

create_api_key

Create a Portkey API key with scopes, rate limits, and expiry to control access. Choose workspace or org-level access; save the secret shown once.

Instructions

Create a Portkey API key for auth. Org keys grant broader access; workspace keys are scoped. WARNING: The key secret is returned ONCE in the tool result and will be visible in MCP transcripts and LLM context — store it securely immediately. Using the key grants access immediately according to its scopes, defaults, and limits. Workspace keys require workspace_id and user keys require user_id.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Display name for the API key
`type`	Yes	Key type: 'organisation' for org-wide access or 'workspace' for workspace-scoped
`scopes`	Yes	Permission scopes for the key (e.g., ['logs.read', 'analytics.read'])
`user_id`	No	User ID (required for user sub-type keys)
`sub_type`	Yes	Sub-type: 'user' for user-associated keys or 'service' for service accounts
`expires_at`	No	Expiration date in ISO 8601 format
`description`	No	Optional description for the key
`rate_limits`	No	Request or token rate limits, or null to clear them
`alert_emails`	No	Email addresses for alerts
`credit_limit`	No	Credit limit for usage
`workspace_id`	No	Workspace ID (required for workspace-type keys)
`rate_limit_rpm`	No	Rate limit in requests per minute
`alert_threshold`	No	Alert threshold percentage (0-100)
`organisation_id`	No	Organisation UUID
`rotation_policy`	No	Automatic API-key rotation policy, or null to disable it
`default_metadata`	No	Default metadata key-value pairs
`default_config_id`	No	Default configuration ID to use with this key
`default_allow_config_override`	No	Allow callers to override the default config

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the tool call succeeded and returned structured data
`data`	No	Structured success payload when ok is true
`error`	No	Structured error payload when ok is false

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.11.5Sep 8, 2026

addedInput schema / properties / default_allow_config_override

Added value: +{
+  "description": "Allow callers to override the default config",
+  "type": "boolean"
+}

addedInput schema / properties / expires_at / format
```
Added value: +"date-time"
```

addedInput schema / properties / expires_at / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"

addedInput schema / properties / organisation_id

Added value: +{
+  "description": "Organisation UUID",
+  "type": "string"
+}

addedInput schema / properties / rate_limits

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "properties": {
+          "type": {
+            "description": "Whether the limit counts requests or tokens",
+            "enum": [
+              "requests",
+              "tokens"
+            ],
+            "type": "string"
+          },
+          "unit": {
+            "description": "Rate window unit for the request or token count",
+            "enum": [
+              "rpd",
+              "rph",
+              "rpm",
+              "rps",
+              "rpw"
+            ],
+            "type": "string"
+          },
+          "value": {
+            "description": "Maximum count in the selected rate window",
+            "maximum": 9007199254740991,
+            "minimum": 0,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "type",
+          "unit",
+          "value"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Request or token rate limits, or null to clear them"
+}

addedInput schema / properties / rotation_policy

Added value: +{
+  "anyOf": [
+    {
+      "description": "Automatic API-key rotation policy, or null to remove it",
+      "properties": {
+        "key_transition_period_ms": {
+          "description": "Overlap in milliseconds before the previous key expires",
+          "maximum": 9007199254740991,
+          "minimum": 1800000,
+          "type": "integer"
+        },
+        "next_rotation_at": {
+          "anyOf": [
+            {
+              "format": "date-time",
+              "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Explicit next rotation timestamp in ISO 8601 format"
+        },
+        "rotation_period": {
+          "anyOf": [
+            {
+              "enum": [
+                "weekly",
+                "monthly"
+              ],
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Built-in weekly or monthly automatic rotation cadence"
+        }
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Automatic API-key rotation policy, or null to disable it"
+}

Addedv1.0.1May 7, 2026
RemovedMay 1, 2026
First observedJan 1, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description adds highly valuable behavioral context beyond annotations: the key secret is returned exactly once, will be visible in MCP transcripts and LLM context, and must be stored immediately. It also discloses that access activates immediately according to scopes, defaults, and limits. This is exactly the kind of operational risk an agent needs to know.

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?

The description is compact and well organized: purpose first, then scope distinction, then the security-critical warning, then required parameter relationships. Every sentence earns its place and there is no redundant schema repetition or filler.

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 complex 18-parameter mutation tool with an output schema, the description covers purpose, key type selection, required IDs, immediate activation, and the one-time secret exposure behavior. This is sufficient for an agent to use the tool correctly without needing the schema to explain operational context.

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?

The input schema already documents all 18 parameters with full coverage, so the baseline is 3. The description reinforces which IDs are required for which key types, but this information is also present in the schema. It adds little genuinely new parameter-specific meaning, though it does help synthesize the key type relationships.

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?

The description states a specific action ('Create a Portkey API key') with a clear purpose ('for auth') and distinguishes org keys from workspace keys by scope. However, it does not explicitly contrast itself with the sibling create_virtual_key, so sibling differentiation is incomplete.

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?

It provides useful conditional guidance: org keys for broader access, workspace keys for scoped access, and it flags the required companion parameters (workspace_id for workspace keys, user_id for user keys). It does not name alternatives or state when this tool should be avoided in favor of a sibling like create_virtual_key.

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

Deploy Server