Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Update flag environment config

update_flag_environment_config

Destructive

Configure a feature flag's per-environment serving behavior by setting its default variation, serving strategy, and prerequisites.

Instructions

Update a flag's per-environment serving config: defaultVariationId (served on fallthrough, required), strategy (SingleVariation | PercentageRollout | TargetedRollout — only SingleVariation is currently supported at the environment level), and prerequisites. Percentage rollouts are configured on targeting rules via update_targeting.

Input Schema

Name	Required	Description
`flag`	Yes	Flag key or id
`project`	Yes	Project key
`strategy`	No	Serving strategy; only SingleVariation is currently supported here
`environment`	Yes	Environment key, e.g. production
`prerequisites`	No	Flags that must evaluate to the expected variation before this flag serves. Omit to leave existing prerequisites untouched; pass a list (possibly empty) to replace them wholesale.
`defaultVariationId`	Yes	Variation id to serve on fallthrough — required by the API

Output Schema

Name	Required	Description	Default
`flag`	Yes
`project`	Yes
`strategy`	No
`environment`	Yes
`prerequisites`	No
`defaultVariationId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.3.0Oct 18, 2026

addedInput schema / properties / environment / description
```
Added value: +"Environment key, e.g. production"
```
addedInput schema / properties / flag / description
```
Added value: +"Flag key or id"
```
addedInput schema / properties / project / description
```
Added value: +"Project key"
```

addedInput schema / properties / strategy / description

Added value: +"Serving strategy; only SingleVariation is currently supported here"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "defaultVariationId": {
+      "type": "string"
+    },
+    "environment": {
+      "type": "string"
+    },
+    "flag": {
+      "type": "string"
+    },
+    "prerequisites": {
+      "items": {
+        "properties": {
+          "expectedVariationKey": {
+            "type": "string"
+          },
+          "prerequisiteFlagKey": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "project": {
+      "type": "string"
+    },
+    "strategy": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "project",
+    "flag",
+    "environment",
+    "defaultVariationId"
+  ],
+  "type": "object"
+}

First observedv0.1.6Sep 16, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, so the mutation profile is known. The description adds the useful constraint that only SingleVariation is supported at this level, but does not say whether changes take effect immediately for live traffic, whether prerequisites are replaced or merged (that lives only in the schema), or what permissions are needed. Value-add beyond annotations is modest.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the operation and its field list, with the alternative-tool note at the end. The nested parentheticals are slightly heavy but every clause carries information.

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 return values need no explanation, and the required parameter plus the strategy limitation are covered. What's missing is the blast radius — whether the update is immediate, partial, or wholesale for prerequisites — which matters for a destructive-flagged mutation.

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 all six parameters are already documented, including the prerequisite replace-vs-omit semantics and the fallthrough meaning of defaultVariationId. The description largely restates those schema notes rather than adding new meaning, so baseline 3 applies.

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 a precise verb and resource — 'Update a flag's per-environment serving config' — and enumerates the exact settings affected (defaultVariationId, strategy, prerequisites). This is clearly distinguishable from siblings like update_flag (flag-level) and update_targeting (rule-level).

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?

Explicitly routes percentage rollout work away from this tool: 'Percentage rollouts are configured on targeting rules via update_targeting.' That is a concrete alternative with a condition. It doesn't cover when to prefer this over update_flag or toggle_flag, so not a full 5.

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