How to use GrowthBook MCP server to automate your feature flag lifecycle

A feature flag is temporary operating infrastructure, not a Boolean you create once and forget.

The useful lifecycle starts before the flag exists and ends after its conditional code is gone. Between those points, a team must name the flag, assign ownership, keep it disabled until the code is ready, target the intended population, ramp exposure, watch guardrails, preserve an emergency path, settle the final behavior, and remove the flag without changing production unexpectedly.

GrowthBook's current MCP server can coordinate that work from an AI client. Version 2 combines an authenticated API bridge with official agent skills. The server discovers the relevant skill, the agent reads its current procedure, and authenticated API calls operate on GrowthBook. The GrowthBook skills repository now covers the major flag stages instead of relying on a fixed list of one-off tools.

Automation here means reducing lookup and sequencing work. It does not mean giving an agent an unbounded production token and asking it to “manage flags.” The safe unit is a scoped workflow with an expected state, an approval boundary, and a readback receipt.

Define the lifecycle as state transitions

The Model Context Protocol lets an AI application call external tools through a standard interface. GrowthBook's skill layer adds the operational sequence around those calls.

This model is compatible with the broader OpenFeature specification, which separates application evaluation from a provider's control plane. Your code consumes a value; GrowthBook owns the live rules; MCP gives an agent a governed path to that control plane.

Before using write workflows, connect the server with a token scoped to the required projects. The GrowthBook MCP server page covers supported clients and setup. Then ask the agent to list and read the current matching skill before it acts. That prevents an old prompt based on version 1 tool names from becoming a guessed v2 API call.

Stage 1: Create a durable flag contract

flag-create does more than send a key and a default. It checks whether the key already exists, resolves the project, lists every environment, validates the value type, and builds an environment map that explicitly disables the flag everywhere.

That default is important. An organization's “new environment” policy is configurable, so a create workflow must not assume a new flag is off. The skill sends {enabled: false} for each environment and creates no targeting rules.

Choose the key carefully because feature keys are permanent. Prefer kebab-case and name the behavior, not a ticket number or implementation detail. Also choose the narrowest useful value type:

• boolean for an on/off release gate
• string for named modes or copy variants
• number for a remotely controlled threshold
• json for a structured configuration whose schema is reviewed in code

Use a prompt with a visible contract:

Read the latest flag-create skill. Create a Boolean flag named new-billing-summary in project billing. Default to false, describe the behavior it gates, and explicitly disable it in every environment. Show the resolved project and environment IDs and ask before the POST. Stop after readback.

The receipt should say that the flag is disabled everywhere and has no rules. If the request was actually an A/B test, the skill should route to experiment design instead of creating an orphaned flag.

Add an owner and cleanup intent early. Martin Fowler's feature toggle taxonomy distinguishes short-lived release toggles from longer-lived operational or permission toggles. The distinction affects how aggressively you should audit and remove the flag later.

Stage 2: Implement and verify the code path

Creating a GrowthBook object does not change application behavior until the SDK evaluates the flag. Ask the coding agent to locate the initialized GrowthBook client, follow the repository's existing evaluation pattern, and preserve a safe fallback.

For a Boolean gate, review both branches. What happens before the SDK is ready? What happens if the flag is absent? Is the default path the current production behavior? For JSON flags, validate the runtime shape rather than casting an arbitrary payload into a trusted type.

The GrowthBook SDK documentation is the canonical reference for each language. The agent should use the installed SDK and existing project conventions, not invent a generic helper from memory.

Require tests at the code boundary:

• default or missing-flag behavior
• explicit off behavior
• explicit on behavior
• any targeting attributes passed to the SDK
• server-rendering or hydration behavior when relevant

MCP manages GrowthBook state; normal code review manages source changes. Keeping those receipts separate makes it clear whether a failure came from application logic or live flag configuration.

Design flags for scale

Build ownership, rollout, and cleanup expectations into every flag before temporary release logic turns into permanent infrastructure.

Read the Scale Guide

Stage 3: Translate audience intent into an exact rule

flag-targeting handles force rules and percentage rollouts. It first fetches the flag's type, environments, and ordered rule list. It then fetches registered attributes for the flag's project and, when needed, resolves saved groups or prerequisites.

The rule order matters because the first matching rule wins. New rules append to the bottom, so an apparently correct beta-user rule may never run if an earlier, broader rule already matches. The agent should surface the current order before adding anything.

Plain-English targeting must resolve into existing GrowthBook concepts:

• “beta testers” may be a saved group
• “US customers” may be a condition on a registered country attribute
• “app version 5.2 or newer” needs a version-aware operator on a version-formatted attribute
• “only if checkout v2 is on” is a rule-level prerequisite
• “enterprise users” is ambiguous until the user chooses a saved group or an attribute condition

Conditions are evaluated by the SDK against attributes supplied by your application. An unregistered or never-populated attribute can produce a valid-looking rule that never matches. The current skill refuses to invent the attribute and confirms it from GrowthBook first.

Ask for a draft-only action:

On new-billing-summary, propose a production force rule that serves true to the saved group design-partners and users whose registered plan attribute equals enterprise. Show existing rule order, resolved IDs, exact condition JSON, scope, and served value. Add it to a draft only and stop before publish.

The GrowthBook targeting documentation explains how conditions, hashing, and ordered evaluation behave. MCP makes the configuration conversational, but the resulting rule must still be inspectable as data.

Stage 4: Ramp exposure through scheduled holds

A percentage rollout is one state. A ramp schedule defines how exposure changes over time. flag-ramp attaches a sequence of coverage patches to one force or rollout rule. Each step can have a time interval, a manual hold, or an approval requirement after the interval clears.

A reasonable plan might be:

1. Start at 5% and soak for 24 hours.
2. Move to 25% and require approval after another 24 hours.
3. Move to 50% and hold manually through a peak-traffic period.
4. Complete at 100%.

The rollback state is not automatically zero. startActions must match the rule's coverage before the ramp began. If the rule was already serving 10%, rolling back to zero would create an unintended behavior change.

Use an explicit prompt:

Build a production ramp for rule <rule-id> on new-billing-summary: current coverage to 5%, then 25%, 50%, and 100%, with 24-hour intervals. Require approval before 50% and hold manually before completion. Use the current coverage as the rollback state. Stage the schedule in the existing draft and do not publish.

The current skill can also start, pause, resume, advance, approve, roll back, complete, or restart a live ramp. An advance call can override holds, so it should be treated as a deliberate production action rather than routine automation.

Stage 5: Monitor outcomes, not only deployment health

flag-monitoring adds a datasource, exposure query, guardrail metrics, optional signal metrics, and health actions to a ramp. Monitored steps wait for results before advancing.

At least one guardrail is required. Without it, the workflow is an unmonitored ramp, which belongs in flag-ramp. Every metric must use the same datasource named in the monitoring configuration.

The team also chooses how to handle health states:

• SRM can warn, hold, or trigger rollback; hold is the conservative default.
• no traffic and multiple exposures can produce warning or hold behavior.
• autoUpdate: true allows automatic rollback on a guardrail failure.
• an approval condition can keep a human gate even after monitoring passes.

Ask the agent to make those choices visible:

Add monitoring to the billing-summary ramp. Use the matching datasource and exposure query. Guard on checkout errors and payment failures; track page latency as a signal. Hold on SRM, warn on no traffic for 24 hours, and require human approval at 50%. Show metric IDs and the full monitoring block before writing.

Monitoring does not guarantee safety. It evaluates the metrics and thresholds you configured, at the cadence data becomes available. The GrowthBook safe rollout documentation provides the product model, while the agent can make the current IDs and actions easier to review.

Stage 6: Publish with review and conflict handling

All rule, toggle, ramp, and monitoring changes live first in a draft revision. flag-publish attempts to publish a named version and handles two important branches.

An approval-required response is a policy decision, not a transient failure. The skill can request a review, but the draft author cannot approve their own change. A merge conflict means live state changed after the draft branched. The agent fetches field-level conflicts and asks whether each should preserve the draft or the newer live value. It never retries blindly or discards the draft to escape the conflict.

This is the production handoff:

Inspect revision 42 on new-billing-summary. Summarize the diff, reviewer status, environments, rule order, ramp, and monitoring. If it is approved and conflict-free, show the publish action and wait for my confirmation. After publishing, fetch the flag and report the live state.

The before/after readback is essential. A successful HTTP response proves that a call returned; it does not by itself prove that you targeted the intended environment and rule.

Stage 7: Operate with a clear emergency path

During a rollout, ask for state rather than memory:

Read new-billing-summary and its ramp status. Report live revision, production enablement, default value, active ordered rules, current coverage, monitoring decision, guardrail health, and pending approvals. Do not change anything.

If behavior is broken, choose the smallest correct control:

• pause the ramp to stop automatic progression
• roll the ramp back to its captured start state
• revert a prior published revision into a new reviewable draft
• disable the flag in one environment so all rules stop and every caller receives the default value

The last option is the environment-level kill switch. It still goes through draft, review, and publish. It is not a hidden bypass, and its effect depends entirely on whether the default value is safe.

Community discussion of MCP-based flagging repeatedly asks for preview, before/after diffs, observation windows, and rollback receipts rather than raw “toggle” access. A recent practitioner thread captures that operational concern. The current GrowthBook skills encode many of those checks, but teams must still scope tokens and review policies appropriately.

Stage 8: Retire the flag without changing behavior

flag-search can identify candidates by project, owner, tag, environment state, or staleness. Discovery should remain read-only. For one reviewed flag, flag-cleanup follows a gated sequence:

1. Fetch live state, staleness, experiments, and open drafts.
2. Determine which value users actually receive, including temporary experiment rollouts.
3. Identify rules that diverge from the post-archive default.
4. Find code references through GrowthBook or a confirmed local repository search.
5. Inline the chosen behavior per file and run tests.
6. Archive the flag through the revision workflow.
7. Verify a deployed cycle while the action is still reversible.
8. Delete only after a second explicit confirmation.

A running experiment blocks cleanup. A neverStale flag also blocks it until a human removes that protection. An unresolved draft must be published or discarded first.

The important subtlety is the inline value. If a stopped experiment has a temporary winner rollout, all eligible users may see the winner even when it differs from the flag's default. Archiving stops rule evaluation and returns the default. The agent must surface that behavior change before touching code or GrowthBook.

Permanent deletion removes the flag and its revisions, but it cannot guarantee that another flag does not depend on it. The workflow warns the operator to inspect the “Used by” relationship before the irreversible step. It also keeps archive and delete separate even when the API could be made to allow a faster path.

Turn the workflow into team policy

Automate repeated questions, not accountability. A simple policy can require:

• project, owner, flag type, and target cleanup date at creation
• a safe default and explicit environment scope
• a draft diff before every live change
• guardrails and hold behavior before a production ramp
• readback with revision and rule IDs after publish
• a known kill path documented in the owning service
• monthly stale-flag audits that never delete in bulk
• archive, deployed verification, and separate delete confirmation

The GrowthBook feature flag best-practices guide provides the organizational foundation. The open GrowthBook source repository makes the control plane inspectable, while the MCP server brings those governed operations into the editor.

The goal is not to make flags invisible. It is to make their state, ownership, risk, and next action visible wherever the team works. The best automation leaves fewer forgotten branches and more evidence for every production decision.

Keep flags from becoming debt

Use a lifecycle-first operating model to preserve release control without accumulating stale rules, unclear ownership, and dead code.

Build a Flag Program