Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Update feature flag metadata

update_flag

Destructive

Edit a flag's metadata—name, description, tags, or client-side visibility—without changing its key, type, or targeting. Pass ifMatch to prevent overwriting concurrent changes.

Instructions

Update flag name/description/tags/clientSideVisible. Changes only the fields you pass and keeps the rest; pass description: "" to clear it. Key and type are immutable. Use toggle_flag / update_targeting for behavior changes. Pass ifMatch (the etag from get_flag) to refuse the write if the flag changed since you read it.

Input Schema

Name	Required	Description
`flag`	Yes	Flag key or id
`name`	No	New display name
`tags`	No	Replaces the whole tag list
`ifMatch`	No	etag from get_flag. The write is refused with 412 if the resource changed since that read; re-read and re-apply. Omit to write unconditionally.
`project`	Yes	Project key
`description`	No	New description; "" clears it
`clientSideVisible`	No	Expose to client-side SDKs (browser/mobile); false hides the flag from them entirely

Output Schema

Name	Required	Description
`etag`	No	ETag of what this write left behind. Pass it as ifMatch on the next update to chain writes without re-reading. Absent when the API sent none; read the resource again before the next conditional write.
`flag`	Yes
`project`	Yes
`updated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.3.0Oct 18, 2026

addedInput schema / properties / clientSideVisible / description

Added value: +"Expose to client-side SDKs (browser/mobile); false hides the flag from them entirely"

addedInput schema / properties / description / description
```
Added value: +"New description; \"\" clears it"
```

addedInput schema / properties / ifMatch

Added value: +{
+  "description": "etag from get_flag. The write is refused with 412 if the resource changed since that read; re-read and re-apply. Omit to write unconditionally.",
+  "type": "string"
+}

addedInput schema / properties / name / description
```
Added value: +"New display name"
```
addedInput schema / properties / project / description
```
Added value: +"Project key"
```
addedInput schema / properties / tags / description
```
Added value: +"Replaces the whole tag list"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "etag": {
+      "description": "ETag of what this write left behind. Pass it as ifMatch on the next update to chain writes without re-reading. Absent when the API sent none; read the resource again before the next conditional write.",
+      "type": "string"
+    },
+    "flag": {
+      "type": "string"
+    },
+    "project": {
+      "type": "string"
+    },
+    "updated": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "project",
+    "flag",
+    "updated"
+  ],
+  "type": "object"
+}

First observedv0.1.6Sep 16, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only supply destructiveHint=true; the description carries the real behavioral load, disclosing partial-update semantics ('changes only the fields you pass'), the empty-string clear convention, field immutability, and optimistic-concurrency behavior (refused write / etag from get_flag). This is well beyond what the annotation states.

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 dense sentences, each doing distinct work: field list, merge/clear semantics, immutability, alternative tools, then concurrency control. No filler and the mutable-field list is front-loaded.

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?

For a destructive partial-update tool with an output schema already documenting returns, the description covers everything needed to call it correctly: scope, merge behavior, immutability constraints, concurrency guard, and sibling alternatives.

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 baseline is 3, but the description adds genuine meaning the schema lacks: merge semantics ('changes only the fields you pass and keeps the rest') and the description:"" clearing convention. The ifMatch semantics largely restate the schema's own text.

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 specific verb (update) plus resource (flag metadata) and enumerates exactly which fields are mutable (name/description/tags/clientSideVisible). It also explicitly separates itself from sibling tools that change behavior (toggle_flag, update_targeting), so an agent can route correctly without opening schemas.

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 when-to-use-this vs when-to-use-something-else: behavior changes go to toggle_flag / update_targeting, and key/type are declared immutable. The conditional ifMatch guidance ('pass ... to refuse the write if the flag changed') tells the agent when to include a parameter.

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