Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Replace targeting rules

update_targeting

Destructive

Replace a flag's full ordered targeting rules in one environment; pass the etag so concurrent edits aren't overwritten and omitted rules are removed.

Instructions

REPLACE all targeting rules of a flag in one environment (full PUT — rules not included are removed). Rules are evaluated in order. Get the current rules first with get_targeting. Pass ifMatch (the etag from get_targeting) so rules someone else changed meanwhile are not overwritten.

Input Schema

Name	Required	Description
`flag`	Yes	Flag key or id
`rules`	Yes	The complete ordered rule list; rules left out are deleted
`ifMatch`	No	etag from get_targeting. 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
`environment`	Yes	Environment key, e.g. production

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
`environment`	Yes
`rulesReplaced`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 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 / ifMatch

Added value: +{
+  "description": "etag from get_targeting. 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 / project / description
```
Added value: +"Project key"
```

addedInput schema / properties / rules / description

Added value: +"The complete ordered rule list; rules left out are deleted"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "environment": {
+      "type": "string"
+    },
+    "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"
+    },
+    "rulesReplaced": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "project",
+    "flag",
+    "environment",
+    "rulesReplaced"
+  ],
+  "type": "object"
+}

First observedv0.1.6Sep 16, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare destructiveHint=true, but the description discloses the crucial destructive semantics (rules omitted from the payload are deleted), rule evaluation order, and the optimistic-concurrency contract including the 412 refusal behavior. These are exactly the traits an agent needs and that annotations cannot express.

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 tight sentences with zero filler, and the most consequential fact — full replacement with deletion of omitted rules — is front-loaded in the first sentence.

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, concurrency-sensitive mutation the description covers destruction scope, ordering, prerequisite read, and conflict handling; with an output schema present it correctly omits return-shape detail. Nothing essential for correct invocation is missing.

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 baseline is 3; the schema already documents ifMatch's 412 behavior and the 'rules left out are deleted' semantics. The description reiterates rather than extends the per-parameter documentation, adding only the ordering note.

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 (REPLACE) with the resource (all targeting rules of a flag) and the scope (one environment), and the parenthetical clarifies the full-PUT semantics. This distinguishes it cleanly from get_targeting and manage_targeting_rule without needing to open either 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?

Explicitly prescribes the read-before-write workflow: call get_targeting first, then pass the etag as ifMatch. The condition that selects the alternative (single-rule edits via manage_targeting_rule) is only implied by the 'REPLACE all' framing rather than named, which keeps it just short of a 5.

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