Kameleoon MCP server - Kameleoon Documentation

The Kameleoon Model Context Protocol (MCP) server connects AI coding assistants directly to your Kameleoon project. It enables 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, triggers, 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.

Set up the server where you build

Select your AI coding assistant to get a ready-to-paste setup prompt.

Kai, Kameleoon’s in-app AI assistant, includes these same tools natively, with no separate connection step. Use the setup prompts for your AI coding assistant when you want it to act on your Kameleoon project from your IDE instead.

If you want to use these tools from Claude or ChatGPT chat (web or desktop) rather than an IDE, see Connect Kameleoon to Claude and ChatGPT.

Features

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

Discover and inspect experiments, feature flags, goals, segments, triggers, and targeting rules.
Build experiments end to end: create, duplicate, edit their settings and traffic split, add variations with their own code, 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, audience segments, and triggers, and set an experiment’s segment and trigger.
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.

Create variations with their own code

Your AI assistant can set up a test with several variations, each with its own code, without direct API calls. Give the assistant the page URL and the element selectors to change, and ask it to follow these steps:

Create the experiment with experiment_create, for example as a DEVELOPER experiment.
Use the ID of the auto-created Variation 1 from the experiment_create response, and set its code with experiment_variation_update. Don’t add a second variation for it.
Add each further variation with experiment_variation_create, passing its name and any jsCode, cssCode, customJson, or redirection it needs.
To restrict who views the experiment, set its segment or trigger with targeting_rule_update. The experiment already has a targeting rule, so don’t create another one.
Read back each variation’s code with experiment_code_get to confirm the code that Kameleoon stored.

Kameleoon can’t recover a variation’s previous code from the server. Copy the existing code somewhere safe before you update it.

The tools store the code you provide. They don’t generate it, so the result is only as accurate as what your AI assistant knows about the page, which includes the URL and element selectors. An assistant that can read your codebase or the live page can use that context when it writes the code. In a draft experiment, Kameleoon splits traffic evenly across the original page and all variations. With two variations, each of the three versions gets 33% of the traffic. A variation added to a running experiment starts with 0% traffic. Set its share with experiment_traffic_allocation_set while the experiment is paused or scheduled, or in the Kameleoon app while it’s running. Both variation tools check the experiment first. On an experiment that isn’t a draft, such as one that’s running, the tool returns a preview of what will change and applies it only after you confirm. For example, you can use this prompt: “On site d1alzzxd7k, create a developer experiment for https://www.example.com/pricing with two variations. Make the #buy-now button red in the first variation and green in the second.”

Edit experiments, segments, and triggers

Your AI assistant can change an existing experiment’s settings and targeting without the Kameleoon app. For example, a draft experiment needs a goal and a traffic split before it can start. The assistant can attach the goal, set the split, and point the experiment at the segment or trigger that should target it. Each experiment comes with a targeting rule. The assistant changes the segment or trigger of that rule with targeting_rule_update, so you don’t need to create a second rule. Changes that affect live traffic need your confirmation. When an experiment has left draft, or when you change the conditions of a segment or trigger that anything other than a draft experiment uses, the assistant first returns a preview of what will change. It applies the change only after you confirm. The MCP server can’t change the traffic split of a running, deviated, or stopped experiment, or of an experiment used as a personalization. Make that change in the Kameleoon app. For example, you can use this prompt: “On site d1alzzxd7k, for the draft experiment Pricing test: attach goal Purchase, split traffic 50/50 between the original and the variation, and target it to phone visitors on /pricing.” The assistant finds the experiment and the goal, attaches the goal, sets the split, creates a segment for phone visitors and a trigger for /pricing, and binds both to the experiment. The experiment is then ready to start.

The primary workflow: Winning experiment to production

The Kameleoon MCP server automates the “last mile” of implementation. transpose_winning_experiment fetches the winning (or manually selected) variation’s code and applies winner-decision logic in a single call, so your AI assistant doesn’t need to chain separate results and code-retrieval steps together. Without leaving the IDE, you can instruct your AI assistant to execute the following workflow:

Run transpose_winning_experiment to get the winning variation’s code and implementation instructions.
Convert the code into native, production-ready code (such as React components) aligned with the existing codebase.
Create a feature flag in Kameleoon and gate the new implementation behind it.
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 app 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 span, 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).

For experiment_results_get, feature_flag_experiment_results_get, and transpose_winning_experiment, the goalResults array covers every goal attached to the experiment, which includes primary and secondary goals. Kameleoon computes a winner verdict for the primary goal only. Secondary goals return the same statistical figures as guardrail metrics, without a verdict.

Tools that change live traffic show a preview of what will change, and apply the change only after you confirm:

feature_flag_enable, feature_flag_disable, and feature_flag_delete: always.
feature_flag_rule_targeted_create, feature_flag_rule_progressive_create, and feature_flag_rule_experimentation_create: when the flag is already enabled in the target environment.
experiment_update, experiment_variation_create, experiment_variation_update, and targeting_rule_update: when the experiment isn’t a draft.
experiment_traffic_allocation_set: when the experiment is scheduled or paused.
segment_update and trigger_update: when the conditions change and anything other than a draft experiment uses the segment or trigger. Renaming never needs confirmation.
experiment_lifecycle_update: for stopped and deleted.

segment_delete and trigger_delete refuse to delete an item that’s in use unless you set force. You can’t change the traffic split of a running experiment through the MCP server. Change it in the Kameleoon app. If a feature flag rule tool times out or returns a gateway error, the tool may still have created the rule. Check with feature_flag_get before you retry, or the retry adds a duplicate rule.

Experiments

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

Tool	Description	Example prompt
`experiment_list`	Find experiments by name or ID, or list only those with a given status, such as the running ones. Returns paginated summaries (id, name, status, and tags).	”List running 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 for every attached goal: 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). It comes with a first variation and a targeting rule.	”Create a CLASSIC experiment `Homepage hero` on site `d1alzzxd7k`.”
`experiment_variation_create`	Add a variation with its own JavaScript, CSS, custom JSON, or redirect settings to an existing experiment. Draft experiments split traffic evenly. A running experiment gets the new variation at 0%.	”On experiment `149640`, add a variation that makes the `#buy-now` button green.”
`experiment_variation_update`	Change a variation’s code, name, or redirect. Only the fields you pass change, and repeating a call with the same values changes nothing.	”In variation 1 of experiment `149640`, make the `#buy-now` button red.”
`experiment_update`	Change an existing experiment’s settings: name, description, base URL, tags, goals and main goal, shared JavaScript and CSS, global script, data collection, whether shared code also runs on the original page, multiple testing correction, and traffic allocation method. Use it to attach the goal an experiment needs before it can start. Only the fields you pass change. Needs confirmation when the experiment isn’t a draft.	”On experiment `149640`, set goal `271552` as the main goal.”
`experiment_traffic_allocation_set`	Set the traffic split of the original page and every variation. Draft experiments change immediately. Scheduled and paused experiments need confirmation, and the new split takes effect when they start or resume. Use the Kameleoon app to change the split of running, deviated, and stopped experiments.	”On experiment `149640`, split traffic 50/50 between the original and variation 1.”
`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). Starting an experiment requires a goal, variations, and a traffic split. You can also pause and stop deviated and scheduled experiments. You can delete only draft or stopped experiments.	”Start experiment `149640`.”
`transpose_winning_experiment`	Single-entry-point tool that fetches a winning (or manually selected) variation’s code, applies winner-decision logic, and returns instructions for the calling agent to re-implement the variation and gate it behind a new feature flag. One call replaces the older multi-step manual prompt workflow.	”Implement the winning variant of experiment `373001` as a feature flag.”

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 off 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.	”Turn on `new_search` in production.”
`feature_flag_disable`	Turn the per-environment master switch OFF (the rule chain stays intact).	”Turn off `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 these feature flags.”
`feature_flag_experiment_results_get`	Fetch statistical results for every goal attached to a flag’s experimentation rule.	”Get the experiment results for the rule on `new_search`.”

Rules, variations, and variables

Shape how a flag delivers value to users: add delivery and experimentation rules, 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_progressive_create`	Add a progressive delivery rule that raises a variation’s exposure in fixed steps, for a gradual rollout without statistical comparison.	”Roll `new_search` out in production from 5% to 100%, adding 10% every day.”
`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, keeping existing tags.	”Change goal `271552` to a CLICK goal.”
`goal_delete`	Permanently delete a goal.	”Delete goal `271552`.”

Sites

Discover the projects you can access. Most other tools need a site code, so start here.

Tool	Description	Example prompt
`site_list`	List the sites (projects) you can access, with each site’s code, name, and tracking status.	”List the available Kameleoon sites.”

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). A tree has at most two levels.	”Create a segment for desktop visitors in France.”
`segment_update`	Change a segment’s name, description, or conditions. Every campaign that uses the segment targets the new audience right away. Changing the conditions of a segment used by anything other than draft experiments needs confirmation.	”Add Belgium to segment `200604`.”
`segment_delete`	Delete a segment. The tool blocks deletion by default when the segment is in use; override with force.	”Delete segment `200604`.”

Segment conditions take at most two levels: groups of conditions joined by a top-level AND or OR. The tool refuses a deeper condition tree with an explanation instead of flattening it, because flattening can widen the audience. Ask your AI assistant to rewrite the tree in two levels.

Triggers

Define when a campaign fires. A trigger says when (a visitor reaches a page, an event happens, or a visit count passes a set number), and a segment says who. An experiment’s targeting rule combines one of each.

Tool	Description	Example prompt
`trigger_list`	Browse the saved triggers on a site, optionally filtered by name.	”List triggers for site `d1alzzxd7k`.”
`trigger_get`	Inspect a trigger’s conditions and the campaigns that reference it.	”Show trigger `300118`.”
`trigger_create`	Create a saved trigger from conditions that describe a moment, such as a page URL or title, landing page, referrer, traffic origin, page views, visits, day of week, time range, custom data, cookie, or an event. Visitor attributes such as device or location belong in a segment. A new trigger doesn’t affect live traffic until you bind it to an experiment.	”Create a trigger on site `d1alzzxd7k` that fires on `/pricing`.”
`trigger_update`	Change a trigger’s name, description, or conditions. Changing the conditions of a trigger used by anything other than a draft experiment first shows a preview and applies after you confirm.	”Rename trigger `300118` to `Pricing page`.”
`trigger_delete`	Permanently delete a trigger. You can delete a trigger that’s in use only with `force` set to true, and never while a live campaign uses it.	”Delete trigger `300118`.”

Trigger conditions accept page, visit, time, and event types, such as PAGE_URL, VISITS, TIME_RANGE, and EVENT. Visitor attributes, such as DEVICE_TYPE, GEOLOCATION, and BROWSER, belong in a segment, and triggers refuse them. You can’t edit triggers that Kameleoon creates for an experiment’s targeting rule with these tools. Use targeting_rule_update for those.

Targeting rules

Bind a segment (who sees an experiment) and a trigger (when it fires) to an experiment.

Tool	Description	Example prompt
`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_update`	Switch the segment or trigger that targets an experiment, and change its configuration. Only the fields you pass change. The tool rejects invalid configurations without a write.	”Target experiment `149640` to segment `200604`.”
`targeting_rule_create`	Attach a targeting rule to an experiment that has none. Experiments created with `experiment_create` already have one, so use `targeting_rule_update` for those.	None

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 haven’t 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 the Kameleoon feature flags.”
“What experiments are running on site X?”
“Show the status of experiment Y.”
“Show 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`, stop the process, and retry.
Failed to connect after OAuth.	Token didn’t persist.	Re-run the Step 2 command to refresh your token.
Tools aren’t visible in Claude.	Session started before adding the server.	Start a new Claude Code conversation.
A newer tool, such as `experiment_update` or `trigger_list`, is missing from the tool list.	The client keeps the tool list it loaded before Kameleoon released these tools.	Reconnect the server. In Claude.ai, go to Settings > Connectors and reconnect Kameleoon. In Claude Code, run `/mcp` and choose Reconnect.
`mcpServers` key rejected in `settings.json`.	Wrong file; Claude Code doesn’t 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 doesn’t 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 doesn’t 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 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 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

transpose_winning_experiment covers the winner check and code retrieval in one call, but converting that code and rolling it out still benefit from an explicit system prompt. The following example targets React apps and instructs the AI agent to call the tool, then finish the implementation lifecycle: converting the code, gating it behind a new feature flag, and rolling it out, 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. Call transpose_winning_experiment with the experiment ID and mode, and follow its returned instructions.
2. Convert the returned code to React (convert JS code to React components/hooks, and CSS code to the project styling system).
3. 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.
4. 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`, `status` (one or more of `active`, `deviated`, `draft`, `paused`, `scheduled`, `stopped`, `used_as_personalization`; running experiments are `active` and `deviated`), `page`, `perPage`, `sortField`, `sortOrder`
`experiment_get`	`experimentId`	None
`experiment_code_get`	`experimentId`, `variationId`	None
`experiment_results_get`	`experimentId`	`goalIds`, `audienceBasis` (`VISITORS` by default, or `VISITS`), `includeRawReport`
`experiment_create`	`payload` (`siteCode`, `name`, `type`, `baseURL`)	`payload`: `mainGoalId`, `goals`, `tags`, `description`, `commonJavaScriptCode`, `commonCssCode`, `trafficAllocationMethod`, `collectingDataEnabled`, `multipleTestingCorrection`, `executeCodeForReference`
`experiment_variation_create`	`experimentId`, `name`	`jsCode`, `cssCode`, `customJson` (a JSON string), `isJsCodeAfterDomReady`, `shadowDom`, `redirection` (`type` required; `url` for `GLOBAL_REDIRECTION`; `parameters` for `PARAMETER_REDIRECTION`; `includeQueryParameters`, default `false`), `confirm` (required when the experiment isn’t a draft)
`experiment_variation_update`	`variationId`	`experimentId` (the tool refuses the call if it doesn’t match the variation’s experiment), `name`, `jsCode`, `cssCode` (an empty string clears the field), `customJson` (a JSON string), `isJsCodeAfterDomReady`, `shadowDom`, `redirection` (replaces the existing redirect settings; `type` required), `confirm` (required when the experiment isn’t a draft)
`experiment_update`	`experimentId`	`name`, `description` (an empty value keeps the current one), `baseURL` (an absolute `http` or `https` URL), `tags` and `goals` (each replaces the whole list), `mainGoalId`, `commonJavaScriptCode`, `commonCssCode`, `globalScript` (an empty string clears the field), `collectingDataEnabled`, `executeCodeForReference`, `multipleTestingCorrection`, `trafficAllocationMethod` (not while the experiment serves traffic or after it has stopped), `confirm` (required when the experiment isn’t a draft)
`experiment_traffic_allocation_set`	`experimentId`, `originPercentage` (0 to 100), `variationAllocations` (one entry for every variation, each with `variationId` and `percentage`; the total with `originPercentage` can’t exceed 100)	`respool` (default `false`), `confirm` (required for scheduled and paused experiments)
`experiment_duplicate`	`experimentId`	None
`experiment_lifecycle_update`	`experimentId`, `status`	`confirm` (required for `stopped` and `deleted`), `reason`
`transpose_winning_experiment`	`experimentId`	`mode` (`strict_winner_only` default, or `manual_variation_conversion`), `fallbackVariationId` (required when `mode` is `manual_variation_conversion`), `targetFeatureKey` (defaults to `pbx-winning-experiment-<experimentId>`)

experiment_create accepts MVT and SDK_HYBRID as valid type values, but this tool can’t actually create either one. 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.

The variation tools don’t support stopped, MVT, or feature-flag experiments. For feature flag variations, use feature_flag_variation_create. You can’t change the traffic split of a running experiment, or of one that uses a bandit allocation method, through the MCP server.

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`	`confirm` (required to apply the change)
`feature_flag_enable`	`featureKey`, `siteCode`, `environmentKey`	`confirm` (required to apply the change)
`feature_flag_disable`	`featureKey`, `siteCode`, `environmentKey`	`confirm` (required to apply the change)
`feature_flag_activity_logs_get`	None	`type`, `sortKey` (`timestamp`), `sortOrder`, `page`, `perPage`
`feature_flag_experiment_results_get`	`featureKey`, `siteCode`, `environmentKey`, `experimentId`	`goalIds`, `audienceBasis` (`VISITORS` by default, or `VISITS`), `includeRawReport`

Rules, variations, and variables

Tool	Required parameters	Optional parameters
`feature_flag_rule_targeted_create`	`siteCode`, `featureKey`, `environmentKey`, `variationKey`, `exposition`, `releaseDateTime`, `timeZone`	`ruleName`, `confirm` (required when the flag is already enabled in the environment)
`feature_flag_rule_progressive_create`	`siteCode`, `featureKey`, `environmentKey`, `variationKey`, `startExposition`, `stopExposition`, `increaseBy`, `frequencyValue`, `frequencyUnit` (`MINUTES`, `HOURS`, or `DAYS`), `releaseDateTime`, `timeZone`	`ruleName`, `confirm` (required when the flag is already enabled in the environment)
`feature_flag_rule_experimentation_create`	`siteCode`, `featureKey`, `environmentKey`, `controlVariationKey`, `trafficAllocations`, `exposition`, `releaseDateTime`, `timeZone`	`ruleName`, `confirm` (required when the flag is already enabled in the environment)
`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

Sites

Tool	Required parameters	Optional parameters
`site_list`	None	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_update`	`segmentId`	`name`, `description`, `conditionDataTree` (replaces the whole tree), `confirm` (required when the conditions change on a segment used by anything other than a draft experiment)
`segment_delete`	`segmentId`	`force`

Triggers

Tool	Required parameters	Optional parameters
`trigger_list`	None	`siteCode`, `query`, `page`, `perPage`
`trigger_get`	`triggerId`	None
`trigger_create`	`name`, `siteCode`, `conditionDataTree`	`description`, `audienceTracking` (default `false`)
`trigger_update`	`triggerId`	`name`, `description`, `conditionDataTree` (replaces the whole tree), `confirm` (required when the conditions change on a trigger used by anything other than a draft experiment)
`trigger_delete`	`triggerId`	`force` (default `false`)

To bind a saved trigger to an experiment, call targeting_rule_update with triggerConfiguration set to SAVED_TEMPLATE and targetingConfigurationParam set to the trigger ID.

Targeting rules

Tool	Required parameters	Optional parameters
`targeting_rule_list`	None	`siteCode`, `page`, `perPage`
`targeting_rule_get`	`targetingRuleId`	None
`targeting_rule_update`	`experimentId`	`targetingRuleId` (optional; when given, it must be the rule the experiment owns), `segmentId`, `segmentConfiguration` (`ALL_VISITORS` removes the segment), `triggerId`, `triggerConfiguration`, `targetingConfigurationParam`, `confirm` (required when the experiment isn’t a draft)
`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). trafficAllocationMethod is MANUAL (default), MULTI_ARMED_BANDIT, or CONTEXTUAL_BANDIT. frequencyUnit is MINUTES, HOURS, or DAYS. audienceBasis is VISITORS (default) or VISITS. segmentConfiguration is ALL_VISITORS, AUTOPROMO_AUTODEFINED, GRAPHICAL_PAGES, HEAT_SLICE, PAGE, SAVED_TEMPLATE, SITE, or URL, and triggerConfiguration takes the same values except ALL_VISITORS. The targetingConfigurationParam input is a saved trigger ID for SAVED_TEMPLATE, a segment ID for HEAT_SLICE, a full URL for PAGE, or a URL fragment for URL.

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 turn a feature flag on or off.
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’s using port 35535, then rerun the OAuth command.

MCP server doesn’t 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 doesn’t complete

If the OAuth browser window opens but authorization doesn’t finish:

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

A tool returns BLOCKED instead of making the change

Tools that change live traffic return a preview with the status BLOCKED until you confirm, which doesn’t mean an error.

Fix: Read the preview, and if the change is what you want, ask your AI assistant to repeat the call with confirm set to true. For segment_delete and trigger_delete, use force instead.

Headless or remote agents fail to authenticate

Remote or headless agents (such as cloud-hosted Codex) can’t 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.

Tutorials

​Set up the server where you build

​Features

​Create variations with their own code

​Edit experiments, segments, and triggers

​The primary workflow: Winning experiment to production

​Token usage and plan considerations

​Available tools

​Experiments

​Feature flags

​Rules, variations, and variables

​Goals

​Sites

​Segments

​Triggers

​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

​Rules, variations, and variables

​Goals

​Sites

​Segments

​Triggers

​Targeting rules

​Prompting tips

​General troubleshooting

​Port 35535 is already in use

​MCP server doesn’t appear in Codex chat

​Browser flow doesn’t complete

​A tool returns BLOCKED instead of making the change

​Headless or remote agents fail to authenticate

​npx command not found

Set up the server where you build

Features

Create variations with their own code

Edit experiments, segments, and triggers

The primary workflow: Winning experiment to production

Token usage and plan considerations

Available tools

Experiments

Feature flags

Rules, variations, and variables

Goals

Sites

Segments

Triggers

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

Rules, variations, and variables

Goals

Sites

Segments

Triggers

Targeting rules

Prompting tips

General troubleshooting

Port 35535 is already in use

MCP server doesn’t appear in Codex chat

Browser flow doesn’t complete

A tool returns BLOCKED instead of making the change

Headless or remote agents fail to authenticate

`npx` command not found