Statsig MCP Server: Setup, Tools & Real Limits
Statsig MCP is a useful official bridge from AI clients to Statsig project data, but write access deserves the same controls as a production deployment tool.
Statsig MCP is Statsig's official hosted bridge between an MCP-capable AI client and your project's experiments, gates, metrics, and configurations. It is worth using for focused inspection and carefully reviewed changes—not autonomous production administration. Connect by OAuth, begin read-only, and treat every mutation as a release operation.
Table of contents
Use these links to jump to the practical answer you need.
- What Statsig MCP actually is
- What exists today
- Setup
- Tools you get
- Permissions and blast radius
- Real limits
- When not to use it
What Statsig MCP actually is
Statsig MCP turns Statsig's management APIs into model-callable tools. Once connected, an agent can inspect active or stale feature gates, retrieve experiment configuration, summarize results and audit history, and—if its identity may write—create or update Statsig objects.
This is a control-plane integration, not an SDK replacement. Your application still evaluates gates and logs exposures through Statsig's SDKs; the MCP connection lets an AI client operate on project metadata and configuration. Statsig's current capability list covers audit logs, dynamic configs, experiments, Autotunes, gates, layers, metrics and metric sources, parameter stores, segments, reviews, plus logs and observability.
Ask for ten stale gates, inspect one gate's rules, find its references in a repository, then propose a cleanup. The server supplies Statsig state; the coding client supplies repository access and reasoning. Browse other integration patterns in the MCP Directory capabilities catalog before assuming one connector owns the whole workflow.
What exists today
There are two first-party Statsig servers today, and they solve different problems. The authenticated project server is the relevant choice for operations; the public docs server is only for retrieving Statsig documentation.
| Official endpoint | Data exposed | Authentication | Writes | Best use |
|---|---|---|---|---|
https://api.statsig.com/v1/mcp | Your Statsig project | OAuth or supported Console API key flow | Permission-dependent | Gates, experiments, metrics, configs, and administration |
Statsig Docs MCP /api/mcp endpoint | Public English documentation | None | No | Grounding an assistant in current docs |
The manual setup guide and client-specific pages cover the hosted endpoint. Meanwhile, the Docs MCP page says that server is read-only, English-only, Streamable HTTP-only, rate-limited per client, and separate from project data.
Our view: use the hosted first-party project server unless policy requires a self-managed adapter. An unofficial proxy adds a dependency that can see credentials and alter requests, while contributing little when Statsig already supports remote OAuth. For other vendor-operated choices, see the MCP Directory official-server collection.
Setup
The clean setup needs a Statsig account, project access, and a client that supports remote MCP over HTTP and OAuth. No npm package or locally launched process is required for the current first-party route.
- Confirm your Statsig organization permits Personal Console API Keys for your role. Statsig states that its MCP OAuth flow currently supports only Personal Console API Keys.
- Add the remote endpoint to the client's MCP configuration.
- Start the client, follow the browser sign-in and authorization flow, and choose the intended Statsig project.
- Verify with read operations: list experiments, list gates, then fetch one known experiment by ID.
- Inspect the granted project role before attempting any write.
For clients that accept the conventional JSON form, Statsig's verified configuration is:
{
"mcpServers": {
"statsig": {
"url": "https://api.statsig.com/v1/mcp"
}
}
}
That block comes from Statsig's current manual configuration, not from a guessed package. Use your client's guide or the MCP Directory config generator rather than pasting a Cursor path into every application. If the server fails to appear, restart the client, confirm the exact HTTPS URL, and check that the client supports remote HTTP transport.
OAuth is preferable to a long-lived key because the user completes authorization interactively and the client stores the token. The important nuance is that Statsig does not document a menu of special MCP OAuth scopes on the setup page; effective access follows the authorized Personal Console API Key and the user's Statsig permissions. Do not claim a fictional statsig.read scope.
Tools you get
The project server exposes named operations for Statsig entities, but the live tool catalog is the authority because capabilities can change. These four read tools are explicitly named in Statsig's published MCP guide and are the safest starting set.
| Tool name | What it does | Practical use |
|---|---|---|
Get_List_of_Gates | Lists gates, with filters such as stale or permanent | Find cleanup candidates without loading every detail |
Get_Gate_Details_by_ID | Retrieves one gate's rules and metadata | Review targeting and rollout before a change |
Get_List_of_Experiments | Lists project experiments, optionally filtered | Build a compact active-experiment inventory |
Get_Experiment_Details_by_ID | Retrieves groups, parameters, and experiment metadata | Check allocation and configuration for one test |
Statsig's December 2025 workflow guide names those tools in its gate-and-experiment example. The broader current overview also lists write-capable domains, including segments and layers, but it does not publish every live tool identifier in page text. Ask your client to show tools/list before encoding names in prompts or automation; MCP itself defines tool discovery as a paginated protocol operation in the tools specification.
Avoid prompts like “fix all stale flags.” Request a bounded read, select one object, show the proposed payload, and stop before execution.
Permissions and blast radius
Start read-only, then grant write access only to a dedicated integration identity with a defined project role. A general administrator's credential turns a mistaken interpretation into a production configuration change.
Statsig says read-only users can use read tools, while writes require write permission. Its own AI-development guidance recommends a limited-access Console API key and explicitly says never to run destructive tools without user instruction. MCP guidance likewise recommends showing tool inputs and requiring human confirmation for sensitive calls.
The blast radius is specific and serious. Changing a gate rule can expose unfinished code to the wrong users; replacing an experiment can alter groups or parameters and invalidate interpretation; editing a segment can change targeting across every gate or experiment that references it. Deleting a stale gate before removing all code references can leave fallback behavior you never reviewed.
I would require approval on every create, update, archive, delete, rollout, and experiment-decision action. Enable Statsig review policies where available, keep audit logs, limit prompts to one entity, and separate exploratory reads from change sessions. A dedicated identity makes revocation and attribution possible; a shared human key does neither.
Real limits
The main limits are API pagination, rate limits, model context, incomplete product coverage, and the difference between retrieving state and judging it. MCP does not make a large Statsig project fit into one prompt or make an LLM's recommendation statistically valid.
Statsig list APIs paginate. For example, the List Experiments API accepts limit and page, supports at most 100 IDs in one filtered request, and offers sparse fields to trim responses. Use those controls: retrieve names and IDs first, then details for a short shortlist. Dumping hundreds of full rule trees wastes context and makes omissions harder to notice.
Statsig publishes Console API mutation ceilings of approximately 100 requests per 10 seconds and 900 per 15 minutes, per project, in its Console API overview. It does not publish a numeric read limit or a separate numeric authenticated-MCP quota there, so do not promise throughput. The public Docs MCP only says it rate-limits per client. Retries should use backoff, and bulk changes should be deliberately paced.
The server also cannot inspect your repository unless the host separately grants filesystem or source-control tools. It cannot prove that a stale gate has no callers, replace product review, or repair bad event instrumentation by inference. Statsig notes that adding event-count metrics from new logging is currently manual in its AI-development guide. Treat tool output as current system data, not as a complete deployment decision.
When not to use it
Do not use Statsig MCP when a deterministic script, Statsig's own interface, or built-in analysis gives a simpler and safer result. Conversational tool calls are best for exploratory, cross-context work—not repeatable bulk administration.
Choose a plain Console API script for scheduled exports, migrations, CI checks, or hundreds of identical updates: it is testable, version-controlled, resumable, and easier to reconcile. Use Statsig's console and analysis features when interpreting experiment results or making a launch decision; a model summary can hide sample-ratio issues, guardrail movement, or uncertainty. Use the docs-only MCP when the question is merely how Statsig works.
I would adopt Statsig MCP for read-heavy investigation and one-at-a-time, human-approved changes. I would avoid unattended writes and vague portfolio-wide prompts. That trade-off gives an agent timely context without turning probabilistic language interpretation into an unreviewed production control plane. Compare the integration with other curated options in best MCP servers before adding another credential-bearing connection.