---
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
lang: en
token_estimate: 1330
---
# 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.

## Reference and automation

### [Tool reference](https://docs.statsig.com/integrations/mcp/tool-reference)

Look up MCP tools, actions, and inputs.

### [Automation examples](https://docs.statsig.com/integrations/mcp/automation-examples)

Call the V3 server from scheduled and CI jobs.

## Current MCP capabilities

Statsig MCP exposes 18 default tools. Tool visibility depends on your permissions and the server configuration.

| Tool group | What it does |
| --- | --- |
| Context and search | `get_context` returns your project, permissions, and review settings. `search` and `fetch` find and retrieve Statsig resources. |
| Read tools | `gate_read`, `experiment_read`, `dynamic_config_read`, `metric_read`, and `log_read` list and inspect gates, experiments, dynamic configs, metrics, metric sources, audit logs, and Logs Explorer data. Each takes an `action`. |
| Create tools | `gate_create`, `experiment_create`, and `dynamic_config_create` create new resources. These tools require write access. |
| Update tools | `gate_update`, `experiment_update`, and `dynamic_config_update` replace an existing resource. These tools require write access and a `confirmation`. |
| Discovery tools | `discover_tools` finds other operations, including layers, segments, Parameter Stores, Autotunes, holdouts, prompts, tags, dashboards, reviews, and partial updates. `api_read`, `api_write`, and `api_destructive` run the operation you discover. |

Clients that use expanded tool exposure also show typed tools for layers, segments, Parameter Stores, and Autotunes.

Your agent can find and run any operation that Statsig exposes through discovery, without a dedicated tool. For the inputs each tool accepts, go to the [tool reference](https://docs.statsig.com/integrations/mcp/tool-reference).

#### Safety and confirmation

- Update tools and `api_destructive` operations require a `confirmation`. Review each change before your agent supplies a `confirmation`.
- `api_destructive` covers sensitive updates and review actions, not only deletion.
- Project permissions and review policies still apply. Approving a review doesn't commit its changes.

#### Legacy V1 resources

Existing V1 connections remain supported. To update an existing connection, go to [Migrate to Statsig MCP V3](https://docs.statsig.com/integrations/mcp/migrate-to-v3).

For the legacy tools, go to the [V1 tool reference](https://docs.statsig.com/integrations/mcp/v1-tool-reference).

## 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

```text
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, list gates with type="STALE" and limit=10. Call gate_read with the get_list_of_gates action and the parameters query_type and query_limit. 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.
```