Skip to main content
Glama
CodesWhat

portkey-admin-mcp

by CodesWhat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_provider

Creates a workspace provider backed by an org integration. Set independent credit, rate, and usage limits with expiration to control how that workspace accesses the integration's key.

Instructions

Create a workspace provider backed by an org integration. The provider inherits the integration key, but its limits and expiration are enforced independently for that workspace. Returns the new provider id and slug.

Input Schema

NameRequiredDescriptionDefault
nameYesDisplay name for the provider
noteNoOptional note or description for the provider
slugNoCustom slug for the provider. Auto-generated with random suffix if omitted
expires_atNoExpiration date in ISO 8601 format
credit_limitNoCredit limit for usage
workspace_idNoWorkspace ID - required when using organization admin API keys
integration_idYesIntegration slug for the provider (e.g., 'openai', 'anthropic', 'azure-openai')
periodic_resetNoPeriod for resetting usage limits: 'monthly' or 'weekly'. Defaults to 'monthly'.
alert_thresholdNoAlert threshold percentage (0-100)
rate_limit_unitNoMust be provided together with rate_limit_value. Values: 'rpm' (requests/min), 'rph' (requests/hour), or 'rpd' (requests/day).
rate_limit_valueNoMust be provided together with rate_limit_unit.
usage_limit_typeNoType of usage limit: 'cost' (monetary) or 'tokens' (token count). Defaults to 'cost'.

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. Addedv1.0.1
  3. Removed
  4. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Goes beyond the annotations by explaining that the provider inherits the integration key while limits and expiration are enforced independently per workspace – a real behavioral trait an agent wouldn't infer from the schema. Annotations already carry the safety profile (non-idempotent, non-destructive, open-world), so remaining gaps like permission requirements are minor.

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?

Three tight sentences, front-loaded with the core action, then the key semantic distinction, then the return value. No wasted words.

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?

An output schema exists, so the return description is a bonus rather than a necessity. The description adequately frames a 12-param creation tool's core semantics, though it doesn't touch the org-admin workspace_id nuance or rate/usage limit interplay.

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 parameters are already well documented and the baseline is 3. The description's note about inheriting the integration key and independent limit enforcement adds indirect meaning but no direct per-parameter clarification.

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?

States a specific verb+resource ('Create a workspace provider') and adds a qualifying relationship ('backed by an org integration') that separates it from create_integration. It does not explicitly name sibling alternatives, so it falls 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 Guidelines3/5

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

The 'backed by an org integration' framing implies the key precondition (an existing integration_id is needed), but the description never says when to use create_provider versus update_provider or how it relates to workspace scoping. Usage is only implied.

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