Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Add, update, or remove a variation

manage_variation

Destructive

Add, update, or remove a flag's variations to control its values and targeting. For update or remove, get variationId first; add requires a key and value.

Instructions

Manage a flag's variations. action=add requires key + value; action=update/remove require variationId (get ids via get_flag). Removing a variation fails with VARIATION_HAS_DEPENDENTS if other flags depend on it.

Input Schema

Name	Required	Description
`key`	No	Required for add; immutable afterwards
`flag`	Yes	Flag key or id
`name`	No	Display name
`value`	No	Variation value serialized as a string; required for add
`action`	Yes	add needs key + value; update and remove need variationId
`project`	Yes	Project key
`description`	No	What this variation means
`variationId`	No	Required for update/remove

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.3.0Oct 18, 2026

addedInput schema / properties / action / description

Added value: +"add needs key + value; update and remove need variationId"

addedInput schema / properties / description / description
```
Added value: +"What this variation means"
```
addedInput schema / properties / flag / description
```
Added value: +"Flag key or id"
```
addedInput schema / properties / name / description
```
Added value: +"Display name"
```
addedInput schema / properties / project / description
```
Added value: +"Project key"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$defs": {
+    "ActionCapability": {
+      "description": "One entry in a resource's `_actions` block: may the caller perform it, and if not, why.",
+      "properties": {
+        "allowed": {
+          "type": [
+            "boolean",
+            "null"
+          ]
+        },
+        "reason": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "PublicVariationResponse": {
+      "description": "A single variation on a flag, as returned in Variations.",
+      "properties": {
+        "_actions": {
+          "additionalProperties": {
+            "anyOf": [
+              {
+                "$ref": "#/$defs/ActionCapability"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "description": "Capability hints: which operations the authenticated caller may perform on this resource, each with allowed + optional reason. Computed from the caller's role and the resource's state. Injected at runtime; safe to ignore. Present only on top-level resource responses — nested occurrences (e.g. a rule inside a targeting-config response) do not carry it.",
+          "type": [
+            "object",
+            "null"
+          ]
+        },
+        "description": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "id": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "key": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "name": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "value": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "anyOf": [
+    {
+      "$ref": "#/$defs/PublicVariationResponse"
+    },
+    {
+      "properties": {
+        "updated": {
+          "description": "Id of the updated variation",
+          "type": "string"
+        }
+      },
+      "required": [
+        "updated"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "removed": {
+          "description": "Id of the removed variation",
+          "type": "string"
+        }
+      },
+      "required": [
+        "removed"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}

First observedv0.1.6Sep 16, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the destructiveHint=true annotation, the description discloses a concrete failure mode: removal fails with VARIATION_HAS_DEPENDENTS when other flags depend on it. That is useful operational context an agent could not infer from annotations or schema. It does not cover permission or rate-limit behavior, but destructive semantics are already signalled by the annotation.

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 compact sentences with zero filler. The core operation is stated first, then per-action parameter needs, then the notable failure mode — a well front-loaded structure.

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 present, return values need not be described, and the description covers action semantics and the dependency-failure case adequately. It omits what 'update' can modify versus the immutable key and how dependent flags should be handled, which are minor gaps for an 8-parameter tool.

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 coverage is 100% and the action property already documents 'add needs key + value; update and remove need variationId', so the description's conditional mapping is largely redundant with structured data. The only added value is the pointer to get_flag as the source of variationId, which is marginal. Baseline 3 applies.

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 names a specific resource (a flag's variations) and enumerates the three operations the tool spans, matching the title. It is clearly distinguishable from siblings like create_flag, get_flag, or update_flag_environment_config. The generic verb 'manage' with a multi-action enum keeps it from 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 Guidelines4/5

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

It gives action-conditional guidance ('action=add requires key + value; action=update/remove require variationId') and routes the agent to get_flag to obtain ids, which is genuine cross-tool usage guidance. It stops short of explicit when-not-to-use or alternatives to this tool for variation editing.

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