Skip to main content
Glama
Sign In
Featureflip

Featureflip

Official
by canopy-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add, update, remove, or reorder one targeting rule

manage_targeting_rule
Destructive

Edit a single targeting rule without replacing all rules. Add, update, remove, or reorder one rule to change conditions, rollout percentage, or evaluation order.

Instructions

Edit a single targeting rule instead of replacing them all with update_targeting. action=add needs rule (appended last); action=update needs ruleId + rule and changes only the fields you pass (conditionGroups replaces the rule's groups; to clear rolloutPercentage or userSegmentId use update_targeting); action=remove needs ruleId; action=reorder needs ruleIds, every existing rule id exactly once, in the new order. Rule ids come from get_targeting.

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>",
      "flag": "<flag>",
      "environment": "<environment>"
    },
    "name": "manage_targeting_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
flagYesFlag key or id
ruleNoRule fields; required for add and update
actionYesadd needs rule; update needs ruleId + rule; remove needs ruleId; reorder needs ruleIds
reasonNoWhy 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.
ruleIdNoRule id from get_targeting; required for update and remove
projectYesProject key
ruleIdsNoEvery rule id exactly once, in evaluation order; required for reorder
environmentYesEnvironment key, e.g. production

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.0
    • 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"
+}
  2. Changed2 schema fields changedv0.5.0
    • addedInput schema / properties / rule / properties / bucketBy
      Added value: +{
+  "description": "Context attribute the rollout hashes on (default `user_id`; `userId` is accepted as an alias). Visitors whose context lacks it skip this rule, even at 100%. Changing it reshuffles who is in the rollout. Omit to keep the current value.",
+  "maxLength": 255,
+  "minLength": 1,
+  "type": "string"
+}
    • addedOutput schema / $defs / PublicTargetingRuleResponse / properties / bucketBy
      Added value: +{
+  "description": "Context attribute the rollout hashes on (default `user_id`; `userId` is accepted as an alias). A context without it skips this rule, even at 100%. Lookup is exact and case-sensitive, except `user_id`/`userId`, which both read the user id.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  3. Addedv0.3.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, and the description adds genuinely useful semantics beyond that: update is a partial patch ('changes only the fields you pass'), conditionGroups wholly replaces existing groups, add appends at the end, and reorder demands every existing id exactly once. It stops short of describing consequences of a bad reorder or the audit-log/critical-environment requirement, which lives only in the schema.

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?

Front-loaded with the core distinction from update_targeting, then a compact semicolon-delimited per-action breakdown. Dense but every clause carries new information; the nested parentheticals make it slightly harder to scan than a bulleted structure would be.

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 not be explained, and the description covers the multi-action branching that is the main source of invocation error for an 8-parameter tool with nested objects. The only material omission is the audit-log/critical-environment implication of the reason parameter, which is deferred entirely to the schema.

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; the description earns above baseline by encoding action-conditional parameter coupling and the replacement-versus-merge behavior of conditionGroups, which the schema cannot express. It does not, however, explain ruleIds ordering semantics beyond the schema text or the reason parameter's critical-environment rule.

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 and resource ('Edit a single targeting rule') and immediately contrasts scope with the sibling 'instead of replacing them all with update_targeting'. An agent can distinguish this from update_targeting without opening 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Spells out the required parameters per action (add→rule appended last, update→ruleId+rule, remove→ruleId, reorder→ruleIds), names the fallback for clearing fields ('to clear rolloutPercentage or userSegmentId use update_targeting'), and points to get_targeting as the id source. This is explicit when-to-use and when-not-to-use routing.

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

Deploy Server

Other Tools