Products
Solutions
Resources
We’re launching Statsig MCP v3 this week, making your agentic experience stronger, safer, and more efficient.
This past quarter, Statsig MCP usage really took off. If your team uses coding agents, odds are that you or someone on your team connected to the MCP to check feature flags, configs, or experiment results. It’s clear you’re very excited about using Statsig headless! (Me too!)
The more you used it, the more we learned: what was working, what was clunky, and what you wished it could do.
All of that information and feedback helped us rebuild Statsig MCP into the new v3. It has more capabilities, lighter context, and outputs built for automation. Most importantly, new granular access controls will let you more safely set who has write permissions.
Here’s a deep dive into why we rebuilt it and what’s changed.
TL;DR: To use Statsig MCP v3, follow these instructions. If you've used Statsig MCP v2, you'll have to reauthenticate your coding agent and update any hardcoded tool calls to match the new names.
Why we rebuilt the MCP
When we asked MCP users about what we could improve, you told us three things consistently:
“The capability I need isn’t there.” MCP tools were built one at a time, so coverage always trailed the Console API. Work that was possible over the API (reading layer experiments and overrides, creating Autotunes, writing to Parameter Stores, pulling change history) meant dropping out of your agent and calling the API directly.
“My agent picks the wrong tool, or the response is hard to use.” A large catalog of similarly-named tools makes selection harder, not easier. And responses written for a human to read are awkward for automation to parse reliably.
“I can’t safely give an agent write access.” Read-only was a single switch for an entire project. Teams that wanted their platform engineers writing while everyone else read had no way to express that, so many teams turned writes off entirely and kept making production changes by hand.
Underneath all three, there was also a core architectural problem: every capability we added became a permanent tool definition loaded into your agent's context at the start of every session, whether or not you used it. That context comes out of the same window as the work you opened the session to do, and you pay for it on every session—including the ones that never touch Statsig. That approach could not keep pace with the Console API without making every agent session more expensive.
What’s new in v3
Full managed Console API coverage
V3 generates its operation catalog directly from released Console API contracts rather than from hand-written tools. Every endpoint in the managed scope (226 of 226) is covered, with no exclusions.
A much smaller session footprint
Instead of loading the full catalog, v3 serves 18 tools at the start of a read-write session and 10 for read-only sessions. These cover the work that accounts for the overwhelming majority of real usage: feature gates, experiments, dynamic configs, metrics, audit and logs, search, and context.
Everything else is reached on demand. In our internal testing, this reduced input tokens by roughly 43% on an equivalent set of tasks, with tool definitions 55–60% smaller depending on the client.
Output your automation can parse
Every tool returns the MCP-standard data and warnings, plus pagination when applicable. You can build against the structured field rather than writing a parser against prose that may change shape.
V3 also normalizes the safe input mistakes agents commonly make (a number passed as a string, an enum in the wrong case, a single value where a list was expected) rather than failing the call. Ambiguous identifiers, unclear destructive intent, and genuinely invalid shapes are still rejected.
V3 exposes get_context for project, permission, and review context when called, which gives the agent your project, permission, and review context at the start of a session. This allows it to work from what actually exists in your project rather than guessing at IDs and names.
Access controls that match how your team works
How access resolves depends on the kind of key in use:
Personal keys combine the owner's role access with the project maximum set by administrators and the token's scope. This is what gives you per-role and per-user control: a platform team can hold write access while everyone else reads.
Omni and legacy Console API keys resolve against the project maximum and token scope. They are not tied to an individual, so role and per-user settings do not apply to them.
In both cases, permissions are applied twice: once when an agent discovers what is available, and again when an operation executes. Tools a caller is not authorized to use do not appear in the session at all, rather than appearing and then failing.
Tested against your client
V3 has compatibility fixtures for client profiles with a standards-first generic profile for anything else. Each profile is checked against the exact runtime tool list, portable schemas, representative calls, and error formats. A profile can change what is visible; it can never grant access beyond your permissions.
Steps to use v3
Here's how to get started! We also have detailed instructions in the public docs.
Add a remote MCP server named Statsig V3 Beta in your client’s settings: https://api.statsig.com/v3/mcp
Use your existing Statsig authentication method. Complete sign-in when prompted, or supply your Console API key in the statsig-api-key header if supported.
Enable v3 and start a new conversation. Disable your previous Statsig connection while testing; keep its settings for rollback.
Test your connection
Ask: “Which Statsig project am I connected to, and what permissions do I have?”
Confirm the project, then try “List my gates” or “Show results for [experiment].” Your existing permissions and review requirements apply.
Migrating from v2
V3 is a full rebuild, so if you’re already using Statsig MCP v2, you’ll need to reauthenticate your coding agent. Along with that, three things to be aware of:
Tool names have changed. Reads are grouped by entity with an explicit action. Get_Gate_Details_by_ID becomes gate_read with action: get_gate_details_by_id, for example. Create and update remain separate operations by design: an unintended create is harder to detect and recover from than a failed update. A complete mapping from all 93 previous tool names to their v3 equivalents is available on request.
Response parsing. v3 returns structuredContent alongside text. If your automation parses tool output, point it at the structured field.
Parameter Store identifiers. For Parameter Store lookup, update, and delete, use params.path_id rather than params.path_name where applicable.
Use the server’s live tool and discovery schemas as the authority for required fields. They reflect what is actually available to your project and permissions.
Also, you do not need to migrate to v3 yet if you’re not ready. V2 will continue to run unchanged for a few months.
Learning where the work is
As excited as we are for headless Statsig, we do want to be clear: the Console isn’t going away. There’s a lot that belongs on a purpose-built screen: a scorecard you're reading with three colleagues, a rollout you want to watch land, a metric definition your team is still arguing about.
What has changed is that more and more of the work around those moments now happens somewhere else: in a coding agent that is already holding your branch, your diff, and the reason the gate exists in the first place.
Our overall goal with Statsig is for your learning to meet the work where it already is. Which entry point you reach for should be a question of what's fastest in the moment: the UI when you want to see something, an agent when you want to do something in the middle of doing something else, the API when it belongs in a pipeline.
That only holds if the entry points are genuinely equivalent. The new MCP v3 will get you that equivalency.
Try it out and let us know what you think!