---
title: Overview
description: "The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code. With this setup, you can ask questions, explore experiments, and access your Statsig data using AI."
product: general
token_estimate: 2690
---
# Overview

> For AI agents: a documentation index is available at [/llms.txt](/llms.txt). Append `.md` to any page URL for markdown, or send `Accept: text/markdown`.

## MCP configuration guides

### [Codex](https://docs.statsig.com/integrations/mcp/codex)

Set up Statsig MCP using Codex Desktop App, CLI, or IDE extension.

### [ChatGPT Connector](https://docs.statsig.com/integrations/mcp/chatgpt-connector)

Talk to your Statsig projects from within ChatGPT.

### [Cursor](https://docs.statsig.com/integrations/mcp/cursor)

Configure Statsig MCP in Cursor IDE.

### [Claude Code](https://docs.statsig.com/integrations/mcp/claude-code)

Set up Statsig MCP in Claude Code.

### [Manual setup](https://docs.statsig.com/integrations/mcp/manual-setup)

Manual configuration for any MCP-compatible tool.

## Current MCP capabilities

#### Audit Logs

| Tool | Description |
| --- | --- |
| Get\_Audit\_Logs | List audit logs in the project. Filter by:- `id` - `sortKey` - `sortOrder` - `tags` - `startDate` - `endDate` |

#### Dynamic Configs

| Tool | Description |
| --- | --- |
| Create\_Dynamic\_Config | Create new config |
| Get\_Dynamic\_Config\_Details\_by\_ID | Retrieve detailed config information |
| Get\_List\_of\_Dynamic\_Configs | List all dynamic config objects in the project. Filter by:- `creatorName` - `tags` |
| Update\_Dynamic\_Config\_Entirely | Replace entire dynamic config with new targeting and values |
| Get\_Dynamic\_Config\_Version\_History | Retrieve the version history for a dynamic config |

#### Experiments (A/B Tests)

| Tool | Description |
| --- | --- |
| Create\_Experiment | Create a new experiment. Accepts these optional fields:- `secondaryIDType`: a secondary unit type for the experiment. - `identifierMappingMode`: how Statsig maps identifiers across ID types. - `enabledNonProdEnvironments`: the non-production environments where the experiment runs. - `links`: reference links to attach to the experiment. - `secondaryMetrics`: secondary metrics to track alongside the primary metrics. Set them when you create the experiment, without a separate update call. |
| Get\_Experiment\_Details\_by\_ID | Get experiment details. Optionally trim the response to only the fields you need:- `fields`: comma-separated list of field names to return (for example, `hypothesis,primaryMetrics`); omit to return all fields. Reduces context consumption by up to 95–99%. |
| Get\_Experiment\_Overall\_Results | Retrieve experiment results/pulse data for a specific experiment. Analyze by:- `date` - `cuped` - `confidence` |
| Get\_Experiment\_Metric\_Dimension\_Results | Retrieve metric results for one experiment metric with dimensional breakdowns. Analyze by:- `date` - `cuped` - `confidence` |
| Get\_List\_of\_Experiments | List all experiments in the project. Filter by:- `status` - `creatorName` - `tags` - `stale` |
| Update\_Experiment\_Entirely | Replace the entire experiment configuration (Statsig removes any excluded data). Accepts the same optional fields as `Create_Experiment`, which keep their current value when you omit them:- `secondaryIDType`: a secondary unit type for the experiment. Pass `null` or an empty string (`""`) to clear it. - `identifierMappingMode`: how Statsig maps identifiers across ID types. - `enabledNonProdEnvironments`: the non-production environments where the experiment runs. - `links`: reference links to attach to the experiment. - `secondaryMetrics`: secondary metrics to track alongside the primary metrics. |
| GetExperimentSummaryCharts | Retrieve summary charts for a specific experiment |
| Get\_Experiment\_Version\_History | Retrieve the version history for an experiment |
| Start\_Experiment\_Code\_Cleanup | Start the code cleanup process for an experiment after it has concluded |

#### Autotunes

**Create\_Autotune**: Create a new Autotune (multi-armed bandit) experiment. Describe the arms, success event, exploration/attribution windows, and winner threshold; the agent builds and creates the Autotune. Creates in draft by default; start the Autotune from the console to allocate traffic. Prompts for confirmation before creating.

#### Gates (Feature Flags)

| Tool | Description |
| --- | --- |
| Create\_Gate | Create new gate/flag |
| Get\_Gate\_Details\_by\_ID | Get complete gate configuration details |
| Get\_Gate\_Results | Retrieve pulse/results for a specific gate rule.- `cuped` - `confidence` |
| Get\_List\_of\_Gates | List all gates/flags. Filter by:- `type` - `creatorName` - `tags` |
| Update\_Gate\_Entirely | Replace entire gate setup with new rules and settings (Statsig removes any excluded data) |
| Get\_Gate\_Version\_History | Retrieve the version history for a gate |
| Start\_Gate\_Code\_Cleanup | Start the code cleanup process for a gate after it has concluded |

#### Layers

| Tool | Description |
| --- | --- |
| Create\_Layer | Create a new layer |
| Get\_Layer\_Details\_by\_ID | Retrieve layer details, including parameters and metadata |
| Get\_List\_of\_Layers | List all layers in the project |
| Update\_Layer\_Entirely | Replace the full layer configuration |

#### Metrics and Metric Sources

| Tool | Description |
| --- | --- |
| Get\_List\_of\_Metric\_Sources | List all metric sources in the project |
| Get\_List\_of\_Metrics | List all metrics in the project. Filter by:- `showHiddenMetrics` - `tags` - `filters` |
| Get\_Metric\_Definition\_by\_ID | Get the full definition for a metric, including its type, source, and configuration details |

#### Parameter Stores

| Tool | Description |
| --- | --- |
| Get\_List\_of\_Param\_Stores | List all Parameter Stores in the project |
| Get\_Param\_Store\_Details\_by\_Id | Retrieve details for a specific Parameter Store by ID |
| Create\_Param\_Store | Create a new Parameter Store and its parameters |
| Update\_Param\_Store | Update an existing Parameter Store, including adding or changing parameters |
| Delete\_Param\_Store | Delete a Parameter Store |

#### Segments

| Tool | Description |
| --- | --- |
| Create\_Segment | Create a new segment. Supports `id_list`, `rule_based`, `analysis_list`, and `user_store_id_list` segment types |
| Get\_List\_of\_Segments | List all segments in the project |
| Get\_Segment\_by\_ID | Retrieve segment details |
| Update\_Segment | Update an existing segment. Specifically:- Update rules for conditional segment types - Add IDs to user stores and ID lists |

#### Reviews

| Tool | Description |
| --- | --- |
| Create\_Gate\_Review | Create a review request for a gate change |
| Edit\_Gate\_Review | Edit an existing gate review request |
| Approve\_Gate\_Review | Approve a gate review request |
| Reject\_Gate\_Review | Reject a gate review request |
| Commit\_Gate\_Review | Commit an approved gate review, applying the change |
| Cancel\_Gate\_Review | Cancel a gate review request |
| Get\_Gate\_Review\_by\_ID | Retrieve a specific gate review by ID |
| Get\_List\_of\_Gate\_Reviews | List all reviews for a gate |
| Get\_Gate\_Eligible\_Reviewers | List users eligible to review a gate change |
| Create\_Experiment\_Review | Create a review request for an experiment change |
| Edit\_Experiment\_Review | Edit an existing experiment review request |
| Approve\_Experiment\_Review | Approve an experiment review request |
| Reject\_Experiment\_Review | Reject an experiment review request |
| Commit\_Experiment\_Review | Commit an approved experiment review, applying the change |
| Cancel\_Experiment\_Review | Cancel an experiment review request |
| Get\_Experiment\_Review\_by\_ID | Retrieve a specific experiment review by ID |
| Get\_List\_of\_Experiment\_Reviews | List all reviews for an experiment |
| Get\_Experiment\_Eligible\_Reviewers | List users eligible to review an experiment change |
| Create\_Autotune\_Review | Create a review request for an Autotune change |
| Edit\_Autotune\_Review | Edit an existing Autotune review request |
| Approve\_Autotune\_Review | Approve an Autotune review request |
| Reject\_Autotune\_Review | Reject an Autotune review request |
| Commit\_Autotune\_Review | Commit an approved Autotune review, applying the change |
| Cancel\_Autotune\_Review | Cancel an Autotune review request |
| Get\_Autotune\_Review\_by\_ID | Retrieve a specific Autotune review by ID |
| Get\_List\_of\_Autotune\_Reviews | List all reviews for an Autotune |
| Get\_Autotune\_Eligible\_Reviewers | List users eligible to review an Autotune change |

#### Logs and Observability

| Tool | Description |
| --- | --- |
| Query\_Logs\_Explorer | Query the Logs Explorer for raw event data |
| Cluster\_Log\_Patterns | Cluster and summarize log patterns to surface recurring events and anomalies |

Need other functions? Statsig considers additions by request. Reach out in Slack.

## Use cases

The Statsig MCP server supports both `GET` and `POST` requests. Read-only users can connect and use all read tools. Write tools require an API key with write permissions. The Statsig MCP server is especially useful for:

- Repetitive tasks like cleaning up stale gates
- Summarizing console information in your IDE workflows
- Bulk creating or deleting gates, and making the necessary changes in your code

### Example prompt for stale gate cleanup

```plaintext
You are an expert, diligent Software engineer with the sole goal of reducing the amount of tech debt in the code base. This code base, making use of best practices, leverages feature gates liberally using Statsig. As gates complete their lifecycle in Statsig, they may end up "stale" which means that they're enabled, but no longer checked. Your job is to find these gates, and refactor the codebase to no longer check the gate (instead, changing the check to a constant value).

You should follow coding best practices:
- You should not simply replace gate calls with "True" or "False" but instead carefully trace the logic through to where it is used and change the behavior that way - adjusting the code in minor ways to make the default behavior what the value is that the gate was returning
- You should always strive to write minimal code - readable but terse, never longer than it needs to be
- You should never write comments or debug statements.

You should use the statsig-local MCP to list feature gates, then look for gates that are marked as stale. You should then grep the codebase for that feature flag name, and do a minimal rewrite of the code to no longer use Statsig, removing the checkGate call or similar. When you use the MCP use the get /console/v1/gates endpoint and parameters type="STALE" and limit =10. You should select only one gate to do this with, before stopping. If you cannot find the gate after a grep, try the next one you found using the MCP. Once you successfully remove a gate, return.
```