Top 5 things you can do with GrowthBook's MCP server right now

The most useful MCP workflow is not "show me every tool." It is a closed loop that starts with a product decision and ends with a verified GrowthBook state.

GrowthBook's MCP server changed substantially with version 2. Instead of exposing a long list of fixed endpoint wrappers, the current server provides a thin API bridge plus official agent skills. The skills tell an AI assistant how to complete a workflow, where to pause for approval, which failure states matter, and what to verify after a change.

That makes the server more capable than its 3 top-level tools suggest. growthbook_list_skills discovers the available workflows. growthbook_read_skill loads the detailed instructions. growthbook_call_api performs authenticated GrowthBook REST operations. The current GrowthBook skills repository includes more than 20 workflows across feature flag revisions, targeting, ramping, monitored rollouts, experiment design and analysis, metric discovery, and charts.

Here are 5 things a product or engineering team can do now. Each example includes a starting prompt and the boundary that keeps the workflow trustworthy.

Why the current skill model changes the answer

An older list of GrowthBook MCP features might name create_feature_flag, get_experiments, or generate_flag_types as separate tools. Those names described version 1. The current server follows a different architecture: it loads procedural skills, then uses a generic authenticated API call for the exact endpoint the workflow requires.

The distinction is operationally important. The MCP server concepts guide explains how tools expose typed operations. Skills add the sequence around those operations: resolve identifiers, inspect current state, prepare a payload, pause before a mutation, handle known failure paths, and read back the result. The server can add or improve a workflow by updating a versioned skill instead of expanding an undifferentiated tool list.

This design also makes capability discovery part of the task. A good prompt can ask the agent to list available skills and read the matching one before acting. If the installed server lacks the expected workflow, the agent should say so rather than improvising from a stale blog post.

The Agent Skills specification is client-independent, so the same GrowthBook workflow can be used by compatible agents outside the MCP server as well. MCP provides the live connection; the skill provides the operating method.

What these 5 workflows do not promise

The server does not make product judgment automatic. It does not create trustworthy metrics from vague names, prove that a code branch is safe to delete, guarantee that an experiment will win, or make a production flag change risk-free. It gives an agent current context and a reviewed procedure for reaching the next decision.

That boundary reflects a recurring practitioner concern. Early community discussion of the GrowthBook MCP server focused on the visible endpoint tools. The current implementation is broader, but it also asks teams to govern more complete workflows. The relevant question has moved from "Can the assistant call this function?" to "Can the team audit the full path from intent to verified state?"

1. Launch an A/B test from a product hypothesis

The experiment workflow starts before an API call. experiment-design turns a rough idea into a launchable spec: hypothesis, variations, primary metric, guardrails, assignment unit, target population, and sample-size considerations. It reads current GrowthBook context but does not launch anything.

experiment-launch then resolves a datasource, assignment query, metrics, projects, and owners. It can create the experiment, prepare or reuse a feature flag, wire an experiment-reference rule, and call the start endpoint. It also handles pre-launch checklist failures rather than treating a rejected start as a generic error.

Try this prompt:

Use GrowthBook's experiment-design skill. Design an A/B test for a shorter checkout form. The primary outcome is completed purchase; page errors and refund requests are guardrails. Use our existing GrowthBook metrics. Produce the spec only and do not create anything.

Review the metric IDs and assignment unit. Then hand the approved spec to experiment-launch:

Launch the approved checkout experiment in project checkout. Use the existing short-checkout flag if it is compatible. Show every proposed write and wait for confirmation before creating or starting anything.

The assistant should not invent a metric, datasource, or project because the names sound plausible. GrowthBook's current skills explicitly avoid metric and datasource creation. Create those definitions in the platform first, then reference their IDs. The GrowthBook experimentation platform is the system of record for the resulting experiment and results.

The practical benefit is not that a prompt replaces experiment design. It is that the prompt can pull existing definitions, defaults, and checks into the design conversation while the team is still in the IDE or product-planning context.

Choose stronger test metrics

Build a primary-metric and guardrail set that answers the product question without hiding important costs.

Read the KPI Playbook

2. Ship a feature behind a controlled flag

AI coding tools can produce a feature faster than a team can review its release plan. The GrowthBook flag skills make release control part of the same workflow.

flag-create checks for an ID collision, resolves project and owner, confirms the value type, and creates a new flag disabled in every environment. That default matters. Creating a flag should not expose unfinished behavior.

From there, flag-targeting can add a force or rollout rule with conditions, saved groups, and prerequisites. flag-ramp can build a multi-step schedule with intervals or manual gates. flag-monitoring adds guardrail metrics and optional rollback behavior to a progressive rollout. The feature flag platform keeps the live configuration separate from the code deployment.

Start with:

Create a Boolean flag named new-billing-summary in project billing. Keep it disabled in every environment. After creation, show the readback and stop.

Then add exposure deliberately:

Propose a production targeting rule for employees and the saved design-partners group. Do not publish the revision. Show the resolved attribute conditions and percentage ranges.

The current skills respect GrowthBook's revision lifecycle. A draft can be reviewed, approved, and published through separate skills. That prevents "add a rule" from silently becoming "change production."

3. Read experiment results in a decision-ready summary

An experiment results page can contain dozens of metrics, dimensions, and statistical fields. The experiment-analyze skill turns that payload into a structured review without skipping the checks that make the conclusion credible.

The workflow resolves the experiment, triggers a fresh snapshot when appropriate, polls for completion, checks sample ratio mismatch (SRM), and interprets lift, intervals, probability or p-values, and guardrails. It distinguishes a data-quality warning from a flat result and a flat result from evidence of no meaningful effect.

Ask:

Analyze the latest results for experiment <id>. Check SRM first. Summarize the primary metric, guardrails, confidence intervals, and practical effect size. Do not recommend shipping if data quality is invalid or the decision rule is not met.

The GrowthBook experiment docs remain the canonical configuration reference. The agent's summary should include the experiment ID, snapshot timing, metric names, variation mapping, and warnings so a reviewer can reproduce it.

This workflow is useful in engineering standups and product reviews because it reduces dashboard navigation. It does not make statistical judgment automatic. The team still owns the decision threshold, opportunity cost, and product context.

4. Audit and remove stale feature flags safely

Feature flags create options during delivery and obligations afterward. A stale flag leaves branches in code, rules in GrowthBook, and ambiguity for the next engineer.

The current workflow separates discovery from cleanup. flag-search can audit flags by project, owner, tag, environment state, and staleness without changing anything. flag-cleanup then walks through code-site inlining, archived state, verification, and eventual deletion. It treats archive and delete as separate gates.

Start with an audit:

Search project checkout for temporary flags that are stale, have no active experiment, and are fully rolled out in production. Return IDs, owners, environments, code references, and recommended next action. Do not archive or delete anything.

For one reviewed candidate:

Read the flag-cleanup skill for <flag-id>. Locate and classify every code reference. Propose the replacement value for each site, run tests after the code change, and stop before archiving the GrowthBook flag.

The key boundary is that an MCP agent should not claim fully automatic stale-code removal. Code references can hide inverted logic, server/client differences, generated code, and fallback behavior. GrowthBook's feature flag best practices support lifecycle ownership; engineering review still decides whether the old branch is safe to remove.

5. Search metrics and build Product Analytics charts

The v2 skills extend MCP beyond flags and experiments. metric-search can list and audit fact metrics and fact tables, including definitions, columns, and whether a metric is chartable. analytics-explore can build and run a metric-over-time chart, aggregate a fact table, or query a raw warehouse table, returning the numbers and a deep link to the rendered chart.

Try:

Search fact metrics related to checkout completion. Return each metric ID, numerator and denominator when applicable, fact table, owner, projects, and whether it can be used in Product Analytics. Do not create or update metrics.

Then:

Build a weekly chart for the selected checkout-completion metric over the last 12 weeks. Break it down by device category. Run the query, summarize the values, and return the GrowthBook chart link.

The current skills do not create metrics or datasources. That limitation is useful: it keeps semantic definitions in a reviewed layer while letting the agent explore them through GrowthBook Product Analytics. If the chart surfaces a meaningful segment shift, the workflow can hand off to experiment-design for a testable follow-up.

The GrowthBook 5.0 release describes this broader agentic direction: official skills are shared across the MCP server and in-app assistant, while Product Analytics can reuse experimentation metrics and fact tables.

Pick one workflow and require a receipt

Do not enable all writes on day 1. Pick the workflow that removes the most repeated friction, run it read-only, and compare the output with GrowthBook.

For every write, require a receipt containing:

• the skill and API method used
• the GrowthBook project and environment
• the flag, experiment, metric, or chart IDs
• the before and after state
• whether the change is proposed, draft, approved, published, running, stopped, archived, or deleted
• any checklist, SRM, permission, conflict, or verification warning

The server is open source and published through npm, but trust still depends on your token scope, client approvals, and review process. Community discussions about MCP repeatedly return to the same lesson: the useful server is the one that reaches real context without quietly expanding its authority.

Write prompts that expose assumptions

The strongest prompt names the project, environment, target object, desired final state, and write boundary. It also tells the agent what evidence to return. Compare these 2 requests:

Roll out the new checkout.

In project checkout, inspect flag new-checkout. Propose a production rollout from 10% to 25% for the existing eligible audience. Check active experiments, prerequisites, draft revisions, and monitoring first. Show the exact draft change and wait for confirmation. Do not publish.

The second prompt does not micromanage the API. It defines the business scope and safety boundary. The selected skill can fill in the correct sequence while the human retains control of the material decision.

For read workflows, require source identifiers and timestamps. For writes, require before/after state and lifecycle status. For analysis, require data-quality warnings and uncertainty. These receipts make MCP work reviewable in the same way a pull request makes code changes reviewable.

GrowthBook's current MCP server can support complete product-development loops right now. The best first use is not the most dramatic. It is the one your team can verify end to end.

Improve experiment decisions

Review the setup and post-test checks that help teams move quickly without mistaking noisy results for product truth.

Read the Trustworthy Checklist