Kameleoon MCP server - Kameleoon Documentation

The Kameleoon Model Context Protocol (MCP) server connects AI coding assistants directly to your Kameleoon project, enabling agentic workflows for experiments and feature flags. Beyond reading configurations and pulling variation code, your AI assistant can build and manage experiments, feature flags, goals, segments, and targeting rules, and run the full rollout lifecycle, all from your development environment. Register and authenticate the server to automate your implementation lifecycle, from a winning variation to a gated production rollout.

Features

After you connect the server, your AI agent can interact with Kameleoon to:

Discover and inspect experiments, feature flags, goals, segments, and targeting rules.
Build experiments end to end: create, duplicate, and run the full lifecycle (start, pause, resume, stop, delete).
Manage feature flags: create, duplicate, delete, toggle per environment, and review the change history.
Configure flag delivery: add targeted and experimentation rules, custom variations, and typed variables.
Create and maintain goals and audience segments, and bind segments to experiments.
Analyze experiment and feature-flag-experiment results, and pull raw variation code (JavaScript and CSS).
Automate the full implementation lifecycle, from a winning variation to a gated production rollout.

The primary workflow: Winning experiment to production

The Kameleoon MCP server automates the “last mile” of implementation. Without leaving the IDE, you can instruct your AI assistant to execute the following workflow:

Retrieve experiment results and identify the winning variation.
Extract the variation’s raw code from Kameleoon.
Convert the code into native, production-ready code (such as React components) aligned with the existing codebase.
Create a feature flag in Kameleoon.
Wrap the new implementation behind the feature flag.
Enable and validate the feature in production.

Token usage and plan considerations

Connecting the Kameleoon MCP server to an AI assistant adds a small, fixed overhead: the tool schemas that describe the available actions. This overhead stays flat regardless of which plan the assistant runs on. The token cost of a workflow comes from the work itself, not from the connection. The following factors drive usage:

The amount of data a workflow retrieves, such as full experiment configurations, variation code, or activity logs.
The amount of code the assistant generates or converts, for example when transposing a winning variation into native application code.
The number of sites or brands a single workflow touches. Duplicating and auditing experiments across three sites consumes proportionally more tokens than running the same operation on one site.
How broadly you scope a single prompt. A narrow, single-site check consumes far less than an open-ended request to review every experiment across every site.

Before you commit a team to a specific AI assistant plan, scope your expected workflows: how many sites or brands they touch, how often you run them, and whether they include large data-retrieval or code-generation steps. Recurring, multi-site workflows need a plan with a larger usage allowance or context window than a plan sized for occasional, single-site prompts. Check your AI assistant provider’s plan documentation for its specific usage limits and context window size.

Available tools

The server exposes the tools below, grouped by area. Each tool maps to a single, well-scoped action, so you can compose them into larger workflows (for example: read results, pull code, create a flag, add a rule, enable it).

Experiments

Build, inspect, and run A/B tests (Web Experiments).

Tool	Description	Example prompt
`experiment_list`	Find experiments by name or ID. Returns paginated summaries (id, name, status, and tags).	”List active experiments on site `d1alzzxd7k`.”
`experiment_get`	Retrieve an experiment’s full configuration: variations, traffic split, goals, and targeting.	”Show the configuration for experiment `149640`.”
`experiment_code_get`	Pull a variation’s raw JavaScript, CSS, and custom JSON, plus the experiment’s shared common JS and CSS.	”Pull the code for variation 1 of experiment `149640`.”
`experiment_results_get`	Fetch statistical results: per-variation conversion rates, significance, confidence intervals, and the winner.	”Summarize results for experiment `149640`.”
`experiment_create`	Create a draft experiment (type, base URL, goals, optional common code).	”Create a CLASSIC experiment `Homepage hero` on site `d1alzzxd7k`.”
`experiment_duplicate`	Clone an experiment into a new draft, copying variations, code, deviations, and targeting.	”Duplicate experiment `149640`.”
`experiment_lifecycle_update`	Drive the lifecycle: start, pause, resume, stop, or delete (stop and delete require confirmation).	”Start experiment `149640`.”

Feature flags

Create and operate feature flags, toggle them per environment, and read their history and results.

Tool	Description	Example prompt
`feature_flag_list`	Find feature flags by key, name, or ID.	”List all feature flags for site `d1alzzxd7k`.”
`feature_flag_get`	Retrieve a flag’s full configuration in an environment: variations, variables, primary goal, and rule chain.	”Show configuration for flag `snake_game`.”
`feature_flag_create`	Create a flag with default `on` and `off` variations.	”Create a flag `ui_refresh` for site `d1alzzxd7k`.”
`feature_flag_duplicate`	Clone an existing flag (the copy starts disabled in every environment).	”Duplicate the `new_search` flag.”
`feature_flag_delete`	Permanently delete a flag and all of its configuration.	”Delete the flag `ui_refresh`.”
`feature_flag_enable`	Turn the per-environment master switch ON so the SDK evaluates rules.	”Enable `new_search` in production.”
`feature_flag_disable`	Turn the per-environment master switch OFF (rules are preserved).	”Disable `new_search` in staging.”
`feature_flag_activity_logs_get`	Read the audit trail of flag changes (who changed what, and when).	”Show the recent change history for our feature flags.”
`feature_flag_experiment_results_get`	Fetch statistical results for a flag’s experimentation rule.	”Get the experiment results for the rule on `new_search`.”

Flag delivery, variations, and variables

Shape how a flag is delivered, and define the variations and typed variables it serves.

Tool	Description	Example prompt
`feature_flag_rule_targeted_create`	Add a targeted delivery rule: serve one variation to a percentage of traffic, with optional scheduling.	”Roll `new_search` out to 20% in production.”
`feature_flag_rule_experimentation_create`	Add an A/B experimentation rule that splits traffic across variations with statistical tracking.	”A/B test `off` vs `on` 50/50 on `new_search`.”
`feature_flag_variation_create`	Add a custom variation (a named state of the feature) to a flag.	”Add a `variant_a` variation to `new_search`.”
`feature_flag_variable_create`	Define a typed variable (BOOLEAN, NUMBER, STRING, JSON, JS, CSS, ENUM) with a default value.	”Add a STRING variable `label` defaulting to `Search`.”
`feature_flag_variation_variable_set`	Override a variable’s value for one specific variation.	”Set `label` to `Find` on `variant_a`.”

Goals

Create and maintain the conversion goals used by experiments and flags.

Tool	Description	Example prompt
`goal_list`	Browse goals on a site, with usage counts across experiments, flags, and personalizations.	”List goals for site `d1alzzxd7k`.”
`goal_get`	Inspect a goal’s type configuration, tags, and usage counts.	”Show goal `271552`.”
`goal_search`	Find a goal by a substring of its name.	”Search goals for `checkout`.”
`goal_create`	Create a goal of any type (URL, CLICK, SCROLL, PAGE_VIEWS, TIME_SPENT, CUSTOM, and more).	”Create a URL goal that matches `/thank-you`.”
`goal_update`	Edit a goal’s name, description, tags, tracking tools, or multiple-conversions setting.	”Rename goal `271552` to `Signup complete`.”
`goal_update_type`	Switch a goal’s type and replace its type-specific configuration (tags are preserved).	”Change goal `271552` to a CLICK goal.”
`goal_delete`	Permanently delete a goal.	”Delete goal `271552`.”

Segments

Define and inspect the audiences you target.

Tool	Description	Example prompt
`segment_list`	Browse segments on a site, with usage counts.	”List segments for site `d1alzzxd7k`.”
`segment_get`	Inspect a segment’s condition tree (raw JSON plus a human-readable summary).	”Show segment `200604`.”
`segment_create`	Create an audience segment from a condition tree (geolocation, device, browser, custom data, and more).	”Create a segment for desktop visitors in France.”
`segment_delete`	Delete a segment. The tool blocks deletion by default when the segment is in use; override with force.	”Delete segment `200604`.”

Sites and targeting rules

Discover your projects and bind segments to experiments.

Tool	Description	Example prompt
`site_list`	List the sites (projects) you can access, with each site’s code, name, and tracking status.	”List my Kameleoon sites.”
`targeting_rule_list`	List targeting rules on a site.	”List targeting rules for site `d1alzzxd7k`.”
`targeting_rule_get`	Inspect a single targeting rule (segment, configuration, trigger, and the experiment it belongs to).	”Show targeting rule `118605`.”
`targeting_rule_create`	Bind a segment to an experiment to control who participates.	”Target experiment `149640` to segment `200604`.”

Claude Code integration

Step 1: Register the server

To register the server for your user profile (making it available in all projects), open a terminal and run the following command:

claude mcp add --scope user kameleoon -- npx -y mcp-remote@0.1.37 https://mcp.kameleoon.com/mcp 35535 --static-oauth-client-metadata '{ "scope": "openid" }'

To register the server only for the current project (which adds a .mcp.json file to your repository for team sharing), run:

claude mcp add kameleoon -- npx -y mcp-remote@0.1.37 https://mcp.kameleoon.com/mcp 35535 --static-oauth-client-metadata '{ "scope": "openid" }'

Verify that Claude added the server:

claude mcp list

Expected output: kameleoon: ... - ✗ Failed to connect (A failed connection here is normal because you have not completed authentication yet).

Step 2: Complete OAuth authentication

In the same terminal, trigger the login flow:

npx -y mcp-remote@0.1.37 https://mcp.kameleoon.com/mcp 35535 --static-oauth-client-metadata '{ "scope": "openid" }'

The command automatically opens a browser tab. If it doesn’t, copy the URL printed in the terminal and open it manually.
Sign in to your Kameleoon account.
Click Authorize.
When the browser displays a success message, press Ctrl+C in your terminal.

Verify the connection:

claude mcp list

Expected output: kameleoon: ... - ✓ Connected

Step 3: Start a new Claude Code session

Claude Code makes tools from newly added MCP servers available only in sessions that you start after registering the server. Close your current Claude Code chat and open a new one.

Step 4: Verify the connection

In a new Claude Code conversation, try the following prompts:

“List my Kameleoon feature flags.”
“What experiments are active on site X?”
“Show me the status of experiment Y.”
“Show me the code for variation 1 of experiment Z.”

Claude troubleshooting

Symptom	Cause	Fix
Browser doesn’t open.	Auto-launch failed.	Copy the URL from the terminal and open it manually.
Connection refused on port 35535.	Port is in use.	Run `netstat -ano \| findstr :35535`, kill the process, and retry.
Failed to connect after OAuth.	Token did not persist.	Re-run the Step 2 command to refresh your token.
Tools are not visible in Claude.	Session started before adding the server.	Start a new Claude Code conversation.
`mcpServers` key rejected in `settings.json`.	Wrong file; Claude Code does not use that key.	Use the `claude mcp add` command instead.
Auth error after a long period.	OAuth token expired.	Re-run the Step 2 command.

Antigravity integration

Quick setup

Paste the following self-starter prompt directly into your Antigravity chat to connect automatically:

Connect to the Kameleoon MCP production server. The endpoint is https://mcp.kameleoon.com/mcp, using mcp-remote@0.1.37 on port 35535 with the openid scope. Authenticate by running the npx mcp-remote command to trigger my browser, then verify the connection.

Manual configuration

Edit the configuration file at ~/.gemini/antigravity/mcp_config.json and add the following JSON block:

"kameleoon": {
  "command": "npx",
  "args": [
    "-y",
    "mcp-remote@0.1.37",
    "https://mcp.kameleoon.com/mcp",
    "35535",
    "--static-oauth-client-metadata",
    "{ \"scope\": \"openid\" }"
  ]
}

Codex integration

Quick setup

Paste the following self-starter prompt into your Codex chat:

Configure the Kameleoon MCP server at https://mcp.kameleoon.com/mcp. Use port 35535 for callback. Once configured, run the login command to trigger my browser and then list my feature flags.

Manual configuration

Add the following block to ~/.codex/config.toml. Create the file if it does not exist:

[mcp_servers.kameleoon]
command = "npx"
args = ["-y", "mcp-remote@0.1.37", "https://mcp.kameleoon.com/mcp",
        "35535", "--static-oauth-client-metadata",
        "{ \"scope\": \"openid\" }"]

Authenticate the connection

The Kameleoon MCP server uses OAuth. Run the following command in your terminal to start the authorization flow:

npx -y mcp-remote@0.1.37 https://mcp.kameleoon.com/mcp 35535 \
  --static-oauth-client-metadata '{ "scope": "openid" }'

Expected behavior:

The browser automatically opens a window.
Click Authorize on the Kameleoon login page.
Kameleoon completes the local callback on port 35535.
The terminal confirms that the proxy connected successfully.

A successful connection outputs text similar to the following:

Connected to remote server using StreamableHTTPClientTransport
Local STDIO server running
Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport

Verify tool operations

After you authenticate, run the following checks to confirm the tools work as expected:

List available tools: Confirm that tools/list succeeds and returns the Kameleoon tools. Ensure the output includes the tools listed in the tools table, such as experiment_code_get, feature_flag_list, and feature_flag_create.
Retrieve feature flags: Run feature_flag_list(siteCode = "d1alzzxd7k"). A successful response returns a list of feature flags for the specified site.
Retrieve experiment results: Run experiment_results_get(experimentId = 149640). A successful response includes the experiment name, site code, type, and status.

Cursor integration

Cursor integrates MCP tools directly into the IDE Chat sidebar, which makes them available while you code.

Option 1: Configure via Cursor UI (recommended)

Open Cursor Settings (Cmd+Shift+J on macOS, Ctrl+Shift+J on Windows/Linux).
Navigate to Features > MCP Servers > + Add New MCP Server.
Set the Name to kameleoon.
Set the Type to command.

Enter the following string as the Command:

npx -y mcp-remote@0.1.37 https://mcp.kameleoon.com/mcp 35535 --static-oauth-client-metadata '{ "scope": "openid" }'

Save the configuration.

Option 2: Configure via mcp.json (advanced)

Open ~/.cursor/mcp.json (create the file if it does not exist) and add the following entry to the mcpServers object:

{
  "mcpServers": {
    "kameleoon": {
      "command": "bash",
      "args": [
        "-lc",
        "npx -y mcp-remote@0.1.37 https://mcp.kameleoon.com/mcp 35535 --static-oauth-client-metadata '{ \"scope\": \"openid\" }'"
      ]
    }
  }
}

Restart Cursor after you edit the file manually.

Sample prompts for developer workflows

After you connect the Kameleoon MCP server, use prompts like the following in your IDE:

“List the Kameleoon MCP tools available in this session.”
“Show me all feature flags for site code d1alzzxd7k.”
“Get the details for feature flag new_search on site d1alzzxd7k.”
“Fetch experiment results for experiment 149640 and summarize the current status.”
“Pull the variation code for experiment <experimentId> and variation <variationId>.”

For more advanced workflows, try the following prompts:

“Inspect feature flag new_search for site d1alzzxd7k and explain what environments and variations it currently has.”
“Summarize experiment 149640 for an engineer. Include status, site code, winner state, and whether any variation data is available.”
“List the active feature flags for site d1alzzxd7k and point out any flags that look like stale candidates.”
“Retrieve the code for variation <variationId> in experiment <experimentId> and explain what frontend behavior it changes.”
“Create a new feature flag named <name> with key <featureKey> for site d1alzzxd7k.”
“Turn on feature flag <featureKey> in the staging environment for site d1alzzxd7k.”
“Turn off feature flag <featureKey> in the production environment for site d1alzzxd7k.”

Advanced workflow: End-to-end automation

To experience the full capability of the MCP server, use a comprehensive system prompt. The following example demonstrates how to transpose winning variation code into React components, which is intended primarily for React applications. It instructs the AI agent to handle the entire implementation lifecycle, from retrieving winning results to generating production-ready native code gated behind a new feature flag, and then rolling it out and validating it, all through the MCP tools. Paste the following prompt into your AI assistant:

You are integrating a Kameleoon A/B experiment into a production codebase by converting a Kameleoon PBX variation into maintainable native React code.

**Context**

- Experiment ID: 373001
- Mode: strict_winner_only (default) or manual_variation_conversion (Fallback variation: 1266752)

**Rules**

- Inspect the repo first and follow existing conventions (structure, styling, routing, tests, feature flags).
- Do not copy experiment code directly. Re-implement using idiomatic React (components, hooks, state).
- Do not keep experiment-specific logic (IDs, Kameleoon APIs) in production code.
- Prefer existing feature flag systems for rollout. Use the Kameleoon MCP feature-flag tools to create and gate the flag.
- Avoid DOM manipulation (no querySelector calls, MutationObserver instances, or similar direct DOM APIs).
- Do not add new dependencies unless necessary.
- Do not modify the source experiment's lifecycle (do not stop or delete it) unless explicitly asked.
- Be explicit if something is unclear.

**Workflow steps**

1. Get experiment results (experiment_results_get).
2. Decide integration:
   - Mode A (default: strict_winner_only): Proceed only if winner.status == "clear_winner".
   - Mode B (manual): Use the fallback variation provided in the context.
3. Get the variation code and the prompt that was used (experiment_code_get).
4. Convert the code to React (convert JS code to React components/hooks, and CSS code to the project styling system).
5. Create a feature flag "pbx-winning-experiment-373001" (feature_flag_create). If the implementation needs more than a simple on/off, add variations and typed variables (feature_flag_variation_create, feature_flag_variable_create, feature_flag_variation_variable_set), then gate the converted code behind the flag.
6. Roll out and validate: add a delivery rule (feature_flag_rule_targeted_create for a staged percentage rollout, or feature_flag_rule_experimentation_create to keep measuring), enable the flag in the target environment (feature_flag_enable), and confirm the final configuration with feature_flag_get.

Tool parameters reference

Use the exact tool names and parameter names returned by tools/list. The live MCP schema supports the following parameters.

Experiments

Tool	Required parameters	Optional parameters
`experiment_list`	None	`siteCode`, `filterQuery`, `page`, `perPage`, `sortField`, `sortOrder`
`experiment_get`	`experimentId`	None
`experiment_code_get`	`experimentId`, `variationId`	None
`experiment_results_get`	`experimentId`	None
`experiment_create`	`payload` (`siteCode`, `name`, `type`, `baseURL`)	`payload`: `mainGoalId`, `goals`, `tags`, `description`, `commonJavaScriptCode`, `commonCssCode`, `trafficAllocationMethod`, `collectingDataEnabled`, `multipleTestingCorrection`, `executeCodeForReference`
`experiment_duplicate`	`experimentId`	None
`experiment_lifecycle_update`	`experimentId`, `status`	`confirm` (required for `stopped` and `deleted`), `reason`

experiment_create accepts MVT and SDK_HYBRID as valid type values, but neither can actually be created through this tool. MVT always fails because the API requires mvtVariations (sections and variations) on creation, and no MCP tool exposes that field. SDK_HYBRID always fails with an “Incorrect Experiments type” error, regardless of payload. AI, CLASSIC, DEVELOPER, and PROMPT all create successfully. To create an MVT experiment, call the Automation API directly and follow the steps in Create a multivariate experiment.

Feature flags

Tool	Required parameters	Optional parameters
`feature_flag_list`	None	`siteCode`, `filterQuery`, `page`, `perPage`, `sortField`, `sortOrder`
`feature_flag_get`	`featureKey`, `siteCode`	`environmentKey` (`*` for all environments)
`feature_flag_create`	`siteCode`, `featureKey`, `name`	`description`
`feature_flag_duplicate`	`featureKey`, `siteCode`	None
`feature_flag_delete`	`featureKey`, `siteCode`	None
`feature_flag_enable`	`featureKey`, `siteCode`, `environmentKey`	None
`feature_flag_disable`	`featureKey`, `siteCode`, `environmentKey`	None
`feature_flag_activity_logs_get`	None	`type`, `sortKey` (`timestamp`), `sortOrder`, `page`, `perPage`
`feature_flag_experiment_results_get`	`featureKey`, `siteCode`, `environmentKey`, `experimentId`	None

Flag delivery, variations, and variables

Tool	Required parameters	Optional parameters
`feature_flag_rule_targeted_create`	`siteCode`, `featureKey`, `environmentKey`, `variationKey`, `exposition`, `releaseDateTime`, `timeZone`	`ruleName`
`feature_flag_rule_experimentation_create`	`siteCode`, `featureKey`, `environmentKey`, `controlVariationKey`, `trafficAllocations`, `exposition`, `releaseDateTime`, `timeZone`	`ruleName`
`feature_flag_variation_create`	`siteCode`, `featureKey`, `variationKey`, `variationName`	None
`feature_flag_variable_create`	`siteCode`, `featureKey`, `variableKey`, `variableType`, `defaultValue`	None
`feature_flag_variation_variable_set`	`siteCode`, `featureKey`, `variationKey`, `variableKey`, `value`	None

Goals

Tool	Required parameters	Optional parameters
`goal_list`	None	`siteCode`, `page`, `perPage`
`goal_get`	`goalId`	None
`goal_search`	`query`	`siteCode`, `page`, `perPage`
`goal_create`	`payload` (`name`, `siteCode`, `type`, `hasMultipleConversions`)	`payload`: type-specific params (`matchString`, `matchType`, `scrollType`, `scrollValue`, `timeSeconds`, `pageViews`, `url`, `jsCode`), `tags`, `description`, `status`, `trackingTools`
`goal_update`	`goalId`	`name`, `description`, `tags`, `trackingTools`, `hasMultipleConversions`
`goal_update_type`	`goalId`, `type`	type-specific params
`goal_delete`	`goalId`	None

Segments

Tool	Required parameters	Optional parameters
`segment_list`	None	`siteCode`, `query`, `page`, `perPage`
`segment_get`	`segmentId`	None
`segment_create`	`name`, `siteCode`	`conditionDataTree`, `description`
`segment_delete`	`segmentId`	`force`

Sites and targeting rules

Tool	Required parameters	Optional parameters
`site_list`	None	None
`targeting_rule_list`	None	`siteCode`, `page`, `perPage`
`targeting_rule_get`	`targetingRuleId`	None
`targeting_rule_create`	`segmentConfiguration`, `siteCode`, `experimentId`	`segmentId`, `triggerConfiguration`, `triggerId`, `targetingConfigurationParam`

Accepted enum values: experiment_lifecycle_update.status is started, resumed, paused, stopped, or deleted. Experiment type is AI, CLASSIC, DEVELOPER, MVT, PROMPT, or SDK_HYBRID. Goal type is CLICK, CUSTOM, SCROLL, PAGE_VIEWS, URL, TIME_SPENT, RETENTION_RATE, WAREHOUSE, or RATIO_METRICS. variableType is BOOLEAN, NUMBER, STRING, JSON, JS, CSS, or ENUM. trafficAllocations is a comma-separated variationKey:percentage string that sums to 100 (for example off:50,on:50). releaseDateTime is an ISO-8601 local datetime without offset (for example 2026-07-01T09:00:00) and timeZone is an IANA zone (for example Europe/Paris or UTC).

For environment-specific queries, pass environmentKey = "production" or environmentKey = "staging" where supported.

Prompting tips

Include the site code when you work with feature flags.
Include the experiment ID when you query experiments or experiment results.
Include both experimentId and variationId when you request variation code.
Explicitly name the target environment when you ask the agent to enable or disable a feature flag.
Request a plain-English summary if you want your AI agent to interpret the MCP response rather than just retrieving the raw data.

General troubleshooting

Port 35535 is already in use

If authentication fails with an EADDRINUSE error, another process already listens on the OAuth callback port.

Cause: A stale mcp-remote process remains active from a previous authentication attempt.
Fix: Stop the stale process that is using port 35535, then rerun the OAuth command.

MCP server does not appear in Codex chat

Codex might not hot-reload newly added MCP servers into an already-running thread.

Fix: Refresh Codex or start a new session after you update config.toml.

Browser flow does not complete

If the OAuth browser window opens but authorization does not finish:

Confirm that you clicked the Authorize button on the Kameleoon login page.
Check that your browser or system settings do not block localhost callbacks.
Manually open the callback URL if your browser fails to launch it automatically.

Headless or remote agents fail to authenticate

Remote or headless agents (such as cloud-hosted Codex) cannot complete the browser-based authorization step.

Fix: Use a desktop version of your tool instead.

npx command not found

If the command fails with a “not found” error, ensure that npx is available on your system path. Node.js versions 8.2 and later include npx by default.

​Features

​The primary workflow: Winning experiment to production

​Token usage and plan considerations

​Available tools

​Experiments

​Feature flags

​Flag delivery, variations, and variables

​Goals

​Segments

​Sites and targeting rules

​Claude Code integration

​Step 1: Register the server

​Step 2: Complete OAuth authentication

​Step 3: Start a new Claude Code session

​Step 4: Verify the connection

​Claude troubleshooting

​Antigravity integration

​Quick setup

​Manual configuration

​Codex integration

​Quick setup

​Manual configuration

​Authenticate the connection

​Verify tool operations

​Cursor integration

​Option 1: Configure via Cursor UI (recommended)

​Option 2: Configure via mcp.json (advanced)

​Sample prompts for developer workflows

​Advanced workflow: End-to-end automation

​Tool parameters reference

​Experiments

​Feature flags

​Flag delivery, variations, and variables

​Goals

​Segments

​Sites and targeting rules

​Prompting tips

​General troubleshooting

​Port 35535 is already in use

​MCP server does not appear in Codex chat

​Browser flow does not complete

​Headless or remote agents fail to authenticate

​npx command not found

Features

The primary workflow: Winning experiment to production

Token usage and plan considerations

Available tools

Experiments

Feature flags

Flag delivery, variations, and variables

Goals

Segments

Sites and targeting rules

Claude Code integration

Step 1: Register the server

Step 2: Complete OAuth authentication

Step 3: Start a new Claude Code session

Step 4: Verify the connection

Claude troubleshooting

Antigravity integration

Quick setup

Manual configuration

Codex integration

Quick setup

Manual configuration

Authenticate the connection

Verify tool operations

Cursor integration

Option 1: Configure via Cursor UI (recommended)

Option 2: Configure via mcp.json (advanced)

Sample prompts for developer workflows

Advanced workflow: End-to-end automation

Tool parameters reference

Experiments

Feature flags

Flag delivery, variations, and variables

Goals

Segments

Sites and targeting rules

Prompting tips

General troubleshooting

Port 35535 is already in use

MCP server does not appear in Codex chat

Browser flow does not complete

Headless or remote agents fail to authenticate

npx command not found