How to use GrowthBook's MCP server to keep feature flag code type-safe

Type-safe feature flags require one contract between GrowthBook and your repository. MCP can audit that contract; the current GrowthBook CLI generates the TypeScript source of truth.

A misspelled feature key rarely crashes an application. It usually falls back. A Boolean flag accidentally treated as a string may also compile when the SDK is used without a strict feature map. Those failures are quiet: the product appears stable while the intended experience never reaches users—or the fallback selects the wrong branch.

GrowthBook's TypeScript SDK supports an AppFeatures generic that maps every allowed key to its value type. Once connected, the compiler can reject unknown keys and incompatible fallback values. The generated map should come from live GrowthBook configuration, not a hand-maintained interface that drifts.

There is one important 2026 version detail. GrowthBook MCP v1 exposed a generate_flag_types tool, and the earlier type-safe React guide demonstrates that workflow. The current v2 GrowthBook MCP server has a thin three-tool architecture, and the current GrowthBook skills catalog explicitly leaves SDK code generation out of scope.

The supported current pattern is:

1. use MCP to read and audit live flag IDs, value types, defaults, projects, and code references
2. use the current GrowthBook CLI's generate-types command from the same editor
3. wire the generated type into the SDK
4. make regeneration and type-checking a CI gate

That still delivers an editor-native workflow without pretending a retired MCP tool is current.

Understand what type safety can catch

Without a strict map:

const enabled = gb.isOn("new-chekout");
const tax = gb.getFeatureValue("regional-tax-rate", "0");

Both calls may compile even when the first key is misspelled and the second fallback has the wrong type.

With a generated contract:

exportinterface AppFeatures {
  "new-checkout": boolean;
  "regional-tax-rate": number;
  "checkout-copy": string;
  "payment-methods": string[];
}

the SDK can constrain methods to keyof AppFeatures and use the corresponding value type. The TypeScript compiler then catches:

• key typos
• deleted or renamed-in-code keys
• a fallback with the wrong primitive type
• a component expecting a value shape different from the generated contract
• stale tests and mocks that refer to removed flags

The current GrowthBook JavaScript SDK package documents strict typing on the GrowthBook<AppFeatures> instance. React hooks can use the same generic.

Types do not catch:

• a valid key disabled in the target environment
• a targeting condition based on an attribute the application never sends
• an earlier rule shadowing a later rule
• a stale or unavailable SDK payload
• a semantically wrong but type-correct number
• a client-side flag incorrectly used as authorization

Treat compilation as one layer in the release system, not evidence that the live rule works.

Step 1: Audit the live flag contract with MCP

Start read-only. Ask the current flag-search skill to inventory the project and include fields that affect the code contract:

Read the latest GrowthBook flag-search skill. For project checkout, list every non-archived feature key, value type, default value, owner, tags, environment enablement, and code-reference count. Sort by key. Do not write anything.

Then ask for mismatches against the repository:

Compare that GrowthBook inventory with all feature keys referenced in this TypeScript repository. Report keys present only in GrowthBook, only in code, type assumptions in fallbacks, and direct uses that bypass our typed wrapper. Read only.

This creates two sets:

• control-plane contract: what GrowthBook says exists and its declared value type
• code contract: what the repository imports, evaluates, mocks, and assumes

An unknown key in code is a likely defect. A GrowthBook-only key may belong to another repository, be newly created, or be stale. Project scoping and Code References help distinguish those cases.

The GrowthBook feature flag documentation explains the four value types—Boolean, string, number, and JSON—and how defaults and rules serve them. Your generated TypeScript should reflect the declared type, while JSON flags may need a stronger application-specific schema.

Keep flag contracts maintainable

Pair strict types with naming, ownership, and cleanup rules so compiler safety does not coexist with an ungoverned control plane.

Read the Flag Scale Guide

Step 2: Install and authenticate the current GrowthBook CLI

The original growthbook/growthbook-cli repository was archived in July 2026. Its README points to the maintained growthbook/cli repository. Do not build a new workflow around the archived command layout.

The current CLI is installed with:

npm i -g growthbook

On a workstation, run:

growthbook configure
growthbook whoami

The current CLI stores secrets in the operating-system keychain when available. It also supports profiles for cloud, staging, and self-hosted instances. In CI, provide a scoped bearer credential through the documented environment or secret mechanism rather than committing it.

Pin a CLI version the team has tested. The current CLI follows semantic versioning, and its README recommends version pinning for automation. A generator is part of your build chain; an unreviewed major update should not rewrite a contract file on every developer machine.

The MCP server and CLI can use the same GrowthBook project while holding different permissions. MCP may be read-only for audits, while CI uses a read-capable CLI token. Neither requires production flag-write permission to generate types.

Step 3: Generate AppFeatures from GrowthBook

The current CLI syntax is:

growthbook generate-types \
  --project prj_checkout \
  --output ./src/growthbook \
  --filename app-features.ts

Without output flags, it writes ./growthbook-types/app-features.ts. Limiting to one project keeps unrelated flags out of the application contract and makes autocomplete useful.

Add a package script:

{
  "scripts": {
    "growthbook:types": "growthbook generate-types --project prj_checkout --output ./src/growthbook --filename app-features.ts",
    "typecheck": "tsc --noEmit"
  }
}

Run generation, inspect the diff, and compare it with the MCP inventory. The counts and keys should align. If the CLI and MCP point at different profiles or instances, the mismatch is a configuration failure worth stopping on.

Do not hand-edit the generated file. If a JSON flag produces a type too broad for application safety, keep the generated transport contract and validate or narrow at an adapter boundary.

Step 4: Thread the type through the SDK

For the base JavaScript SDK:

import { GrowthBook } from"@growthbook/growthbook";
importtype { AppFeatures } from"./growthbook/app-features";

exportconst growthbook = new GrowthBook<AppFeatures>({
  apiHost: process.env.GROWTHBOOK_API_HOST,
  clientKey: process.env.GROWTHBOOK_CLIENT_KEY,
});

For React:

import { useGrowthBook } from"@growthbook/growthbook-react";
importtype { AppFeatures } from"./growthbook/app-features";

exportfunction Checkout() {
  const gb = useGrowthBook<AppFeatures>();
  const showNew = gb?.isOn("new-checkout") ?? false;

  return showNew ? <NewCheckout /> : <LegacyCheckout />;
}

Use the exact generic form supported by the installed SDK version. The GrowthBook React SDK docs are the canonical reference for initialization, provider, loading state, and hooks.

Run the compiler. Fix every error by comparing code with the GrowthBook contract, not by casting:

// Avoid: hides the exact problem strict typing was added to find
gb.isOn(flagName askeyof AppFeatures);

If a dynamic key is a real requirement, isolate it in a reviewed adapter that validates membership at runtime. Do not spread unchecked casts across components.

The TypeScript handbook on keyof explains how a property map becomes the union of allowed keys. GrowthBook's SDK combines that key union with indexed access to select the expected value type.

Step 5: Make JSON flags safe at runtime

TypeScript disappears at runtime. A generated declaration describes what GrowthBook is configured to serve, but it cannot validate an unexpected payload arriving from a stale cache, misconfiguration, or manual change.

For structured values, validate:

import { z } from"zod";

const paymentMethodsSchema = z.array(z.string());

exportfunction getPaymentMethods(gb: GrowthBook<AppFeatures>) {
  const value = gb.getFeatureValue("payment-methods", []);
  return paymentMethodsSchema.parse(value);
}

Choose whether invalid data should fail closed, use a safe fallback, or surface an operational alert. The right behavior depends on the feature.

The OpenFeature evaluation specification distinguishes typed evaluation calls and type-mismatch errors. That model is useful even when you use the native GrowthBook SDK: caller expectations should be explicit at both compile time and runtime.

Never use client-side flag visibility as authorization. Client payloads and treatment code can be inspected. Enforce permissions on the server independently, as the GrowthBook client-side flag guide recommends.

Step 6: Add a drift gate to CI

Commit the generated file. In CI:

1. install the pinned CLI
2. configure a read-only GrowthBook profile or bearer token
3. run the same generation command
4. fail if the generated file differs
5. run tsc --noEmit and tests

A shell outline:

npm run growthbook:types
git diff --exit-code -- src/growthbook/app-features.ts
npm run typecheck
npm test

This answers two different questions:

• Did GrowthBook's contract change without the repository updating?
• Does the current repository still compile against the updated contract?

If CI cannot safely reach GrowthBook, generate types in a separate trusted workflow when flags change, commit the result through a pull request, and keep the compile gate local to the repository.

Do not auto-commit a type change directly to the default branch. A deleted key may require a code migration, and a changed value type can alter runtime semantics. The generated diff is review input.

Step 7: Use MCP to review every flag change

MCP becomes most valuable at the point of change. Before creating or changing a flag:

Show whether this proposed key exists, its current value type and project, and every code reference. If the type would change, list affected call sites. Do not mutate.

After a reviewed GrowthBook change:

Fetch the flag and read back key, value type, default, revision, and environment state. Then run the repository's GrowthBook type generator and type checker. Show the diff and errors. Do not cast around failures.

For deletion:

Before archiving, prove the key has no remaining typed or string-literal references across the intended repositories. Regenerate types only after the code migration is ready. Keep archive and permanent delete as separate confirmations.

This pairs the current MCP strengths—live state, revisions, code references, dependency checks—with deterministic generation. The GrowthBook AI-native workflow keeps agent reads and writes inside normal permissions and audit trails.

Avoid three false forms of type safety

A hand-written interface

It improves autocomplete on day one and drifts on day ten. Generate from GrowthBook.

A generated file nobody imports

The file can be perfect while the SDK instance remains GrowthBook<Record<string, any>>. Verify the generic is applied to the actual instance and hooks.

A passing compiler with broad casts

as any and unchecked keyof casts turn contract failures back into runtime fallbacks. Track and prohibit them at flag-evaluation boundaries.

Also remember that generated types describe keys and shapes, not allowed targeting populations. A type-safe call can still serve the wrong audience. Pair compiler checks with live-rule readback and test contexts.

A copy-ready workflow

Audit non-archived flags in project checkout and compare them with this repository. Read only.

Run the pinned GrowthBook CLI generate-types command for prj_checkout. Show the generated diff.

Thread AppFeatures through the existing GrowthBook SDK instance and React hooks. Fix type errors without broad casts. Add tests for safe fallbacks.

Add CI commands that regenerate, fail on diff, type-check, and test. Use a read-only secret.

Return a receipt with MCP inventory count, generated key count, changed keys/types, compiler result, test result, and unresolved runtime risks.

The current architecture asks two tools to do what each does best. MCP supplies live GrowthBook context and reviewable lifecycle operations. The CLI produces a deterministic TypeScript artifact. The compiler prevents code from quietly drifting away from the flag contract.

Scale flags without losing control

Combine type safety with clear ownership, release stages, and cleanup rules so a larger flag program stays understandable.

Build a Flag Program