Skip to main content
Glama
CodesWhat
by CodesWhat

create_api_key

Create a Portkey API key for authentication with configurable type, scopes, and limits. Key secret is returned once and must be stored securely.

Instructions

Create a Portkey API key for auth. Org keys grant broader access; workspace keys are scoped. WARNING: The key secret is returned ONCE in the tool result and will be visible in MCP transcripts and LLM context — store it securely immediately. Using the key grants access immediately according to its scopes, defaults, and limits. Workspace keys require workspace_id and user keys require user_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesKey type: 'organisation' for org-wide access or 'workspace' for workspace-scoped
sub_typeYesSub-type: 'user' for user-associated keys or 'service' for service accounts
nameYesDisplay name for the API key
descriptionNoOptional description for the key
workspace_idNoWorkspace ID (required for workspace-type keys)
user_idNoUser ID (required for user sub-type keys)
scopesYesPermission scopes for the key (e.g., ['logs.read', 'analytics.read'])
credit_limitNoCredit limit for usage
alert_thresholdNoAlert threshold percentage (0-100)
rate_limit_rpmNoRate limit in requests per minute
default_config_idNoDefault configuration ID to use with this key
default_metadataNoDefault metadata key-value pairs
alert_emailsNoEmail addresses for alerts
expires_atNoExpiration date in ISO 8601 format

Output Schema

TableJSON 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
Behavior5/5

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

Adds critical behavioral details beyond annotations: warns that the key secret is returned only once and visible in transcripts, and states that the key grants immediate access. No contradiction with annotations (readOnlyHint=false, etc.).

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?

Four sentences with clear structure: purpose, type distinction, security warning, activation behavior, and requirements. Front-loaded with most important info.

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?

Covers purpose, security, activation, and key requirements. With output schema present and 14 parameters, the description is adequate but could mention optional fields like rate limits or defaults.

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% with clear descriptions for each parameter. The description reinforces key constraints (workspace_id required for workspace type, user_id for user sub-type) and scopes, adding marginal value over schema.

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?

Explicitly states 'Create a Portkey API key for auth' and distinguishes between org and workspace keys. Clearly differentiates from sibling tools like delete_api_key and update_api_key.

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?

Provides context on when to use each key type (org vs workspace) and prerequisites (workspace_id for workspace keys, user_id for user sub-type). However, does not contrast with alternatives like create_virtual_key.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CodesWhat/portkey-admin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server