feat(mcp): report the release-condition change from update-feature-flag

products/feature_flags/mcp/tools.yaml

@@ -859,6 +859,11 @@ tools:
             property filter on an existing condition, such as an `is_not` filter, removes access from some users who
             match that condition today. Add a property filter to an existing condition only when the user asks to
             restrict access. When the request can mean either, ask the user which one they mean before you write.
+
+
+            When you send `filters`, the response includes `filters_change`. Read its `summary`. When
+            `filters_change.narrows` is true, tell the user which condition now serves fewer users, and confirm that
+            they asked to restrict access.
         include_params:
             - key
             - name

services/mcp/schema/tool-definitions-all.json

@@ -13774,7 +13774,7 @@
         "feature_flag_behavior": "enable"
     },
     "update-feature-flag": {
-        "description": "Update a feature flag by numeric ID (partial update: only the fields you include are changed). Use this for edits that have no dedicated tool, such as property filters, adding and removing release conditions, variant definitions, payloads, tags and the description.\n\nPrefer a dedicated tool whenever the request matches one. `feature-flag-enable`, `feature-flag-disable`, `feature-flag-archive` and `feature-flag-unarchive` each change one state field and send no `filters`. A targeting change someone else made between your read and your write is therefore not overwritten. Send `active` or `archived` here only when the same request also changes targeting or another field, so the whole edit lands in one write.\n\n`feature-flag-set-release-condition-rollout` changes one release condition's percentage and `feature-flag-roll-out-to-everyone` serves the flag to its whole audience. Both send no `filters` and both refuse the write when the flag changed after the version you read, so a concurrent edit cannot be lost. This tool sends no `version`, so it writes even when the flag changed after your read. It replaces the whole `filters` object with your copy of it. Use it for a rollout change only when those two tools cannot express it, such as changing the split between variants while leaving the audience alone.\n\nRollout conditions, variants, and payloads live in the structured `filters` param, and sending `filters` replaces the whole object, so read the flag first and merge your change. When the flag targets groups, keep `type: \"group\"`, `group_type_index`, and `filters.aggregation_group_type_index` in what you send; if you omit them this tool restores them from the existing flag so group targeting is not silently converted to person targeting. Use `feature-flag-get-definition-by-key` when you have the string key: it returns the numeric ID and the full definition in one call. Use `feature-flag-get-definition` when you already have the ID. To apply a change at a future time instead, use `scheduled-changes-create`.\n\nRelease conditions combine with OR: a user who matches any condition gets the flag, subject to that condition's rollout percentage. Property filters inside one condition combine with AND. To give more users access, add their values to an existing `exact` property filter, or add a new release condition. A new property filter on an existing condition, such as an `is_not` filter, removes access from some users who match that condition today. Add a property filter to an existing condition only when the user asks to restrict access. When the request can mean either, ask the user which one they mean before you write.",
+        "description": "Update a feature flag by numeric ID (partial update: only the fields you include are changed). Use this for edits that have no dedicated tool, such as property filters, adding and removing release conditions, variant definitions, payloads, tags and the description.\n\nPrefer a dedicated tool whenever the request matches one. `feature-flag-enable`, `feature-flag-disable`, `feature-flag-archive` and `feature-flag-unarchive` each change one state field and send no `filters`. A targeting change someone else made between your read and your write is therefore not overwritten. Send `active` or `archived` here only when the same request also changes targeting or another field, so the whole edit lands in one write.\n\n`feature-flag-set-release-condition-rollout` changes one release condition's percentage and `feature-flag-roll-out-to-everyone` serves the flag to its whole audience. Both send no `filters` and both refuse the write when the flag changed after the version you read, so a concurrent edit cannot be lost. This tool sends no `version`, so it writes even when the flag changed after your read. It replaces the whole `filters` object with your copy of it. Use it for a rollout change only when those two tools cannot express it, such as changing the split between variants while leaving the audience alone.\n\nRollout conditions, variants, and payloads live in the structured `filters` param, and sending `filters` replaces the whole object, so read the flag first and merge your change. When the flag targets groups, keep `type: \"group\"`, `group_type_index`, and `filters.aggregation_group_type_index` in what you send; if you omit them this tool restores them from the existing flag so group targeting is not silently converted to person targeting. Use `feature-flag-get-definition-by-key` when you have the string key: it returns the numeric ID and the full definition in one call. Use `feature-flag-get-definition` when you already have the ID. To apply a change at a future time instead, use `scheduled-changes-create`.\n\nRelease conditions combine with OR: a user who matches any condition gets the flag, subject to that condition's rollout percentage. Property filters inside one condition combine with AND. To give more users access, add their values to an existing `exact` property filter, or add a new release condition. A new property filter on an existing condition, such as an `is_not` filter, removes access from some users who match that condition today. Add a property filter to an existing condition only when the user asks to restrict access. When the request can mean either, ask the user which one they mean before you write.\n\nWhen you send `filters`, the response includes `filters_change`. Read its `summary`. When `filters_change.narrows` is true, tell the user which condition now serves fewer users, and confirm that they asked to restrict access.",
         "category": "Feature flags",
         "feature": "flags",
         "summary": "Update feature flag",