portkey-admin-mcp

create_virtual_key

Create an encrypted virtual key from a provider API key. The raw key is returned only once; use the returned slug in prompts and configs to apply usage and rate limits.

Instructions

Store a provider API key as a virtual key. The raw key is encrypted and only returned at creation time, so save the returned slug and use it in prompts/configs. Optional usage and rate limits apply immediately, and the tool returns the new slug.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	No	Provider API key; omit when secret_mappings supplies key
`name`	Yes	Display name for the virtual key
`note`	No	Optional note or description for this key
`provider`	Yes	Provider slug (e.g., 'openai', 'anthropic', 'azure-openai', 'google')
`expires_at`	No	Expiration in ISO 8601 format
`api_version`	No	API version (for Azure OpenAI)
`credit_limit`	No	Maximum usage cost threshold
`workspace_id`	No	Workspace ID to create the key in
`resource_name`	No	Resource name (for Azure OpenAI)
`rate_limit_rpm`	No	Requests per minute limit
`alert_threshold`	No	Percentage of credit_limit at which to send alert emails (0-100)
`deployment_name`	No	Deployment name (for Azure OpenAI)
`secret_mappings`	No	Secret Reference mappings for key or model_config fields
`deployment_configurations`	No	Azure deployment configurations with API versions and aliases

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.

Changed5 schema fields changedv0.11.5Sep 8, 2026

addedInput schema / properties / deployment_configurations

Added value: +{
+  "description": "Azure deployment configurations with API versions and aliases",
+  "items": {
+    "properties": {
+      "alias": {
+        "description": "Optional model alias for the deployment",
+        "type": "string"
+      },
+      "api_version": {
+        "description": "Azure OpenAI API version",
+        "minLength": 1,
+        "type": "string"
+      },
+      "deployment_name": {
+        "description": "Azure deployment name",
+        "minLength": 1,
+        "type": "string"
+      },
+      "is_default": {
+        "description": "Whether this is the default Azure deployment",
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "api_version",
+      "deployment_name"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedInput schema / properties / expires_at

Added value: +{
+  "description": "Expiration in ISO 8601 format",
+  "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"
+}

changedInput schema / properties / key / description

Previous value: -"The actual provider API key to store"New value: +"Provider API key; omit when secret_mappings supplies key"

addedInput schema / properties / secret_mappings

Added value: +{
+  "description": "Secret Reference mappings for key or model_config fields",
+  "items": {
+    "properties": {
+      "secret_key": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "Optional key selected from a structured external secret"
+      },
+      "secret_reference_id": {
+        "description": "Secret Reference ID that owns the external secret",
+        "type": "string"
+      },
+      "target_field": {
+        "description": "Virtual Key field populated from the Secret Reference",
+        "type": "string"
+      },
+      "value_format": {
+        "anyOf": [
+          {
+            "enum": [
+              "json",
+              "string"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "Whether Portkey reads the mapped value as JSON or a string"
+      }
+    },
+    "required": [
+      "target_field",
+      "secret_reference_id"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "name",
-  "provider",
-  "key"
-]New value: +[
+  "name",
+  "provider"
+]

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?

Annotations already signal a non-read-only, non-idempotent write, but the description adds genuinely critical behavior beyond them: the raw key is encrypted, it is returned exactly once at creation time, usage/rate limits take effect immediately, and the tool returns a slug. An agent that misses the one-time-return fact could make an irreversible reference mistake later.

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?

Three sentences, all information-bearing, with purpose front-loaded. The only minor flaw is a slight redundancy: 'only returned at creation time' and 'returns the new slug' both convey that the slug is the output, so the third sentence's fresh content is just the immediate-application-of-limits point.

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?

Given a 14-parameter tool and an existing output schema, the description correctly focuses on the one operational gotcha an agent must not miss (one-time raw-key return and slug retention) while leaving parameter details to the fully covered schema. It is complete enough to invoke the tool correctly; Azure-specific conditional parameters are already documented per-property in the schema.

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%, so the schema carries the parameter-documentation burden and the baseline is 3. The description adds a small amount of semantic glue ('usage and rate limits' maps to credit_limit and rate_limit_rpm, and 'returns the new slug' hints at the output), but it does not compensate for or extend the schema's parameter docs in any substantial way.

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?

The description opens with a specific verb-resource pairing ('Store a provider API key as a virtual key') and immediately establishes the defining traits that separate this from plain API-key creation: encryption, slug-based reference, and use in prompts/configs. Against a sibling set containing both create_api_key and create_virtual_key, this clearly identifies the niche.

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 description gives clear usage context: the tool is for persisting a provider key in a referenceable form, and it instructs the agent to save the returned slug and use it in prompts/configs. It stops short of explicitly naming alternatives or stating when not to use it (e.g., versus create_api_key), so it earns a 4 rather than 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