portkey-admin-mcp

create_rate_limit

Creates request or token rate-limit policies with match conditions and grouping keys for LLM or MCP-tool enforcement.

Instructions

Create a request or token rate-limit policy. Conditions and grouping must be non-empty; target llm uses model/provider keys, while target mcp_tools uses MCP server and tool keys.

Input Schema

Name	Required	Description
`name`	No	Optional policy display name
`type`	Yes	Counter type
`unit`	Yes	Counter reset interval
`value`	Yes	Maximum requests or tokens
`target`	No	LLM or MCP-tool enforcement target
`group_by`	Yes	Counter grouping dimensions
`conditions`	Yes	Policy match conditions
`workspace_id`	No	Workspace UUID scope
`organisation_id`	No	Organisation UUID scope

Output 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.

Changed2 schema fields changedv1.0.9Oct 26, 2026

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"

Changed25 schema fields changedv0.11.5Sep 8, 2026

changedInput schema / properties / conditions / description

Previous value: -"Array of conditions that determine which requests this rate 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 / group_by / description

Previous value: -"Array of fields to group the rate limit by (e.g., ['virtual_key'], ['api_key', 'user_id'])"New value: +"Counter 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 rate 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 / target

Added value: +{
+  "description": "LLM or MCP-tool enforcement target",
+  "enum": [
+    "llm",
+    "mcp_tools"
+  ],
+  "type": "string"
+}

changedInput schema / properties / type / description

Previous value: -"What to rate limit: 'requests' or 'tokens'"New value: +"Counter type"

changedInput schema / properties / unit / description

Previous value: -"Time unit: 'rpm' (per minute), 'rph' (per hour), or 'rpd' (per day)"New value: +"Counter reset interval"

changedInput schema / properties / unit / enum

Previous value: -[
-  "rpm",
-  "rph",
-  "rpd"
-]New value: +[
+  "rpm",
+  "rph",
+  "rpd",
+  "rpw"
+]

changedInput schema / properties / value / description

Previous value: -"The maximum allowed value per unit (e.g., 100 rpm)"New value: +"Maximum requests or tokens"

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

changedInput schema / properties / workspace_id / description

Previous value: -"Workspace ID to scope the limit to"New value: +"Workspace UUID scope"

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

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already disclose that this is a non-destructive, non-idempotent, open-world write operation. The description adds target-specific key semantics but largely repeats the schema's non-empty constraints and does not explain permissions, duplicate handling, or side effects.

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 efficient sentences, front-loaded with the core action and immediately followed by the most important configuration rules. No filler.

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 and full schema descriptions present, return values and most parameter details are already covered. The description supplies the key creation semantics and target-specific key mapping, though it could say more about scoping via workspace_id or organisation_id.

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. The description adds useful meaning by explicitly binding target values to key families: llm maps to model/provider keys, while mcp_tools maps to MCP server/tool keys, which helps configure group_by and conditions correctly.

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 states a specific verb and resource: creating a request or token rate-limit policy. It distinguishes the two counter types clearly. However, it does not differentiate this tool from sibling tools such as create_usage_limit or update_rate_limit.

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?

The description explains creation semantics and validation constraints but gives no explicit guidance on when to use this tool versus alternatives like create_usage_limit or update_rate_limit. An agent must infer the choice from the tool name alone.

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

Deploy Server