portkey-admin-mcp

update_usage_limit

Modify a cumulative usage-limit policy's name, conditions, credit limit, alert threshold, or reset schedule. Replace the full condition set or reset usage for a specific grouped value.

Instructions

Update a cumulative usage-limit policy's name, description, complete condition set, credit limit, alert threshold, reset schedule, next reset time, or one grouped value's usage. periodic_reset and periodic_reset_days are mutually exclusive; conditions replace the existing set.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Usage-limit policy UUID
`name`	No	Replacement display name
`conditions`	No	Complete replacement condition set
`description`	No	Replacement description, or null to clear it
`credit_limit`	No	Replacement cumulative maximum
`periodic_reset`	No	Replacement reset schedule
`alert_threshold`	No	Replacement alert threshold
`next_usage_reset_at`	No	Next reset timestamp in ISO 8601 format, or null to clear it
`periodic_reset_days`	No	Custom reset interval in days, or null to clear it
`reset_usage_for_value`	No	Grouped value whose usage should reset

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.12.2Oct 2, 2026

addedInput schema / properties / conditions

Added value: +{
+  "description": "Complete replacement condition set",
+  "items": {
+    "properties": {
+      "excludes": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "items": {
+              "type": "string"
+            },
+            "minItems": 1,
+            "type": "array"
+          }
+        ],
+        "description": "Values to exclude"
+      },
+      "key": {
+        "description": "Match key such as api_key, virtual_key, provider, config, prompt, model, endpoint_type, mcp_server, mcp_tool, workspace_id, or metadata.*",
+        "minLength": 1,
+        "type": "string"
+      },
+      "value": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "items": {
+              "type": "string"
+            },
+            "minItems": 1,
+            "type": "array"
+          }
+        ],
+        "description": "One value or several OR-matched values; use * for wildcard matching"
+      }
+    },
+    "required": [
+      "key",
+      "value"
+    ],
+    "type": "object"
+  },
+  "minItems": 1,
+  "type": "array"
+}

addedInput schema / properties / description

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 500,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Replacement description, or null to clear it"
+}

addedInput schema / properties / name / maxLength
```
Added value: +255
```

addedInput schema / properties / next_usage_reset_at

Added value: +{
+  "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": "Next reset timestamp in ISO 8601 format, or null to clear it"
+}

addedInput schema / properties / periodic_reset_days

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 365,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Custom reset interval in days, or null to clear it"
+}

Changed14 schema fields changedv0.11.5Sep 8, 2026

addedInput schema / properties / alert_threshold / anyOf

Added value: +[
+  {
+    "minimum": 0,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / alert_threshold / description

Previous value: -"New alert threshold percentage (0-100)"New value: +"Replacement alert threshold"

removedInput schema / properties / alert_threshold / type
```
Removed value: -"number"
```

changedInput schema / properties / credit_limit / description

Previous value: -"New maximum allowed usage value"New value: +"Replacement cumulative maximum"

removedInput schema / properties / credit_limit / exclusiveMinimum
```
Removed value: -0
```
addedInput schema / properties / credit_limit / minimum
```
Added value: +0
```

changedInput schema / properties / id / description

Previous value: -"The unique identifier of the usage limit"New value: +"Usage-limit policy UUID"

addedInput schema / properties / id / minLength
```
Added value: +1
```

changedInput schema / properties / name / description

Previous value: -"New name for the usage limit"New value: +"Replacement display name"

addedInput schema / properties / periodic_reset / anyOf

Added value: +[
+  {
+    "enum": [
+      "monthly",
+      "weekly"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / periodic_reset / description

Previous value: -"New periodic reset schedule"New value: +"Replacement reset schedule"

removedInput schema / properties / periodic_reset / enum
```
Removed value: -[
-  "monthly",
-  "weekly"
-]
```
removedInput schema / properties / periodic_reset / type
```
Removed value: -"string"
```

changedInput schema / properties / reset_usage_for_value / description

Previous value: -"Reset usage counters for a specific group_by value"New value: +"Grouped value whose usage should reset"

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

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare it as a non-read-only, non-idempotent mutation, so the description's real added value is the replacement semantics: 'conditions replace the existing set' and the mutual-exclusivity rule between the two reset fields. These are non-obvious mutation behaviors that materially affect how the call should be formed.

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?

Two dense sentences, front-loaded with the action and field list, followed immediately by the two hard constraints. No filler, though the first sentence is a long enumeration that could be lightly tightened.

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?

For a 10-param mutation tool with full schema coverage, an output schema, and annotations, the description covers the action, the replacement semantics, and the key constraint. The missing piece is routing guidance against sibling update/reset tools, which is a modest gap.

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 baseline is 3 and the schema does the heavy lifting. The description still adds value by grouping the updatable fields and stating the periodic_reset/periodic_reset_days exclusivity, a constraint the schema itself does not enforce.

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?

Opens with a specific verb+resource ('Update a cumulative usage-limit policy') and enumerates exactly which fields can change, so the agent knows the scope without opening the schema. It does not differentiate from close siblings like update_rate_limit or reset_usage_limit_entity, which keeps it just short of a 5.

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

Usage Guidelines2/5

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

There is a constraint note (periodic_reset and periodic_reset_days are mutually exclusive) but no guidance on when to use this tool versus create_usage_limit, reset_usage_limit_entity, or update_rate_limit. The agent must infer usage context entirely from the name.

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

Deploy Server