How to set up GrowthBook MCP Server for Cursor

The point of the GrowthBook MCP Server is not convenience. It is putting release controls where AI-generated code is created.

Cursor can already help write code. The GrowthBook MCP Server lets it work with the feature flags, experiments, metrics, and docs that decide whether that code should reach users.

This setup guide covers the current Cursor path, the GrowthBook environment variables, how to verify the connection, and the prompts that keep the agent inside a safe release workflow.

What the GrowthBook MCP Server gives Cursor

The GrowthBook MCP Server docs define MCP as the standard way to connect AI tools and agents with developer platforms like GrowthBook. Once connected, the server exposes tools for:

• Creating feature flags.
• Listing and inspecting feature flags.
• Creating force rules for targeted access.
• Generating TypeScript types for flags.
• Creating feature flag experiments.
• Reading experiment metadata and summaries.
• Listing attributes, environments, projects, SDK connections, and metrics.
• Searching GrowthBook documentation from the AI tool.

That means Cursor can create the GrowthBook object and edit the code in one workflow. It also means permissions matter. The API key or personal access token should match the work the agent is allowed to do.

The broader Model Context Protocol introduction explains the client-server model behind this pattern. For Cursor, also keep the official tool docs nearby: Cursor docs and Cursor MCP guidance.

Prerequisites

Before you configure the server, collect:

• Node.js, because the server runs through npx.
• A GrowthBook API key or personal access token.
• The GrowthBook email address associated with the user.
• The GrowthBook API URL and app origin if you are not using GrowthBook Cloud.
• Any proxy headers needed for self-hosted or protected deployments.

GrowthBook Cloud usually only needs GB_API_KEY and GB_EMAIL. Self-hosted teams often need GB_API_URL, GB_APP_ORIGIN, and possibly GB_HTTP_HEADER_* values.

Install the server

{
"mcpServers": {
"growthbook": {
"command": "npx",
"args": ["-y", "@growthbook/mcp@latest"],
"env": {
"GB_API_KEY": "YOUR_API_KEY",
"GB_API_URL": "https://api.growthbook.io",
"GB_APP_ORIGIN": "https://app.growthbook.io",
"GB_EMAIL": "YOUR_EMAIL"
}
}
}
}

In Cursor, open Settings -> MCP, add a new global server, save the configuration, and confirm the server shows an active status.

Do not commit API keys to the repository. Use local environment variables, secret storage, or a user-level MCP config. If the MCP config lives in the project, keep secrets out of the file and reference environment variables instead.

Verify what Cursor can do

After the connection is active, test read-only behavior first:

List my GrowthBook projects and environments.
Search the GrowthBook docs for feature flag experiments.
Show me the SDK connections available for this project.

Then test a low-risk write in a sandbox project:

Create a boolean feature flag named mcp_test_flag.
Default it to false.
Do not add targeting rules.
Return the GrowthBook URL and explain how to delete it.

If that works, the integration is ready for real code tasks.

Use prompts that include release constraints

The best prompts give Cursor a job and a boundary:

Create a GrowthBook feature flag for the checkout summary redesign.
Default it to false.
Wrap only the checkout summary component.
Keep the old component as fallback.
Add tests for flag on and flag off.
Do not enable the flag for production users.
Return the flag URL and changed files.

For experiments, include metric constraints:

Create a GrowthBook experiment linked to new_checkout_summary.
Use checkout_completion_rate as the primary metric if it exists.
Use error_rate and page_latency as guardrails if available.
If a metric is missing, stop and report the gap.

The final sentence prevents the agent from inventing measurement.

Troubleshoot common setup problems

If the server does not appear active:

• Confirm node -v works.
• Confirm npx -y @growthbook/mcp@latest can run.
• Confirm the API key has the permissions required for the requested tools.
• Confirm GB_EMAIL is set.
• Confirm self-hosted API and app URLs point to the right GrowthBook instance.
• Check proxy headers if GrowthBook sits behind Cloudflare Access or another private gateway.

If read tools work but write tools fail, treat it as a permissions issue before treating it as a code issue.

Where GrowthBook fits

The MCP setup is worth doing because it makes GrowthBook part of the agent's actual workflow. Cursor can create a flag, wrap code, check docs, and draft an experiment spec without forcing the developer to copy details between systems.

That does not remove review. It makes review easier. The flag URL, code diff, rollout rule, and experiment plan can all be inspected before exposure changes.

Start with one sandbox flag. Then use the same path for a real feature that needs controlled rollout.

For follow-up implementation, keep the GrowthBook feature flags page, GrowthBook experimentation page, AI-native development page, SDK docs, and feature flag experiment docs close to the workflow. For platform setup, verify Node.js, the official MCP Registry, Cursor documentation, Cursor MCP guidance, and the Model Context Protocol introduction.

Production setup checklist

Before using the server for production objects, walk through this checklist:

• Create a dedicated API key or personal access token for the agent workflow.
• Confirm the key can do the intended task and no more.
• Decide whether the MCP config is user-level or project-level.
• Keep secrets outside committed files.
• Test read-only commands before write commands.
• Create one sandbox flag and delete it.
• Confirm the agent returns links to GrowthBook objects it creates.
• Document the exact prompt pattern the team should use for flags and experiments.

This checklist prevents a quiet permissions drift. MCP servers are powerful because they turn external systems into agent tools. That same power means the setup should be owned like any other production integration.

How to introduce this to a team

Do not start by asking every developer to install every AI integration. Start with one repository and one workflow:

1. Connect Cursor to GrowthBook.
2. Create a sandbox flag.
3. Wrap a small component or backend branch.
4. Add tests for both states.
5. Review the GrowthBook flag and code diff together.
6. Remove the sandbox flag.

Once that loop is reliable, make a short team guide. Include the install command, required environment variables, prompt examples, and rules about production targeting. The goal is not to make every developer an MCP expert. The goal is to make safe flag creation boring.

Permission model for a real team

The first working setup is usually personal: one developer, one API key, one local MCP config. A team setup needs more structure. Decide which of these modes you want:

Most teams should start with read-only or sandbox write access. Move to scoped production access only after prompts, review, and cleanup rules are documented.

Project-level versus user-level configuration

Cursor setup can live in different places depending on the client. A user-level config is better for secrets and individual experimentation. A project-level config is better for repeatable team setup, but it must reference environment variables rather than hard-coded tokens.

Document both:

• Where the MCP server is configured.
• Which environment variables are required.
• Which GrowthBook project and environment the key can access.
• How to rotate the token.
• Who owns the integration when it breaks.

This prevents a common failure mode: the demo works on one laptop, but the team cannot reproduce it without copying a private token.

Verification prompts for launch readiness

After setup, run a read-only prompt, a sandbox-write prompt, and a review prompt:

List GrowthBook projects and environments I can access.
Do not create or modify anything.Create a sandbox boolean flag named mcp_setup_check.
Default it to false.
Do not target any production users.
Return the object URL and deletion steps.Review the MCP setup for risk.
Check token scope, environment variables, project targeting, secret handling, and whether production writes require human review.

If Cursor cannot answer those prompts clearly, fix setup before moving to real feature work.

Practical implementation playbook

Treat growthbook mcp for cursor as a workflow, not a one-off prompt. The teams that get the most value from AI coding tools do three things consistently: they narrow the task, keep release state in GrowthBook, and make the final output reviewable by humans who were not in the original chat.

Step 1: Write the release contract

Before code changes, define the contract in a few sentences:

Change:
User-visible behavior:
GrowthBook flag:
Default value:
Fallback:
Owner:
Primary metric:
Guardrails:
Cleanup condition:

The agent can help fill missing fields, but it should not silently invent them. If the primary metric or owner is missing, the right next step is a gap report.

Step 2: Inspect before editing

Ask the tool to inspect existing patterns first:

• Where does the app initialize the GrowthBook SDK?
• Which helper functions or hooks evaluate flags?
• How are tests written for feature-flagged behavior?
• Where do analytics events fire?
• Which files are likely to change?

This keeps the first implementation from creating a second GrowthBook client, duplicating SDK logic, or placing a flag check too high in the component tree.

Step 3: Make one controlled change

The first pass should be deliberately small. Create or reference one flag, preserve one fallback, and test both states. If the agent discovers a useful refactor, capture it as a separate follow-up. Do not let a flag implementation turn into a cleanup project, design-system rewrite, and analytics migration in the same pull request.

Step 4: Review for release risk

Use the agent again, but switch it into review mode:

Review this AI-assisted change for release risk.
Check flag key consistency, fallback behavior, test coverage, analytics parity, targeting assumptions, and cleanup notes.
List blockers first.
Do not modify files.

This prompt usually finds a different class of issues than normal linting. It looks for the ways a change can be technically valid but operationally unsafe.

Step 5: Expose gradually

Deployment and release should stay separate. Deploy the code with the default safe value. Use GrowthBook to expose the change to internal users, a beta segment, a percentage rollout, or an experiment audience. If the change needs evidence, connect it to an experiment before broad exposure.

Step 6: Close the loop

The workflow is not done when the flag turns on. It is done when one of these outcomes happens:

• The treatment ships and temporary branching logic is removed.
• The treatment loses and the new path is removed.
• The test is inconclusive and the next iteration is defined.
• The rollout is paused because a guardrail or QA issue appeared.

Ask the agent for cleanup only after the human-owned decision is clear.

Example review packet

A good final packet should fit in a pull request comment:

• GrowthBook object: new_checkout_summary flag and linked experiment.
• Default: false for all production users.
• Fallback: existing checkout summary component.
• Treatment: new summary component with revised copy and layout.
• Tests: unit tests for off/on states and one integration smoke test.
• Metrics: checkout completion as primary, error rate and latency as guardrails.
• Rollout: internal staff, beta accounts, then experiment traffic.
• Cleanup: remove losing branch or graduate winning branch after decision.

This packet is not bureaucracy. It is the artifact that lets someone review the work without trusting a chat transcript.