Skip to main content
Glama
Sign In
Featureflip

Featureflip

Official
by canopy-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create, rename, or revoke an SDK key

manage_sdk_key
Destructive

Create, rename, or revoke environment SDK keys for Featureflip; revoke stops flag updates immediately, so rotate by creating and deploying a new key before revoking the old one.

Instructions

Manage an environment's SDK keys. action=create needs name + type and returns the full key ONCE (ServerSide for backend SDKs, ClientSide for browser/mobile). action=rename needs sdkKey and changes only the fields you pass. action=revoke needs sdkKey and stops the key working immediately; apps still using it lose flag updates; revoking a critical environment's key needs a reason. To rotate: create a new key, deploy it, then revoke the old one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "project": "<project>",
      "environment": "<environment>"
    },
    "name": "manage_sdk_key"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoKey name; required for create
typeNoRequired for create: ServerSide for backend SDKs, ClientSide for browser/mobile SDKs
actionYescreate needs name + type; rename and revoke need sdkKey
reasonNoWhy you are making this change. Recorded in the audit log, and required when the environment (or, for project-wide changes, any environment in the project) is marked critical.
sdkKeyNoSDK key id (see list_sdk_keys); required for rename and revoke
projectYesProject key
descriptionNoWhat the key is used for; "" clears it
environmentYesEnvironment key, e.g. production

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.0
    • addedInput schema / properties / reason
      Added value: +{
+  "description": "Why you are making this change. Recorded in the audit log, and required when the environment (or, for project-wide changes, any environment in the project) is marked critical.",
+  "type": "string"
+}
  2. Addedv0.3.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true; the description adds the critical operational facts: the full key is returned ONCE, revoke takes effect immediately, dependent apps stop receiving flag updates, and critical environments require a reason. These are exactly the consequences an agent must know before a destructive call.

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?

Front-loaded with the resource, then organized per action in parallel sentences, ending with the rotation workflow. Every sentence carries operational content with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all three action modes, their prerequisites, side effects, and the rotation procedure; an output schema exists so return-shape explanation is unnecessary. Nothing needed to invoke this destructive multi-mode tool correctly is missing.

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 still adds meaning beyond the schema with 'changes only the fields you pass' for rename and the create-needed pairing of name + type, though most other requirements are already documented in the schema descriptions.

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?

States the specific resource (an environment's SDK keys) and the three concrete operations (create, rename, revoke), each tied to an action value. It is clearly distinguishable from the sibling list_sdk_keys, which only enumerates keys.

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

Usage Guidelines5/5

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

Gives explicit conditions per action (create needs name + type, rename/revoke need sdkKey) and adds procedural guidance for rotation: create, deploy, then revoke. This tells an agent not just when to call each mode but the correct ordering, which no other field provides.

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