Statsig MCP server: 18 V3 tools, with discovery for the rest
A feature-flag connector rebuilt around grouped tools and a discovery layer, its legacy V1 server, and the documentation server people confuse with both.
Checked 6 October 2026 · from Statsig's own MCP documentation, including the V3 tool reference and the V3 migration guide
One of 91 guides to monitoring and developer tools. Each covers what an AI coding agent can get out of the tool through MCP, the protocol that lets the agent query the tool directly.
Summary
Statsig runs a hosted MCP server at api.statsig.com/v3/mcp. Its V3 tool reference lists 18 default tools, and clients with expanded tool exposure see 9 more.
V3 groups operations into fewer tools. gate_read and experiment_read take an action, and discover_tools finds every other operation. api_read, api_write and api_destructive then run it.
The V1 server at api.statsig.com/v1/mcp still serves existing connections. Statsig recommends V3 for new setups, and its migration guide maps 93 V1 tools to V3.
There is also a different Statsig server. A read-only Docs MCP serves public documentation. It is separate from the authenticated product endpoint.
What is the Statsig MCP server?
It is Statsig's server for the Model Context Protocol. Statsig is an experimentation and feature-flag platform, so a connected agent reaches gates, experiments and the metrics behind them.
V3 groups the surface by resource. Five read tools cover gates, experiments, dynamic configs, metrics and logs. Three create tools and three update tools cover gates, experiments and dynamic configs.
Other objects go through discovery. Layers, segments, Parameter Stores, Autotunes, holdouts, prompts, tags, dashboards and reviews are discovered operations. A layer groups experiments so that no user is in more than one of them.
Statsig sits in CI and release, reaches production observability through its logs explorer, and reaches nothing in agent observability or cost.
| Part of the work | What Statsig has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | Code cleanup for stale gates and experiments | Partial. Code cleanup for a gate or experiment is a discovered operation; there is no diff or review feature for code |
| CI & release | Gates, experiments, dynamic configs, layers, reviews | Yes. Core strength. Reviews and less common objects run through discovery |
| Production observability | Logs explorer, log pattern clustering | Partial. log_read queries Logs Explorer, and log clustering is a discovered operation; there are no metrics or traces |
| Agent observability & evals | None | No traces or evaluations for your own agents |
| AI cost management | None | No spend data of any kind |
For an agent, Statsig answers what is gated, what is being tested and who approved it. Discovered operations can also propose, approve and commit a gate change on the same connection. It has no application metrics or traces, so it pairs with a telemetry connector.
What can an AI agent do with Statsig?
| Task | Tools | Works | Watch out for |
|---|---|---|---|
| See which gates exist | gate_read | Yes | Use the get_list_of_gates action, then get_gate_details_by_id for each gate |
| Read an experiment's results | experiment_read | Yes | Overall and per-dimension results are separate actions |
| Create and approve a change | discover_tools api_write api_destructive | Yes | Creating a review uses api_write. Approving and committing use api_destructive with a confirmation |
| Find who may approve | discover_tools api_read | Yes | Eligible reviewers are a separate discovered operation for each object type |
| Track configuration history | gate_read experiment_read log_read | Yes | Version history is an action on each read tool. Audit logs sit in log_read |
| Clean up stale flags | discover_tools api_destructive | Yes | Code cleanup starts a process and needs a confirmation |
| Query logs | log_read | Yes | query_logs_explorer returns raw events. Pattern clustering is a discovered operation |
Start with get_context, which returns the project, permissions and review settings. For an operation without a direct tool, call discover_tools with resolve, then run the returned operationHandle. Handles expire, so fetch a fresh one each time.
18 default tools in V3, plus 9 with expanded tool exposure
- Context and search3
get_contextsearchfetch- Read5
gate_readexperiment_readdynamic_config_readmetric_readlog_read- Create3Write
gate_createexperiment_createdynamic_config_create- Update3Write
gate_updateexperiment_updatedynamic_config_update- Discovery4Write
discover_toolsapi_readapi_writeapi_destructive
Groups follow Statsig's V3 tool reference, read 6 October 2026. Expanded exposure adds typed tools for layers, segments, Parameter Stores and Autotunes. The hosted endpoint answers tools/list only with an active Console key.
What the tool definitions cost in context
A client that loads every tool definition at the start of a session spends this much context before the first question. Claude Code defers definitions by default through tool search, and loads a tool's definition when the agent needs it. The method below gives the version and date measured.
A context window is the amount of text a model can hold at once. The figures below measure the V1 server's 67 documented tools, read on 24 August 2026. On Claude they came to 3,669 to 4,619 tokens.
V3 sends 18 default tools in place of 67. A V3 figure needs a live tools/list, and the endpoint requires a Console key for that.
| Tool set | Tools | Tokens (GPT-5.6, GPT-5.5) | Tokens (GPT-4, GPT-3.5) | Tokens (Claude Haiku 4.5 to Opus 5) | Share of a 200,000-token window |
|---|---|---|---|---|---|
| V1, every tool documented on 24 August 2026 | 67 | 1,347 to 2,005 | 1,342 to 2,000 | 3,669 to 4,619 | 0.7% to 2.3% |
Encodings: GPT-5.6, GPT-5.5 o200k_base; GPT-4, GPT-3.5 cl100k_base; Claude Haiku 4.5 to Opus 5 count_tokens. Counted from the 67 V1 tool entries in the vendor's own documentation, read 24 August 2026. That was the only public inventory.
The server could not be run for a live tools/list. So no input schemas are available. These figures cover each tool's name and description only. They are a floor, not the figure.
The Claude columns are measured through the API's count_tokens endpoint, with an empty schema per tool. So they cover the same content as the GPT columns. The range there is two tokenizer generations. Haiku 4.5 and Opus 4.6 sit at the low end. Opus 5 and Sonnet 5 sit at the high end. The gap between them is about a quarter.
Statsig MCP server limits: where answers come back incomplete
Two facts set the limits below. The same connection can propose a change and approve it. A separate Statsig server shares the brand and reaches none of your data.
The agent says: “The change is approved and live.” The same agent may have done both.
Review actions for gates, experiments, dynamic configs and autotunes are discovered operations. Creating a review runs on api_write. Edit, approve, reject, commit and cancel run on api_destructive.
The connector keeps proposer and approver on the same key. The key's permissions and the project's review policy are the controls.
Guard: Decide deliberately whether the agent's key may approve, and require it to name every review operation it ran.
The agent says: “I updated the gate.” It may have replaced it.
gate_update, experiment_update and dynamic_config_update replace the whole resource. Statsig's reference says to read the current state first and keep every field you mean to preserve.
Guard: Have the agent read the object and send it back whole, and check the audit log afterwards.
The agent says: “Get_List_of_Gates is not available.” V3 renamed it.
V3 replaces V1's individual tools with 18 default tools and discovery. Get_List_of_Gates became gate_read with the get_list_of_gates action.
Guard: Move prompts and scripts to the V3 names, using Statsig's migration guide.
Statsig publishes two MCP servers and only one reaches your data.
The Docs MCP is described as targeted, read-only public documentation retrieval. The authenticated product endpoint accesses resources according to the account's permissions. They answer different questions.
Guard: Have the agent name which endpoint it used before you trust an answer about your own project.
How to configure Statsig MCP for agents
- 1
Pick V3 for a new connection
Statsig recommends api.statsig.com/v3/mcp. V1 stays supported for existing connections, and connecting both duplicates tools.
- 2
Decide whether an agent may approve
Approve, reject and commit actions for reviews run through
api_destructive, which needs aconfirmation. - 3
Know which server you are configuring
The Docs MCP is read-only over public documentation; the product endpoint needs OAuth or a Console key and reaches your data.
- 4
Understand the update semantics
Most V3 update tools replace the whole resource. Partial edits, such as adding a tag, are discovered operations.
- 5
Scope the Console key
Statsig states that the authenticated server accesses product resources according to the account's permissions.
Paste this into your agent’s instructions
The same connector can propose a change and approve it, and most updates replace rather than patch. The response must disclose each behavior.
When you answer using Statsig MCP tools, state: - The project and object the answer covers. - Whether you used the Docs MCP or the authenticated product endpoint. They return different things. - Each discovered operation you ran, and whether it used api_write or api_destructive. - Whether you created, approved, committed or canceled a review, or replaced an object with an update tool. If no objects match, say that none matched the filters above. Do not claim that the data does not exist. Write your answer in ASD-STE100 Simplified Technical English. Use short sentences with one idea in each.
Do you need the MCP server at all?
Not for pulling results on a schedule. Statsig's Console API covers the same objects and is the direct route there.
The connector earns its place on the review workflow. Creating a gate review and finding its eligible reviewers from the editor is not something a fixed report does.
For flags without the experimentation surface, LaunchDarkly's connector is narrower and its tools are all described.
Connect it when an agent participates in flag and experiment decisions. Use the Console API for reporting.
Statsig MCP server setup
The server is hosted at api.statsig.com/v3/mcp, so nothing is installed. Statsig recommends OAuth, which uses a Personal Console API key. A Console API key header also works.
Statsig publishes configuration guides for Codex, Cursor, Claude Code, a ChatGPT connector and a manual setup route.
Claude Code
OAuth is Statsig's recommended route: run /mcp in Claude Code to sign in. For a Console API key instead, add --header "statsig-api-key: <your-console-key>".
claude mcp add --transport http statsig \ https://api.statsig.com/v3/mcp
Cursor
In ~/.cursor/mcp.json. The Console key comes from your Statsig project settings, or drop the header to sign in with OAuth.
{"mcpServers":{"statsig":{
"url":"https://api.statsig.com/v3/mcp",
"headers":{"STATSIG-API-KEY":"<your-console-key>"}}}}Codex CLI
Codex reads TOML, so the JSON blocks above will not transfer. The Console key still applies.
[mcp_servers.statsig]
url = "https://api.statsig.com/v3/mcp"
headers = { "STATSIG-API-KEY" = "<your-console-key>" }Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Claude Desktop
macOS ~/Library/Application Support/Claude/claude_desktop_config.json. Windows %APPDATA%\Claude\claude_desktop_config.json. There is no CLI. Edit through Settings, Developer, Edit Config.
Quit and restart fully for changes to load. Paths in args must be absolute. Logs at ~/Library/Logs/Claude/mcp.log.
{"mcpServers":{"statsig":{"url":"https://api.statsig.com/v3/mcp",
"headers":{"STATSIG-API-KEY":"<your-console-key>"}}}}Gemini CLI
~/.gemini/settings.json globally, or .gemini/settings.json per project. Key mcpServers. CLI: gemini mcp add.
{"mcpServers":{"statsig":{"url":"https://api.statsig.com/v3/mcp",
"headers":{"STATSIG-API-KEY":"<your-console-key>"}}}}VS Code Copilot
.vscode/mcp.json per workspace, or your user profile. The portable .mcp.json at the project root and ~/.copilot/mcp-config.json also work. CLI: code --add-mcp.
{"servers":{"statsig":{"url":"https://api.statsig.com/v3/mcp",
"headers":{"STATSIG-API-KEY":"<your-console-key>"}}}}The key depends on the file. .vscode/mcp.json and the user profile take servers, as in the example. The portable .mcp.json and ~/.copilot/mcp-config.json take mcpServers, which VS Code prefers for new servers.
Windsurf
~/.codeium/windsurf/mcp_config.json, which is the path Windsurf documents. Key mcpServers, the same JSON shape as Cursor, carrying the same credential.
{"mcpServers":{"statsig":{"url":"https://api.statsig.com/v3/mcp",
"headers":{"STATSIG-API-KEY":"<your-console-key>"}}}}Zed
~/.config/zed/settings.json, carrying the same credential as the blocks above.
The key is `context_servers`. Zed does not call them MCP servers in config, so searching its settings for mcp finds nothing.
Google Antigravity
~/.gemini/config/mcp_config.json globally, or .agents/mcp_config.json per project. Key mcpServers. There is no CLI. Use the /mcp overlay in the editor. Supports stdio, streamable HTTP, SSE and websocket.
{"mcpServers":{"statsig":{"url":"https://api.statsig.com/v3/mcp",
"headers":{"STATSIG-API-KEY":"<your-console-key>"}}}}Amp (Sourcegraph)
~/.config/amp/settings.json or .amp/settings.json, carrying the same credential. The amp mcp CLI covers approve, doctor and oauth.
The key is `amp.mcpServers`, namespaced. A bare mcpServers block is ignored.
Cline
~/.cline/mcp.json per the docs. The source also reads ~/.cline/data/settings/cline_mcp_settings.json. Key mcpServers, standard JSON shape, carrying the same credential. Supports stdio, streamable HTTP and SSE.
Goose (Block)
~/.config/goose/config.yaml, carrying the same credential.
YAML, and servers are called `extensions`. Goose does not use the MCP vocabulary in config at all. Add one interactively with goose configure, or per session with goose session --with-extension.
Kiro (AWS)
.kiro/settings/mcp.json per workspace, or ~/.kiro/settings/mcp.json globally. Key mcpServers, standard JSON shape, carrying the same credential.
Warp
~/.warp/.mcp.json or .warp/.mcp.json. Key mcpServers, standard shape, carrying the same credential. Also addable through the /agent-add-mcp skill.
JetBrains Junie
.junie/mcp/mcp.json per project, or ~/.junie/mcp/mcp.json. Key mcpServers, carrying the same credential. Use /mcp in the CLI to manage.
Roo Code
.roo/mcp.json per project. The global file is mcp_settings.json, opened from the Roo Code MCP settings view with Edit Global MCP. Key mcpServers, carrying the same credential.
Continue
.continue/mcpServers/*.yaml, one file per server, carrying the same credential.
YAML, and `mcpServers` is a list, not an object. Every JSON client keys servers by name. Continue takes an array, so a converted config will not parse.
Trae
.trae/mcp.json per project, or paste into the UI under Raw Config (JSON). Key mcpServers, standard shape, carrying the same credential.
Devin
Devin has no config file to edit. Servers are added through a web form in the settings UI, and Devin's documentation states you do not need to write or paste JSON. The block below is the shape those fields describe, shown for reference. Either route uses the same credential.
Legacy V1 server
Existing V1 connections still work at api.statsig.com/v1/mcp. Statsig's migration guide maps each V1 tool to its V3 replacement. Disable one version while you test the other.
{"mcpServers":{"statsig-v1":{"url":"https://api.statsig.com/v1/mcp",
"headers":{"STATSIG-API-KEY":"<your-console-key>"}}}}The documentation server
A different server. It is read-only over public documentation and needs no credentials, so it reaches none of your data.
# Statsig's Docs MCP, for public documentation only. # Configure it separately from the product endpoint above.
Read-only access, permissions and security
Reviews run through discovery
Approve, reject, commit and cancel actions for gates, experiments, dynamic configs and autotunes are discovered operations on
api_destructive.Approval and commit are reachable from the same connection
One key can propose a change and approve it. Project review policies still apply, and approving a review leaves it uncommitted.
The agent supplies the confirmation
Update tools and
api_destructiverequire aconfirmationobject. Review each change before the agent sends it.Most updates replace rather than patch
V3 update tools replace the whole resource, so fields left out are lost.
Deletes are discovered operations
Deleting an experiment or a Parameter Store runs through
api_destructive.Permissions follow the key
Statsig documents that the authenticated server accesses resources according to the account's permissions.
Troubleshooting
- The endpoint returns 401
- It accepts an active Console key only, and says so in the error. Other Statsig key types are rejected.
- An update wiped fields you did not touch
- Most V3 update tools replace the resource. Read the object first and send it back complete, or discover a partial-update operation.
- The agent answered from documentation, not your data
- It may have used the Docs MCP, which is a separate read-only server over public documentation.
- A review will not commit
- Approving a review leaves it uncommitted, and commit is its own discovered operation. Check eligibility with the eligible-reviewers operation for that object type.
- A V1 tool name stops working
- V3 uses different names. Statsig's migration guide maps each V1 tool, such as
Get_List_of_Gates, to its V3 replacement. - Every tool appears twice
- V1 and V3 are both connected. Statsig advises disabling the version you are not testing.
Statsig MCP server: Reference
| Item | Value |
|---|---|
| Endpoint | api.statsig.com/v3/mcp, streamable HTTP |
| Legacy endpoint | api.statsig.com/v1/mcp, supported for existing connections |
| Auth | OAuth with a Personal Console API key, or a Console API key header; other key types are rejected |
| Tools | 18 default in V3, plus 9 with expanded tool exposure |
| Discovery | discover_tools, then api_read, api_write or api_destructive |
| V1 tools | 67 in the V1 reference tables; the migration guide maps 93 |
| Second server | A read-only Docs MCP over public documentation |
| Client guides | Codex, ChatGPT connector, Cursor, Claude Code, manual |
| Registry | com.statsig/statsig-mcp-server 1.0.0, listing the V1 URL on 6 October 2026 |
| Inventory source | Statsig's V3 tool reference and migration guide, read 6 October 2026 |
What engineers report
Statsig documents its tools in a V3 reference, a V1 reference and a migration guide, so the counts below are its own.
| What was checked | What it shows |
|---|---|
| Default V3 tools | 18 |
| Added by expanded tool exposure | 9 |
| Discovery execution tools | 3: api_read, api_write, api_destructive |
| V1 tools in the migration guide | 93 |
| V1 tools in the V1 reference tables | 67 |
| Published client guides | 5 |
Tool inventory read from Statsig's V3 tool reference, V1 tool reference and migration guide on 6 October 2026. Unauthenticated tools/list calls to the V1 and V3 endpoints both returned 401 that day, with a message stating that the endpoint accepts an active Console key only.
Should you connect an agent to Statsig?
Yes. Best for v3 over OAuth, with a key scoped to what the agent should decide and every api_destructive call reviewed.
- Strongest fit
- Statsig teams who want an agent inside the gate and experiment review process, not just reading it.
- Main advantage
- A short default tool list, with a discovery layer that still reaches reviews, layers, segments and logs.
- Main weakness
- Less common work takes two calls through discovery, and two server versions plus a docs server share the brand.
- Operational risk
- Approve and commit sit behind the same key as create, and most updates replace whole objects.
From Oodle
One platform for agent traces and infrastructure
Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface.
See agent observabilityFrequently asked questions
How many tools does the Statsig MCP server have?
18 default tools in V3, plus 9 for clients with expanded tool exposure. Discovery reaches the remaining operations. Read from Statsig's V3 tool reference on 6 October 2026, because the hosted endpoint needs an active Console key.
What happened to the V1 review tools?
V1 had a separate tool for each review action and object type. In V3 they are discovered operations. Creating a review runs on api_write, and approve, commit and the rest run on api_destructive.
Is the V1 server still available?
Yes. Existing V1 connections at api.statsig.com/v1/mcp remain supported. Statsig recommends V3 for new setups.
What key does it take?
OAuth with a Personal Console API key, or a Statsig Console API key in a header. The endpoint rejects other key types with a message saying it accepts an active Console key only.
What is the Docs MCP?
A separate read-only server over Statsig's public documentation. It does not reach your project data.
Do updates patch or replace?
Most V3 update tools replace the resource. Read it first and send it back complete, or discover a partial-update operation.