How to set up the GrowthBook MCP server for VS Code

A server is not connected just because mcp.json parses. VS Code must start the process, trust it, discover the current GrowthBook skills, authenticate, and return the right workspace data.

VS Code now has native Model Context Protocol support in its agent experience. You can add MCP servers from the gallery, the Command Palette, the command line, or an mcp.json file. For GrowthBook, the most transparent setup is a local stdio server launched with the official @growthbook/mcp npm package.

This guide uses GrowthBook MCP 2.0, the current stable package as of August 2026. Version 2 is intentionally thin. It exposes growthbook_list_skills, growthbook_read_skill, and growthbook_call_api. The bundled skills define safe workflows; the API bridge performs authenticated reads and writes. That differs from the older fixed tool list still visible in parts of the GrowthBook MCP documentation.

If your team already has the GrowthBook setup guides for Cursor and Claude Code, pay attention to 2 VS Code-specific differences: the root configuration key is servers, not mcpServers, and VS Code can securely prompt for a token through an input variable rather than storing the literal value in your workspace file.

Confirm VS Code, Node.js, and GrowthBook access

You need a current VS Code build with the agent experience enabled, a compatible GitHub Copilot plan or agent harness, Node.js 18 or later, and a GrowthBook Cloud or self-hosted account.

Check the local runtime in VS Code's integrated terminal:

node -v
npm -v
npx --version

The GrowthBook server runs through npx -y @growthbook/mcp@latest. The -y flag accepts the package runner prompt so VS Code can start the server without waiting for terminal input.

Verify the package identity on the official npm page and inspect the GrowthBook-owned source repository. VS Code warns that local MCP servers can run arbitrary code on your machine, so review the publisher and command before trusting it.

Create a dedicated GrowthBook PAT

Use a Personal Access Token tied to the user who should own and approve the resulting work. For a read-only pilot, grant only the permissions needed to list projects, flags, experiments, and metrics. Expand permissions when the team is ready to test reviewable writes.

Do not paste the PAT into chat. Do not add it directly to a committed .vscode/mcp.json. VS Code's MCP configuration reference supports password-style input variables that prompt once and store the value securely.

GrowthBook Cloud needs GB_API_KEY. A self-hosted instance also needs GB_API_URL, set to the HTTPS API base URL without an endpoint suffix such as /api/v1.

Choose user or workspace scope

The VS Code MCP management guide offers 2 main configuration locations:

• User profile: Available across workspaces in the current VS Code profile. Open it with MCP: Open User Configuration.
• Workspace: Stored at .vscode/mcp.json. Use it when the server configuration belongs to one project and can be reviewed by the team.

A shared workspace file can include the server command and input placeholder, but not the secret. Use user scope when different developers need different GrowthBook organizations or self-hosted URLs.

Separate connection config from workflow policy

The server block answers how VS Code reaches GrowthBook. It should not be the only place your team records how agents may use that access. Put stable operating rules in repository instructions: which GrowthBook project maps to the codebase, which environments are production, which flag owners can approve changes, and which actions always require a human review.

This separation keeps the MCP connection reusable while letting each repository define tighter constraints. A frontend repository might permit read-only flag search and type inspection. A platform repository might also permit draft targeting changes. Neither needs unrestricted authority over every GrowthBook project.

GrowthBook's AI-native development model is strongest when the agent works inside the same release controls as a human. Configure the credential and VS Code trust boundary first, then use skills to preserve flag revisions, reviews, experiment pre-launch checks, and result verification.

Add the secure GrowthBook configuration

Open the Command Palette with Ctrl+Shift+P on Windows or Linux, then run MCP: Open User Configuration or MCP: Open Workspace Folder MCP Configuration.

For macOS and Linux, use:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "growthbook-api-key",
      "description": "GrowthBook Personal Access Token",
      "password": true
    }
  ],
  "servers": {
    "growthbook": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@growthbook/mcp@latest"],
      "env": {
        "GB_API_KEY": "${input:growthbook-api-key}"
      }
    }
  }
}

For a self-hosted instance, add GB_API_URL under env:

"GB_API_URL": "https://growthbook-api.example.com"

VS Code prompts for the PAT when the server first starts. Because password is true, the input is masked and stored for later use. If the token is revoked, reset or edit the stored input and start the server again.

Plan feature flags at scale

Pair your new editor workflow with the architecture, ownership, and lifecycle practices that keep feature flags maintainable.

Read the Feature Flag Guide

Adjust the command for Windows or remote development

The JSON above works when VS Code can resolve npx directly. Windows installations sometimes need the command shell wrapper used in GrowthBook's editor examples:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "growthbook-api-key",
      "description": "GrowthBook Personal Access Token",
      "password": true
    }
  ],
  "servers": {
    "growthbook": {
      "type": "stdio",
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@growthbook/mcp@latest"],
      "env": {
        "GB_API_KEY": "${input:growthbook-api-key}"
      }
    }
  }
}

Use this only when direct npx startup fails. The VS Code output log will show whether the command was not found, the package failed to download, or the MCP handshake closed unexpectedly.

Understand where the server actually runs

User-profile servers run on your local machine. When you connect VS Code to SSH, WSL, or a Dev Container, a workspace or remote-user server can run in the remote environment instead. That affects which Node.js installation, network route, and environment variables are available.

Run MCP: Open Remote User Configuration when the server must live beside a remote codebase. Confirm that the remote machine can reach your GrowthBook API and that its PAT handling meets your security policy.

VS Code also supports MCP configuration in devcontainer.json. That is useful for sharing the package command, but secrets should still come from an input, environment file, or approved container secret mechanism. Do not bake the PAT into the image.

Account for the Agent Host

Current VS Code documentation notes that Agent Host does not read .vscode/mcp.json directly. VS Code forwards most server configurations, but interactive ${input:...} values are an exception. For a portable Agent Host configuration, use a workspace .mcp.json or user ~/.copilot/mcp-config.json, then supply secrets through a supported environment source.

This is a deployment choice, not a reason to hardcode the token. First get the local extension-host workflow working. Then move the same server to the host where your agent session actually runs.

Start the server and inspect the live capabilities

After saving mcp.json, use the inline Start action or run MCP: List Servers, select growthbook, and choose Start. VS Code asks you to trust a new or changed local server before it runs. Review the exact package command in the trust dialog.

When the server starts, VS Code discovers its capabilities. Open Chat, select Configure Tools, and look for the growthbook_ prefix. The current package should show:

• growthbook_list_skills
• growthbook_read_skill
• growthbook_call_api

If you see an older list of endpoint-specific tools, the server package or cached tool catalog may be stale. Run MCP: Reset Cached Tools, restart the server, and confirm the npm version. GrowthBook 2.0 bundles the latest skill snapshot available when that release was built.

Verify with a read-only prompt

Use a prompt that states scope and prohibits changes:

Use the GrowthBook MCP server. List the available GrowthBook skills, read flag-search, and list flags for project <project> in environment <environment>. Do not call POST, PUT, PATCH, or DELETE.

The response should identify the selected skill, resolve the project and environment, and return the current flag state. Compare it with GrowthBook Feature Flags or the app. A readable answer is not enough if it silently chose the wrong project.

Then test another read-only workflow:

Read metric-search and list fact metrics that are chartable for datasource <datasource>. Include metric IDs and fact table names. Do not create or update anything.

That proves the skill layer and generic API bridge work beyond a single endpoint. The current skill catalog covers experimentation, feature flag revisions, targeting, monitoring, metric discovery, and Product Analytics charts.

Troubleshoot in dependency order

When the tools do not appear, do not start by changing GrowthBook permissions. Work through the layers.

The server does not start

Run node -v and npx --version in the environment where the server runs. On Windows, switch to the cmd /c wrapper. If the first package download exceeds the startup window, restart after the package is cached. Open the MCP output through MCP: List Servers and choose Show Output.

The server starts but returns 401

The PAT is missing, malformed, expired, or revoked. Re-enter the password input. If the value was exposed, revoke it rather than continuing to debug with the compromised credential.

The server returns 403

The credential authenticated but lacks permission for the requested resource or action. Keep the narrow token and adjust the role deliberately. Do not replace it with an admin token just to make the error disappear.

The agent cannot see the server remotely

Confirm whether the server was added to local user, remote user, workspace, Agent Host, or container configuration. Community reports frequently trace extension-versus-terminal differences to config scope. Use the environment's own MCP: List Servers view instead of assuming every host reads the same file.

The agent chooses the wrong workflow

Ask it to list and read the matching skill before calling the API. The current GrowthBook skills library gives each workflow explicit triggers, inputs, write boundaries, and handoffs. A vague prompt can still select the wrong sibling skill, especially between flag creation, targeting, experiment launch, and cleanup.

Roll the setup out to a team without sharing secrets

A team-ready setup has 3 layers. Commit only the server shape and non-secret defaults. Let each developer provide a personal PAT through the input variable. Maintain project and environment conventions in reviewed repository instructions.

For centrally managed VS Code deployments, administrators can control which MCP servers are allowed. Use that policy to restrict packages and remote endpoints, but keep GrowthBook's own permissions as the final authority. The GrowthBook REST API evaluates the token on every request; a local trust prompt cannot grant a permission the API rejects.

Create a short onboarding check that every developer can repeat:

1. Start the server and inspect its command.
2. List bundled skills and confirm the expected version behavior.
3. Run one read-only flag search in the repository's project.
4. Run one metric search and identify a chartable metric.
5. Confirm that a proposed write prompts for approval and remains in draft when the workflow requires it.

This also creates a useful support boundary. If step 1 fails, investigate Node.js and VS Code. If step 2 fails, inspect the package and tool cache. If steps 3 or 4 fail, inspect the GrowthBook URL and token. If step 5 skips review, fix tool approvals and workflow instructions before granting broader access.

The analytics checks are not decorative. A team can use the same trusted fact metrics in experimentation and GrowthBook Product Analytics. Confirming metric discovery during onboarding proves that the agent can reach the measurement layer, not only the release-control layer.

Make the first write reversible

Once the reads match the UI, test a disabled flag in a sandbox project:

Read the flag-create skill. Propose a Boolean flag named vscode-mcp-check in project <sandbox-project>. It must remain disabled in every environment. Show the exact action and wait for confirmation before writing.

Review the proposed ID, type, project, and default value. After confirmation, require a readback receipt. Do not make the first write a production toggle, an experiment launch, or a bulk stale-flag cleanup.

VS Code makes MCP installation easy. The quality of the result still depends on package trust, token scope, configuration location, live skill discovery, and explicit write review. When those layers are correct, GrowthBook becomes available in the editor without turning natural language into an uncontrolled production interface.

Improve experiment decisions

Review the setup, metric, and post-test checks that help teams trust results before they ship a winner.

Read the Trustworthy Checklist