Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Create or update an environment

manage_environment

Destructive

Create a project environment or update its name, color, sort order, or change-reason settings. Use it to configure environments so every team can organize and track feature flag rollouts.

Instructions

Create an environment in a project, or change its name, color or sort order. action=create needs key + name; action=update needs environment and changes only the fields you pass. The key is immutable. Environments cannot be deleted from here. require_change_reason makes every write to the environment need a reason, and require_confirmation makes the dashboard ask for confirmation first; omit either on update to leave it unchanged. Turning either off needs an Admin or Owner token and a reason. A new environment needs an SDK key before apps can use it (manage_sdk_key).

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>"
    },
    "name": "manage_environment"
  }
}

Input Schema

Name	Required	Description
`key`	No	New environment key, required for create; immutable afterwards
`name`	No	Display name; required for create
`color`	No	Hex color shown in the dashboard, e.g. #22c55e
`action`	Yes	create needs key + name; update needs environment
`reason`	No	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.
`project`	Yes	Project key
`sortOrder`	No	Position in environment lists, lowest first
`environment`	No	Environment key to update; required for update
`require_confirmation`	No	Require explicit confirmation in the dashboard before changes to this environment. Omit on update to leave unchanged
`require_change_reason`	No	Mark the environment critical: every change to it must carry a reason. Omit on update to leave unchanged

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.7.0Nov 5, 2026

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"
+}

addedInput schema / properties / require_change_reason

Added value: +{
+  "description": "Mark the environment critical: every change to it must carry a reason. Omit on update to leave unchanged",
+  "type": "boolean"
+}

addedInput schema / properties / require_confirmation

Added value: +{
+  "description": "Require explicit confirmation in the dashboard before changes to this environment. Omit on update to leave unchanged",
+  "type": "boolean"
+}

addedOutput schema / $defs / PublicEnvironmentResponse / properties / color / description
```
Added value: +"The environment's display color, or null."
```
addedOutput schema / $defs / PublicEnvironmentResponse / properties / id / description
```
Added value: +"The environment's id."
```
addedOutput schema / $defs / PublicEnvironmentResponse / properties / key / description
```
Added value: +"The environment's key."
```
addedOutput schema / $defs / PublicEnvironmentResponse / properties / name / description
```
Added value: +"The environment's display name."
```

addedOutput schema / $defs / PublicEnvironmentResponse / properties / requireChangeReason

Added value: +{
+  "description": "Require a change reason (X-Intent-Reason) on every change to flags in this environment. Business plan and above.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / $defs / PublicEnvironmentResponse / properties / requireConfirmation

Added value: +{
+  "description": "Ask dashboard users to type the environment key before a change lands. Dashboard only; not enforced by the API.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / $defs / PublicEnvironmentResponse / properties / sortOrder / description
```
Added value: +"Position among the project's environments."
```

changedOutput schema / anyOf

Previous value: -[
-  {
-    "$ref": "#/$defs/PublicEnvironmentResponse"
-  },
-  {
-    "properties": {
-      "color": {
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "environment": {
-        "type": "string"
-      },
-      "name": {
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "sortOrder": {
-        "type": [
-          "integer",
-          "null"
-        ]
-      },
-      "updated": {
-        "type": "boolean"
-      }
-    },
-    "required": [
-      "environment",
-      "updated"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "$ref": "#/$defs/PublicEnvironmentResponse"
+  },
+  {
+    "properties": {
+      "color": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "environment": {
+        "type": "string"
+      },
+      "name": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "requireChangeReason": {
+        "type": "boolean"
+      },
+      "requireConfirmation": {
+        "type": "boolean"
+      },
+      "sortOrder": {
+        "type": [
+          "integer",
+          "null"
+        ]
+      },
+      "updated": {
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "environment",
+      "updated"
+    ],
+    "type": "object"
+  }
+]

Addedv0.3.0Oct 18, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond destructiveHint=true, the description discloses that the key is immutable, that updates are partial (only passed fields change), that omit-on-update leaves a toggle unchanged, and that disabling require_change_reason/require_confirmation needs an Admin or Owner token plus a reason. That is real authorization and mutation-scope context the annotation alone does not convey.

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?

The create/update contract is front-loaded in the first two sentences, followed by constraints and then the permission caveat. Dense but nearly every clause carries actionable information; the SDK-key pointer could arguably be trimmed as it duplicates schema-level guidance.

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?

For a 10-parameter dual-mode mutation tool with an output schema and a destructiveHint annotation, the description covers mode selection, partial-update semantics, immutability, and the elevated-permission path. Return behavior is rightly omitted since an output schema exists.

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 schema already documents key immutability, the omit-to-leave-unchanged behavior, and the enum branches. The description restates most of this rather than adding new semantics such as valid key formats or how sortOrder conflicts resolve, so it sits at the baseline.

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 opens with a specific verb+resource pair (create/update an environment in a project) and enumerates the mutable fields (name, color, sort order). It also sets a boundary ('Environments cannot be deleted from here') and points to the SDK-key sibling, so an agent can separate this from list_environments or manage_sdk_key without opening a schema.

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 concrete branch conditions: action=create needs key + name, action=update needs environment and only touches passed fields. It also flags the downstream step ('A new environment needs an SDK key before apps can use it (manage_sdk_key)'). It stops short of explicit when-not guidance beyond the no-delete note.

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