portkey-admin-mcp

register_deployment

Create a self-hosted Gateway deployment to onboard a new control-plane target and securely store the one-time credentials returned. Enterprise-gated.

Instructions

Enterprise-gated. Register a self-hosted Gateway deployment when onboarding a new control-plane target; use list_deployments for existing registrations. The response can contain authentication and registry credentials exactly once, exposed to this MCP transcript, so store them securely immediately and never log them. Enterprise-gated. Returns 403 on non-Enterprise Portkey plans.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Deployment display name
`slug`	No	Optional deployment slug
`tags`	No	Deployment tags, or null to create without tags
`type`	No	Production or non-production deployment type
`is_default`	No	Make this the default deployment
`organisation_id`	No	Owning organisation UUID
`gateway_base_url`	No	Self-hosted Gateway base URL
`jwt_subs_allowed`	No	JWT subject values allowed to use the deployment
`deployment_config`	No	Gateway deployment configuration
`workspaces_allowed`	No	Workspace slugs this deployment may serve; empty allows all
`mcp_gateway_base_url`	No	MCP Gateway base URL
`is_dataservice_hosted`	No	Whether the deployment hosts its own data service
`jwt_sub_workspace_mapping`	No	JWT subject to workspace-slug mapping
`is_playground_proxy_allowed`	No	Whether Playground proxy traffic is allowed

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.

Changed1 schema field changedv0.12.2Oct 2, 2026

addedInput schema / properties / tags

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "propertyNames": {
+        "pattern": "^[a-zA-Z0-9_-]+$",
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Deployment tags, or null to create without tags"
+}

Addedv0.11.5Sep 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: the description warns that authentication and registry credentials are returned exactly once, exposed to the MCP transcript, and must be stored immediately and never logged. That is a critical, non-obvious behavioral trait that the structured fields do not convey. The 403 failure mode is also disclosed, complementing the openWorldHint/readOnlyHint annotations.

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

Conciseness3/5

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

The content is front-loaded and each sentence is substantive, but 'Enterprise-gated' is stated twice (at the start and again before the 403 detail), which is redundant. Minor editorial waste in an otherwise tight description.

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 14-parameter mutation that returns one-time credentials, the description covers the crucial operational caveat (secure storage) and the plan-gating failure. Output schema exists, so return-value explanation is not needed. Nothing essential for 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% with 14 well-described parameters, so the baseline is 3. The description adds the semantic point that the response carries credentials but offers no parameter-specific guidance beyond what the schema already documents.

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 (register a self-hosted Gateway deployment) and the context (onboarding a new control-plane target). Explicitly names the sibling it is not (list_deployments for existing registrations), which is exactly the differentiation needed in this large tool set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the when-to-use condition (onboarding a new target), the alternative (list_deployments for existing registrations), and the gating constraint (Enterprise-only, 403 on non-Enterprise plans). An agent knows both when to call it and when it will fail.

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

Deploy Server