How to use GrowthBook's MCP server to kill a broken feature instantly

A feature flag can remove a broken experience without a code deploy, but “instantly” describes the operator path—not a guarantee that every cached client observes the new payload at the same moment.

GrowthBook's MCP server lets an on-call engineer use a compatible AI client to inspect a flag, prepare an environment-level disable, publish it through the organization's review policy, and verify the resulting state. The current flag-toggle skill is explicitly designed for this kill-switch workflow.

The feature must already be behind a flag. The flag's default must be safe. The operator must know the exact environment. The MCP token must have the right project permissions. GrowthBook's review policy still applies. SDK propagation must be verified.

Those constraints do not make the kill switch slow. They make it dependable.

Know what GrowthBook's kill switch changes

GrowthBook separates environment enablement from rule enablement:

• Environment toggle: determines whether the flag evaluates at all in that environment.
• Rule-level enabled state: determines whether one targeting, rollout, or experiment rule participates.
• Default value: the value used when no rule matches and the behavior the application should treat as its safe baseline.

When flag-toggle disables a flag in production, all rules stop evaluating there. Users who previously matched force, rollout, experiment, prerequisite, or scheduled rules move to the default behavior.

That is broader than pausing a ramp or disabling one rule. It is the correct control when the entire feature is implicated. It can be the wrong control when only one audience or one experimental treatment is broken.

Use the smallest intervention:

The GrowthBook feature flags page connects these controls with ramp schedules and monitoring. The current GrowthBook skills repository defines the exact agent workflows.

Prepare the kill path before the incident

An incident is a bad time to discover that “off” is unsafe. For every release or operational flag, record:

• exact flag ID
• owning project and team
• production environment ID
• value type and default
• what users see when disabled
• SDKs and services that consume it
• expected refresh or streaming behavior
• approval and reviewer path
• fallback if GrowthBook or MCP is unavailable

Test the disabled state in CI and staging. A community report about a months-old flag breaking production highlights why dormant branches need ongoing tests, ownership, and expiration—not only an emergency switch.

Use GrowthBook's feature flag best practices to distinguish short-lived release flags from long-lived operational controls. A flag intentionally kept as a kill switch should be marked so stale cleanup does not recommend removing it.

Also preconfigure emergency access. The current toggle skill has no hidden “ignore review” option. Approval is the normal path. If your production policy requires a second reviewer, ensure one is available. If the organization permits an emergency bypass, document who can activate it and how the action is audited.

Step 1: Establish incident scope

Do not begin with a mutation. Ask the agent to read the flag and relevant incident context:

Read the latest flag-toggle skill. Fetch flag new-search-ranking and production state. Report default value, value type, environment enablement, ordered active rules, ramp status, experiments, open drafts, and direct GrowthBook link. Do not change anything.

Then state the observed harm:

The new ranking path is causing 500 responses for production web traffic. The safe behavior is the legacy ranking path represented by default false. Confirm whether disabling this flag in the actual production environment sends every user to false. Identify any audience that would behave differently.

This confirms three facts:

1. the key is the one used by the failing code
2. “production” maps to an actual environment ID
3. the default produces the intended fallback

If the default is unsafe or ambiguous, do not disable blindly. A targeted rule change, prior-revision revert, traffic-layer rollback, or application deploy may be safer.

Build a safer release path

Pair kill switches with staged exposure, ownership, and cleanup so emergency controls are tested before your team needs them.

Read the Flag Scale Guide

Step 2: Confirm the exact disable

The current workflow makes the behavioral change explicit:

new-search-ranking is enabled in production. Disabling it stops 3 active rules from evaluating. All callers will receive default "false", which selects legacy ranking. Create the toggle in a draft and stop before publish.

Use this prompt:

Disable new-search-ranking in environment ID production. Apply the toggle to a draft revision only. Return the draft version, whether an existing teammate draft was reused, and a one-line summary of every active rule that the disable will suppress. Do not publish.

The v2 revision endpoint uses a special new version to create or reuse an open draft. Reuse is convenient but important during an incident: the toggle might land beside another teammate's pending change. The receipt should identify the draft owner and full diff so you do not publish unrelated work accidentally.

The open GrowthBook MCP server makes authenticated API calls under the provided token. MCP does not confer more authority than that identity has in GrowthBook.

Step 3: Publish through the emergency review path

If the draft contains only the intended toggle, authorize publish:

Publish revision 42 on new-search-ranking with comment “Incident INC-247: disable broken ranking path.” If approval is required, request review and stop. If there is a merge conflict, show the conflicting fields and do not auto-resolve.

The current flag-publish workflow handles:

• approval required: request review; draft authors cannot self-approve
• merge conflict: fetch field-level conflicts; a human chooses draft or live value for each
• success: read back the flag and report the published revision

GrowthBook's agentic feature management release explains that approval policies can apply to environment kill switches, not just targeting rules. That is intentional governance.

If the incident policy allows an authorized bypass, use the documented administrative path. Do not ask the agent to discard and recreate the revision or retry until policy disappears. If review latency is unacceptable for the system's recovery objective, fix the policy and staffing before the next incident.

Step 4: Verify GrowthBook state immediately

After publish, ask for a new read:

Fetch new-search-ranking again. Report published revision, production enabled state, default, active rules, publication timestamp, and audit comment. Confirm that production is disabled according to GrowthBook. Do not make another change.

This proves control-plane state. It does not yet prove every runtime has received it.

Capture a receipt:

Incident: INC-247
Flag: new-search-ranking
Environment: production
Before: enabled; 3 active rules
Default/fallback: false → legacy ranking
Draft: revision 42
Review: <reviewer and status>
Published: <timestamp>
Readback: production disabled

The GrowthBook feature revision documentation provides the underlying audit and revision model. Keep the direct UI link in the incident channel.

Step 5: Verify application behavior

GrowthBook SDKs evaluate feature payloads locally. A published control-plane change must reach the application's SDK payload before the runtime changes behavior. Timing depends on:

• streaming or polling configuration
• cache time-to-live
• proxy or CDN behavior
• server process lifecycle
• offline mobile or desktop clients
• custom refresh settings
• network availability

Do not report “all users are off” from the publish response. Verify representative instances:

• request the affected production path with a known context
• inspect evaluation source and value when debug tooling is available
• watch the error rate and the original incident signal
• sample multiple regions, runtimes, or app versions
• explicitly refresh or recycle instances only when that is part of the runbook

The GrowthBook SDK documentation explains refresh behavior per language. The JavaScript SDK's published package also documents background sync and manual refresh options.

A clear status update is:

GrowthBook published the production disable at 14:07 UTC. Web pods in us-west and eu-central now evaluate false and error rate is returning to baseline. Mobile clients refresh on their normal payload cadence, so full observation is still in progress.

That is more useful than the unsupported claim “instantly fixed everywhere.”

Step 6: Choose the follow-up control

Once the incident stabilizes, keep the flag disabled while the team investigates. Do not delete it. Decide whether to:

• repair the treatment and re-enable for a narrow audience
• revert a prior live flag revision into a new draft
• remove or correct the bad rule
• roll back the application deployment
• leave a long-lived operational kill switch
• permanently inline the safe behavior and later clean up

If the broken feature was part of an experiment, preserve the experiment state and analysis. Stopping an experiment and disabling the feature are different actions. The former records an outcome and can manage temporary rollout; the latter stops all flag rules in one environment.

If a monitored ramp caught the regression, include its decision, guardrail, and rollback status. The GrowthBook safe rollout docs show how ramp monitoring can hold or roll back before a human incident response begins.

Build a copy-ready incident runbook

Read

Fetch <flag-id>. Confirm the actual production environment, current toggle, default, live rules, draft owner, ramp, and experiments. Read only.

Decide

Explain the exact effect of disabling production. Which audiences move from which values to the default? Is the default the known-safe path?

Draft

Stage one environment-level disable in a draft. Do not change rules, default, metadata, or other environments. Return the full diff.

Publish

Publish with incident ID in the comment. Request review if required. Do not auto-resolve conflicts.

Verify

Read back GrowthBook state, then test representative application runtimes and report observed flag values and incident metrics.

Recover

Preserve the disabled state. Propose repair, targeted re-enable, revert, or code rollback as a new reviewed action.

This sequence keeps mitigation fast because nobody has to reconstruct the flag model during the incident. It also prevents the agent from confusing “disable this feature” with “delete the flag” or “stop the experiment.”

Common failure modes

The OpenFeature evaluation specification provides useful common terminology for flag values, errors, reasons, and defaults. Regardless of SDK, build logging that distinguishes an evaluated control value from an unknown or stale flag.

Make “instant” an engineered property

A fast kill switch depends on work completed before launch:

• safe and tested defaults
• explicit owners
• clear environment IDs
• scoped emergency credentials
• reachable reviewers
• streaming or refresh behavior understood
• runtime evaluation diagnostics
• an incident prompt and receipt template
• regular drills that disable and restore a noncritical flag

The agent reduces navigation and remembers the correct revision sequence. GrowthBook supplies the control plane, permissions, and audit history. Your system design determines how rapidly the published value reaches users.

Use MCP to make the operational path short and explicit. Verify the fallback and the runtime before you call the incident resolved.

Make rollbacks less dramatic

Use staged rollouts, guardrail metrics, and tested fallback paths so a production disable is a normal control—not an improvised rescue.

Plan Safer Flag Releases