Skip to main content
Glama
CodesWhat

portkey-admin-mcp

by CodesWhat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_usage_limit

Create a cumulative cost or token usage-limit policy with match conditions and grouping. Apply weekly, monthly, or lifetime resets to enforce budgets across API keys, workspaces, providers, and models.

Instructions

Create a cumulative cost or token usage-limit policy with non-empty conditions and grouping. A periodic reset can be weekly, monthly, or omitted for a cumulative lifetime limit.

Input Schema

NameRequiredDescriptionDefault
nameNoOptional policy display name
typeYesBudget type
group_byYesUsage grouping dimensions
conditionsYesPolicy match conditions
credit_limitYesMaximum cumulative usage
workspace_idNoWorkspace UUID scope
periodic_resetNoOptional reset schedule
alert_thresholdNoOptional alert threshold
organisation_idNoOrganisation UUID scope

Output Schema

NameRequiredDescriptionDefault
okYesWhether the tool call succeeded and returned structured data
dataNoStructured success payload when ok is true
errorNoStructured error payload when ok is false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.9
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed29 schema fields changedv0.11.5
    • addedInput schema / properties / alert_threshold / anyOf
      Added value: +[
+  {
+    "minimum": 0,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / alert_threshold / description
      Previous value: -"Percentage threshold (0-100) at which to send an alert"New value: +"Optional alert threshold"
    • removedInput schema / properties / alert_threshold / type
      Removed value: -"number"
    • changedInput schema / properties / conditions / description
      Previous value: -"Array of conditions that determine which requests this usage limit applies to"New value: +"Policy match conditions"
    • addedInput schema / properties / conditions / items / properties / excludes
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "minItems": 1,
+      "type": "array"
+    }
+  ],
+  "description": "Values to exclude"
+}
    • removedInput schema / properties / conditions / items / properties / field
      Removed value: -{
-  "description": "The field to match on (e.g., 'virtual_key', 'api_key', 'user_id', 'metadata.key')",
-  "type": "string"
-}
    • addedInput schema / properties / conditions / items / properties / key
      Added value: +{
+  "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"
+}
    • removedInput schema / properties / conditions / items / properties / operator
      Removed value: -{
-  "description": "The comparison operator (e.g., 'is', 'contains', 'is_not')",
-  "type": "string"
-}
    • addedInput schema / properties / conditions / items / properties / value / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "minItems": 1,
+    "type": "array"
+  }
+]
    • changedInput schema / properties / conditions / items / properties / value / description
      Previous value: -"The value to match against"New value: +"One value or several OR-matched values; use * for wildcard matching"
    • removedInput schema / properties / conditions / items / properties / value / type
      Removed value: -"string"
    • changedInput schema / properties / conditions / items / required
      Previous value: -[
-  "field",
-  "operator",
-  "value"
-]New value: +[
+  "key",
+  "value"
+]
    • addedInput schema / properties / conditions / minItems
      Added value: +1
    • changedInput schema / properties / credit_limit / description
      Previous value: -"The maximum allowed usage (cost in dollars or token count)"New value: +"Maximum cumulative usage"
    • removedInput schema / properties / credit_limit / exclusiveMinimum
      Removed value: -0
    • addedInput schema / properties / credit_limit / minimum
      Added value: +0
    • changedInput schema / properties / group_by / description
      Previous value: -"Array of fields to group the usage limit by (e.g., ['virtual_key'], ['api_key', 'user_id'])"New value: +"Usage grouping dimensions"
    • addedInput schema / properties / group_by / items / properties
      Added value: +{
+  "key": {
+    "description": "Counter grouping key such as api_key, workspace_id, virtual_key, provider, config, prompt, model, mcp_server, mcp_tool, or metadata.*",
+    "minLength": 1,
+    "type": "string"
+  }
+}
    • addedInput schema / properties / group_by / items / required
      Added value: +[
+  "key"
+]
    • changedInput schema / properties / group_by / items / type
      Previous value: -"string"New value: +"object"
    • addedInput schema / properties / group_by / minItems
      Added value: +1
    • changedInput schema / properties / name / description
      Previous value: -"Optional name for the usage limit"New value: +"Optional policy display name"
    • changedInput schema / properties / organisation_id / description
      Previous value: -"Organisation ID to scope the limit to"New value: +"Organisation UUID scope"
    • addedInput schema / properties / periodic_reset / anyOf
      Added value: +[
+  {
+    "enum": [
+      "monthly",
+      "weekly"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / periodic_reset / description
      Previous value: -"Automatically reset usage counters on this schedule"New value: +"Optional reset schedule"
    • removedInput schema / properties / periodic_reset / enum
      Removed value: -[
-  "monthly",
-  "weekly"
-]
    • removedInput schema / properties / periodic_reset / type
      Removed value: -"string"
    • changedInput schema / properties / type / description
      Previous value: -"What to limit: 'cost' (in dollars) or 'tokens'"New value: +"Budget type"
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Workspace ID to scope the limit to"New value: +"Workspace UUID scope"
  3. Addedv1.0.1
  4. Removed
  5. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare this is a non-destructive, non-idempotent mutation. The description adds useful semantics about cumulative lifetime limits when periodic_reset is omitted, but it doesn't mention side effects, permission requirements, or what happens on duplicate creation beyond the non-idempotent hint.

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 sentences, both front-loaded and free of repetition. The purpose comes first, followed by the reset semantics, with no wasted wording.

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 rich schema with 100% coverage, annotations, and an output schema, the description is complete enough for correct invocation. Minor gaps like not mentioning workspace/organisation scoping or alert_threshold are acceptable because the schema covers them.

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 already documents all nine parameters in detail. The description only clarifies the meaning of omitting periodic_reset (lifetime limit), which adds minor value beyond the schema's 'Optional reset schedule' wording.

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 uses a specific verb and resource ('Create a cumulative cost or token usage-limit policy'), making the operation clear. It implicitly distinguishes itself from rate-limit siblings by emphasizing 'cumulative' and periodic resets, though it doesn't name the alternative tool explicitly.

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

Usage Guidelines3/5

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

It states that conditions and grouping must be non-empty and explains reset options, which implies when the tool is applicable. However, it never says when to choose this over create_rate_limit or update_usage_limit, leaving the agent to infer the distinction.

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

Deploy Server

Other Tools