Featureflip

Official

by canopy-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Create, update, or delete a user segment

manage_segment

Destructive

Create, update, or delete reusable user segments referenced by targeting rules, using ifMatch checks to prevent overwriting concurrent changes.

Instructions

Manage reusable user segments, which targeting rules reference by userSegmentId. action=create needs key + name (+ conditions); action=update needs segment and changes only the fields you pass (conditions replaces the whole list; description: "" clears it); action=delete needs segment. On update, pass ifMatch (the etag from get_segment) so a change someone made since you read it is not overwritten. ifMatch is rejected on create and delete: the API cannot make those conditional.

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

Input Schema

Name	Required	Description
`key`	No	New segment key, required for create; immutable afterwards
`name`	No	Display name; required for create
`action`	Yes	create needs key + name; update and delete need segment
`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.
`ifMatch`	No	etag from get_segment. 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
`segment`	No	Segment key or id; required for update and delete
`conditions`	No	Conditions a user must match to be in the segment; on update, replaces the whole list
`description`	No	What the segment means; "" clears it

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field 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"
+}

Addedv0.3.0Oct 18, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The only annotation is destructiveHint=true, so the description has real room to add value, and it does: update is partial ('changes only the fields you pass'), conditions is a full replace, description "" clears the field, and ifMatch enforces optimistic concurrency with a 412 refusal. What it does not state is whether delete is permanent or recoverable, which matters most for a tool flagged destructive.

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?

A single dense paragraph front-loaded with the resource and its role, then the three action contracts in order, then the concurrency rule. Every clause carries operational information and nothing is repeated from the schema verbatim without purpose.

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 9-parameter mutation tool with three modes, the description covers action selection, field replacement semantics, and concurrency control, and an output schema exists so return values need no explanation. The remaining gap is authorization/audit context: the description never mentions that a reason may be mandatory in critical environments, which is a precondition an agent can trip over.

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 the baseline is 3; the description rises above it by consolidating scattered per-parameter docs into an action-oriented contract and by explaining the ifMatch lifecycle (supply it on update, it is rejected on create/delete because those cannot be made conditional). It adds no detail on the nested conditions item fields, but those are fully documented in the schema.

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?

Opens with a specific verb+resource ('Manage reusable user segments') and immediately adds the domain relationship ('which targeting rules reference by userSegmentId'), which separates it from list_segments and get_segment in the sibling set. The three supported actions are named explicitly, so an agent knows this is the mutation counterpart to the read tools.

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 a per-action recipe: create needs key + name (+ conditions), update needs segment, delete needs segment. It names the read tool to use first ('the etag from get_segment') and states the recovery path ('re-read and re-apply'), plus the negative case that ifMatch is rejected on create and delete. That is explicit when-to-use, when-not-to-use, and which sibling to pair with.

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