How to use GrowthBook's MCP to add targeting rules in plain English (no console required)

“Show the new billing summary to enterprise beta testers in the US” is a useful product instruction. A safe GrowthBook rule still needs exact attributes, group IDs, scope, values, order, and review.

GrowthBook's MCP server lets a compatible AI client translate audience intent into a draft feature-flag rule. The current flag-targeting skill supports force rules and percentage rollouts, including registered SDK attribute conditions, saved groups, and rule-level prerequisites.

The benefit is not that targeting becomes vague. The benefit is that the agent can gather the exact GrowthBook objects, expose ambiguity, build valid condition JSON, and return a readable receipt without requiring you to click through the console.

This guide follows the current skill in the GrowthBook skills repository and the v2 GrowthBook MCP server.

Know the four parts of a targeting rule

A useful targeting request answers:

1. Which flag and value? For example, serve true for a Boolean flag.
2. Who qualifies? Attribute conditions, saved groups, or prerequisite flags.
3. Where does it apply? Named environments or all environments.
4. How much traffic? Everyone who matches, or a deterministic percentage.

GrowthBook rules evaluate top to bottom and the first match wins. A new rule appends to the bottom. That means a perfectly valid enterprise rule may be unreachable if an earlier broad rule already matches the same users.

The GrowthBook targeting rules docs explain the underlying evaluation model. MCP gives the agent a way to read and modify that model through natural language, but the live object remains an ordered rule with explicit fields.

Step 1: Read the flag before describing the audience

Start with:

Read the latest flag-targeting skill. Fetch new-billing-summary and show value type, default, project, environment IDs, environment enablement, and the complete ordered rule list. Do not change anything.

The agent needs the value type because GrowthBook rule values are serialized as strings:

• Boolean: "true" or "false"
• number: a numeric string such as "25"
• string: the literal value
• JSON: valid JSON-encoded text

The current API does not catch every type mismatch at write time, so the skill validates before posting. A prompt that says “serve premium mode” is incomplete until the agent knows whether the flag expects a Boolean, string, number, or JSON value.

Also verify the environment. “Prod” is an alias humans use; the rule needs an actual environment ID from the flag's configuration.

Step 2: Fetch registered targeting attributes

Before translating “enterprise users in the US,” the skill queries GrowthBook for attributes in scope. For a project flag, it uses that project ID so org-wide and project attributes are returned without unrelated fields.

A useful response groups them:

id           string   hash attribute
country      string   ISO country code
plan         enum     free | pro | enterprise
appVersion   string   semantic version
isEmployee   boolean
companyId    string   hash attribute

Only use attributes in this list. GrowthBook conditions are evaluated client-side by the SDK against attributes your application supplies. An unknown name can produce a valid-looking rule that never matches.

Ask:

Fetch attributes available to this flag's project. Map “enterprise users in the US on app version 5.2 or newer” to registered fields and show their types and formats. If any phrase has no unique mapping, ask me rather than guessing.

The agent should prefer version-aware comparison operators for version-formatted attributes. Lexicographic string comparison would treat values such as 1.0.10 incorrectly relative to 1.0.9.

The GrowthBook SDK docs explain where attributes enter each application integration. The control plane cannot target on context the runtime never supplies.

Step 3: Choose a condition, saved group, or prerequisite

Plain-language audience labels can refer to different GrowthBook concepts:

Attribute conditions

Conditions use GrowthBook's MongoDB-style JSON syntax. Multiple top-level fields are ANDed:

{
  "country": "US",
  "plan": "enterprise",
  "appVersion": { "$vgte": "5.2.0" }
}

Use $or when either branch can qualify:

{
  "$or": [
    { "country": "US" },
    { "isEmployee": true }
  ]
}

Comparisons are case-sensitive by default. Use the skill's supported case-insensitive membership or regex operators only when the attribute's semantics require them. Avoid unlisted MongoDB operators; they may silently never match in SDK evaluation.

Saved groups

A named cohort such as “design partners” should usually resolve to a GrowthBook saved group rather than repeat a long condition on every flag. The skill fetches group IDs and uses the separate savedGroups field.

Multiple group IDs can require membership in all or any. The prompt should say which:

Target users in both design-partners and billing-beta.

Rule-level prerequisites

A prerequisite asks whether another flag evaluates to the required value for the same user. If it fails, GrowthBook skips this rule and continues down the list.

For a Boolean dependency:

{
  "id": "billing-platform-v2",
  "condition": "{\"value\": true}"
}

Rule-level prerequisites gate only that rule. Feature-level prerequisites gate the entire flag and use a separate workflow. The GrowthBook guide to flagging at scale shows why dependencies can be useful and why they need simulation and cleanup discipline.

Keep targeting understandable

Use ownership, prerequisites, simulation, and cleanup practices before a few useful rules become an opaque production decision tree.

Read the Flag Scale Guide

Step 4: Decide between force and rollout

A force rule serves one value to every matching user:

Serve true to US enterprise design partners in production.

A rollout rule serves the value to a deterministic fraction of matching users:

Serve true to 10% of eligible US enterprise design partners in production.

Coverage is a number from 0 to 1. A partial rollout also needs a registered hash attribute. Use user ID for user-level stability or a company identifier for account-level consistency. The unit should match the release intent; randomizing people inside the same enterprise account can create mixed experiences.

Ask:

Use a rollout rule at 10% of matching accounts, hashed by the registered companyId attribute. Confirm that it is marked as a hash attribute. Do not substitute user ID.

The OpenFeature evaluation specification offers shared terminology for evaluation context and flag values. GrowthBook's exact bucketing and condition semantics remain defined by its SDKs.

Step 5: Preview the exact rule

Before a write, require a normalized summary:

Flag: new-billing-summary
Type/default: boolean / false
Action: add rollout
Served value: true
Scope: production only
Coverage/hash: 10% / companyId
Condition: country=US AND plan=enterprise AND appVersion>=5.2.0
Saved groups: design-partners (all)
Prerequisite: billing-platform-v2 evaluates true
Position: appended as rule 4
Possible shadowing: rule 2 matches all enterprise users
Effect if published: only users satisfying every audience field enter the 10% bucket

If an earlier rule shadows the new one, decide whether to reorder, narrow the earlier rule, or change the plan. Do not create the rule and hope.

This prompt works:

Normalize my request into an exact GrowthBook rule. Validate the value against the flag type, environment against the flag, attributes against the project registry, saved-group and prerequisite IDs, coverage, hash attribute, and rule order. Show the JSON and a human explanation. Do not write.

Plain English is the input interface. The JSON receipt is the review interface.

Step 6: Add to a draft, then read it back

Authorize only the draft write:

Add the reviewed rollout rule to a draft revision on new-billing-summary. If a draft version is already in this session, thread the same version; otherwise use a new draft. Return revision version and rule ID. Do not publish.

The skill uses the feature revision endpoint. If a draft already exists, the special new version can reuse it. Surface the owner and other pending changes so a targeting update does not accidentally bundle unrelated work.

Fetch the draft and verify:

• rule ID
• type
• value
• scope
• condition string parses to the intended JSON
• saved-group IDs and match mode
• prerequisite ID and condition
• coverage and hash attribute
• position in the full rule list

The GrowthBook AI-native development page explains that agent changes stay inside the same permissions, approval flow, and audit trail as app changes.

Step 7: Test representative contexts

Before publish, create test contexts that cover each boundary:

Ask the agent to explain which field fails for each. Then verify in the application or GrowthBook simulation tools. The GrowthBook feature flags platform includes targeting and simulation capabilities designed for this review.

Do not infer runtime truth only from JSON. Attribute values may differ in capitalization, types, availability, or naming across SDKs. A condition can be structurally correct and operationally dead.

Community discussion of GrowthBook's targeting by account or user attributes reinforces the core model: the application provides context and SDKs evaluate locally. Your test contexts must resemble what the application actually sends.

Step 8: Publish through normal review

After a reviewer checks the draft:

Publish revision 42 on new-billing-summary with comment “10% enterprise design-partner rollout.” If approval is required, request review and stop. If there is a conflict, show each field and do not auto-resolve. After success, fetch the live flag.

A 409 means the live flag changed since the draft started. It is not a network retry. The publish workflow fetches the merge conflict and asks whether each field should preserve the draft or live value.

After publish, report:

• live revision
• environment enablement
• ordered rules
• the new rule ID and position
• current default
• publication timestamp and audit comment
• direct GrowthBook link

Then evaluate known contexts and monitor the release. “Published” does not prove that every SDK has received an updated payload.

Edit and remove rules by ID

For edits, the skill shows a numbered list for the human but resolves the selected item to its stable fr_... rule ID. Never guess an ID from position.

A patch should include only changed fields. No-op patches are rejected because they create draft noise and can reset review state. Changing a force rule's coverage below 100% effectively turns it into a rollout and requires a hash attribute.

Experiment-reference rules have extra protections. Their values and coverage should not be edited through the targeting path. Use the experiment workflow so the flag does not drift from its source of truth.

Removal also goes into a draft:

Remove rule 4 from the displayed list. Confirm its rule ID, type, scope, condition, and served value. Stage removal only. Do not publish.

Removing an experiment rule does not stop the experiment. These are distinct operations.

Write prompts that expose ambiguity

Weak:

Turn it on for VIPs.

Strong:

On new-billing-summary, find whether “VIPs” maps to a saved group or registered attribute in project billing. If both exist, ask me. Propose a production force rule serving Boolean true. Show existing order, exact IDs, condition JSON, default, and expected fallthrough. Draft only.

Weak:

Roll this out to 20%.

Strong:

Propose a production rollout of true to 20% of eligible enterprise accounts on flag new-billing-summary. Hash by registered company ID, not user ID. Preserve the existing design-partner force rule above it. Show the draft diff and stop.

Good prompts define intent and safety boundaries while letting the latest skill supply endpoint mechanics.

Keep a targeting receipt

Store:

Flag/project:
Environment:
Value type/default:
Rule ID/type/value:
Attributes and source:
Condition JSON:
Saved groups and match:
Prerequisites:
Coverage/hash unit:
Rule order and shadowing check:
Draft/reviewer/published revision:
Test contexts:
Runtime verification:

The original GrowthBook MCP launch discussion introduced targeting through fixed force-rule tools. The current skill is broader: it resolves multiple audience concepts, validates value and scope, preserves revision threading, and hands off to review.

No console required should mean fewer clicks and less transcription. It should not mean no exact configuration. Ask in product language, inspect the normalized rule, publish through review, and verify with real SDK contexts.

Turn targeting into a rollout

Add a staged exposure and cleanup plan so today's precise audience rule does not become tomorrow's unexplained permanent branch.

Plan the Flag Lifecycle