portkey-admin-mcp

update_usage_limit

Adjust an existing cumulative usage-limit policy by changing its name, credit limit, alert threshold, reset schedule, or resetting usage for a grouped value.

Instructions

Update a cumulative usage-limit policy's name, credit limit, alert threshold, reset schedule, or one grouped value's usage. Conditions and grouping aren't mutable in the public contract.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Usage-limit policy UUID
`name`	No	Replacement display name
`credit_limit`	No	Replacement cumulative maximum
`periodic_reset`	No	Replacement reset schedule
`alert_threshold`	No	Replacement alert threshold
`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.

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

A4.4/5.0

Behavior4/5

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

Annotations already indicate this is a non-read-only, non-idempotent operation, so the description's task is lighter. It adds useful behavioral context by clarifying which fields are updatable and explicitly stating that conditions/grouping cannot be modified, which is not evident from the schema alone. The description does not contradict the annotations.

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?

Two tight sentences with no filler. The primary action and resource are front-loaded, followed by the list of mutable fields, and then the key limitation. Every clause earns its place.

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?

With an output schema present, full parameter description coverage, and annotations covering the safety profile, the description provides sufficient context for a correct call. It clearly communicates the mutable surface and the one hard restriction. A minor gap is not distinguishing when to use update_usage_limit versus the closely related reset_usage_limit_entity.

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?

The schema has 100% coverage and each parameter already has a concise description. The tool description adds value by grouping the parameters semantically: name, credit limit, alert threshold, reset schedule are 'replacements,' while reset_usage_for_value is framed as resetting 'one grouped value's usage.' It also explains why there are no condition/grouping parameters: they are not mutable.

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 uses a specific verb ('Update') and identifies a clear resource ('cumulative usage-limit policy'), enumerating the exact mutable fields: name, credit limit, alert threshold, reset schedule, or one grouped value's usage. It further distinguishes itself by explicitly stating that conditions and grouping are not mutable, which prevents confusion with related usage-limit tools.

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 context: this tool updates an existing usage-limit policy's allowed attributes. It also provides an explicit exclusion ('Conditions and grouping aren't mutable in the public contract'), signaling what cannot be changed. However, it does not name a specific alternative such as reset_usage_limit_entity for the grouped-value reset case, leaving some routing decision to the agent.

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

Deploy Server