On this page

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

Statsig MCP V3 tool reference

Look up the Statsig MCP V3 tools, their actions, and the inputs each one accepts.

Statsig MCP V3 exposes 18 default tools. Clients that use expanded tool exposure show 9 more tools. Tool visibility depends on your permissions and the server configuration. Use the live tool schemas for full nested fields and valid values.

Start with these steps

  1. Call get_context to check your project and permissions.
  2. Use the direct tools for common tasks. Use discover_tools for other operations, reviews, and partial updates.
  3. Confirm changes before you supply confirmation. Project permissions and review policies still apply.

Request shapes

A confirmation looks like this:

json
{ "acknowledged": true, "reason": "Describe the intended change" }

Read tools

Read tools are read-only. Supply action and arguments.params, and include params even when no fields are required.

gate_read

List, get, and inspect feature gates and their history.

experiment_read

List, get, inspect, and retrieve results for experiments.

Use query_fields to return only the fields you need and reduce context consumption.

dynamic_config_read

List, get, and inspect dynamic configs and their history.

metric_read

List and inspect metrics and metric sources.

log_read

Query Logs Explorer and inspect project audit and change history.

Expanded read tools

These tools appear when your client uses expanded tool exposure.

Create tools

Create tools take the body in params["application/json"]. The exception is autotune_create, which requires arguments.params and confirmation. The fields in the table describe the body.

In projects that use Target Apps, gate_create requires targetApps to contain at least one Target App name, not an internal database record ID.

Update tools

Update tools require write access, arguments.params, and confirmation. Supply the resource identifier in arguments.params.path_id and the body in arguments.params["application/json"].

Most update tools replace the whole resource. Read the current state first and preserve any field you don't intend to change. For a partial edit, such as adding a tag, use discover_tools to find the matching operation.

For segment_update, the request body depends on the selected operation and segment type. Read the live schema for the matching body variant. For param_store_update, use path_id for the Parameter Store identifier. Don't use path_name.

Discover additional operations

discover_tools is read-only. Start with resolve when you know the task. Omit filters you're unsure about, especially lane, because updates and review actions can use api_destructive.

Run a discovered operation

  1. Read the returned input schema, lane, and confirmation requirements.
  2. Call the returned execution tool with its operationHandle and arguments that match the schema.
  3. Retrieve a fresh handle when the current one expires.

Discovered arguments use path, query, and body. The params wrapper that direct tools use doesn't apply.

api_destructive covers sensitive updates and review actions, not only deletion. A confirmation requirement is separate from a project review. Approving a review doesn't commit its changes.

Check responses

  • Check isError before you read structuredContent data.
  • Follow the selected operation's pagination.
  • An empty result doesn't establish that a resource is safe to delete.

Was this helpful?