Statsig MCP exposes experiments, feature gates, dynamic configs, layers, metrics, segments, reviews, audit logs, and observability workflows.
Approve an in-flight review of an autotune experiment. Approval does NOT apply the change to the live autotune — call Commit_Autotune_Review afterward to apply it. The acting user must be an eligible reviewer (see Get_Autotune_Eligible_Reviewers), have approve-reviews permission, and cannot approve their own review. Requires a key owned by a user. path_id = the autotune's ID; path_reviewID = the review ID.
Approve an in-flight review of a dynamic config. Approval does NOT apply the change to the live config — call Commit_Dynamic_Config_Review afterward to apply it. The acting user must be an eligible reviewer (see Get_Dynamic_Config_Eligible_Reviewers), have approve-reviews permission, and cannot approve their own review. Requires a key owned by a user. path_id = the dynamic config's name/ID; path_reviewID = the review ID.
Approve an in-flight review of an experiment (A/B test). Approval does NOT apply the change to the live experiment — call Commit_Experiment_Review afterward to apply it. The acting user must be an eligible reviewer (see Get_Experiment_Eligible_Reviewers), have approve-reviews permission, and cannot approve their own review. Requires a key owned by a user. path_id = the experiment's ID; path_reviewID = the review ID.
Approve an in-flight review of a gate (feature flag). Approval does NOT apply the change to the live gate — call Commit_Gate_Review afterward to apply it. The acting user must be an eligible reviewer (see Get_Gate_Eligible_Reviewers), have approve-reviews permission, and cannot approve their own review. Requires a key owned by a user. path_id = the gate's name/ID; path_reviewID = the review ID.
Cancel (withdraw) an in-flight review of an autotune experiment. This permanently withdraws the proposed change; it does NOT modify the live autotune. Only mutable reviews (pending or accepted) can be cancelled. Requires a key owned by a user. path_id = the autotune's ID; path_reviewID = the review ID.
Cancel (withdraw) an in-flight review of a dynamic config. This permanently withdraws the proposed change; it does NOT modify the live config. Only mutable reviews (pending or accepted) can be cancelled. Requires a key owned by a user. path_id = the dynamic config's name/ID; path_reviewID = the review ID.
Cancel (withdraw) an in-flight review of an experiment (A/B test). This permanently withdraws the proposed change; it does NOT modify the live experiment. Only mutable reviews (pending or accepted) can be cancelled. Requires a key owned by a user. path_id = the experiment's ID; path_reviewID = the review ID.
Cancel (withdraw) an in-flight review of a gate (feature flag). This permanently withdraws the proposed change; it does NOT modify the live gate. Only mutable reviews (pending or accepted) can be cancelled. Requires a key owned by a user. path_id = the gate's name/ID; path_reviewID = the review ID.
Cluster similar log lines into templates (same as `statsig-query log-patterns`). Use after `Query_Logs_Explorer` when raw lines are too noisy. Pass a Logs Explorer filter (e.g. `service:scrapi AND tier:latest AND level:error`) — do not wrap in `#logs{ }`. Statsig/OpenAI internal organizations only (mirrors CAPI `@OpenAIAndStatsigOrgOnly`). Optional: `field` (default clusters on log message field), `limit`, time window (`start_ts`/`end_ts` in ms).
Commit a review of an autotune experiment, APPLYING its proposed change to the live autotune. This is the step that actually mutates the autotune (e.g. starting it, resetting/reallocating, making a decision, or deleting it). Normally called after a different reviewer has approved the review. SELF-APPROVAL: an author cannot Approve_Autotune_Review on their own review — instead, to self-approve, the author commits their own still-pending review directly with this tool. Self-commit succeeds only when the acting user holds the "skip_config_review" permission; this tool bypasses precommit webhooks, so the acting user also needs "bypass_precommit_webhook", otherwise this returns 403. Requires a key owned by a user. path_id = the autotune's ID; path_reviewID = the review ID.
Commit a review of a dynamic config, APPLYING its proposed change to the live config. This is the step that actually mutates the config (e.g. updating rules/default_value, enabling/disabling, archiving, or deleting). Normally called after a different reviewer has approved the review. SELF-APPROVAL: an author cannot Approve_Dynamic_Config_Review on their own review — instead, to self-approve, the author commits their own still-pending review directly with this tool (this is the intended self-approval path). Self-commit succeeds only when the dynamic config permits self-approval and the acting user holds the "skip_config_review" permission. This tool bypasses precommit webhooks, so the acting user also needs "bypass_precommit_webhook"; otherwise this returns 403. Requires a key owned by a user. path_id = the dynamic config's name/ID; path_reviewID = the review ID.
Commit a review of an experiment (A/B test), APPLYING its proposed change to the live experiment. This is the step that actually mutates the experiment (e.g. starting / stopping it, shipping a decision, rolling out a group, or updating settings). Normally called after a different reviewer has approved the review. SELF-APPROVAL: an author cannot Approve_Experiment_Review on their own review — instead, to self-approve, the author commits their own still-pending review directly with this tool (this is the intended self-approval path). Self-commit succeeds only when the experiment's layer permits self-approval and the acting user holds the "skip_config_review" permission. This tool bypasses precommit webhooks, so the acting user also needs "bypass_precommit_webhook"; otherwise this returns 403. Requires a key owned by a user. path_id = the experiment's ID; path_reviewID = the review ID.
Commit a review of a gate (feature flag), APPLYING its proposed change to the live gate. This is the step that actually mutates the gate (e.g. updating rules, enabling/disabling, archiving, or deleting). Normally called after a different reviewer has approved the review. SELF-APPROVAL: an author cannot Approve_Gate_Review on their own review — instead, to self-approve, the author commits their own still-pending review directly with this tool (this is the intended self-approval path). Self-commit succeeds only when the gate permits self-approval and the acting user holds the "skip_config_review" permission. This tool bypasses precommit webhooks, so the acting user also needs "bypass_precommit_webhook"; otherwise this returns 403. Requires a key owned by a user. path_id = the gate's name/ID; path_reviewID = the review ID.
Create an Autotune (multi-armed bandit) experiment that automatically shifts traffic toward the best-performing variant. Specify the variants (arms), the successEvent to optimize for, and the explorationWindow / attributionWindow / winnerThreshold parameters. Set isContextual=true to create a contextual multi-armed bandit (CMAB) that picks an arm per user-context; otherwise a standard MAB is created. Creating an Autotune begins reallocating live SDK traffic across the variants — review the variants and rollout settings before calling.
Open a review proposing a change to an autotune experiment. The change is NOT applied to the live autotune yet — it must be approved (Approve_Autotune_Review) and then committed (Commit_Autotune_Review). Set `type` to the kind of change and supply only the fields that type needs: start (optional start_date) / scheduled_start (start_time) / scheduled_start_edit (new_time) / reallocate — the autotune "reset" (optional reason) / make_decision (winning_group_id) / delete / disable_reviews_locally. Requires a key owned by a user. path_id = the autotune's ID.
Create a new Dynamic Config (static, targetable JSON object) in the Statsig console, including targeting rules, its ID (how we'll refer to it in-code) and its IDtype, which it'll randomize users on. CRITICAL CONSTRAINTS: - the return value for each variant must be set with returnValueJson5. - Always include DefaultValue field in the POST request
Open a review proposing a change to a dynamic config. The change is NOT applied to the live config yet — it must be approved (Approve_Dynamic_Config_Review) and then committed (Commit_Dynamic_Config_Review). Provide a description, an optional set of requested reviewers (use Get_Dynamic_Config_Eligible_Reviewers to find valid IDs), and a `change` carrying exactly one change slot: the content bundle (`rules` and/or `default_value`, which may coexist), one verb field (e.g. is_enabled, is_archived, delete), `restore`, or one metadata field. Requires a key owned by a user (review actions are attributed to the key owner). path_id = the dynamic config's name/ID.
Create an experiment, including its ID (which is how we refer to it in-code), its groups (test/control, and return values) and the ID type it should randomize users on. For metrics, omit direction and hypothesizedValue unless the user explicitly asks for one-sided testing or one-sample testing. Metric direction enables one-sided testing; hypothesizedValue enables one-sample testing against a fixed baseline.
Open a review proposing a change to an experiment (A/B test). The change is NOT applied to the live experiment yet — it must be approved (Approve_Experiment_Review) and then committed (Commit_Experiment_Review). Set `type` to the kind of change (start / stop / pause / restart / abandon / archive / delete / make_decision / rollout / schedule_rollout / reallocate / change_enabled_groups / unarchive / update_owners / update_team / update_settings / update_overrides / update_target_applications / update_allowed_reviewers / update_default_impact_multiplier / scheduled_start / scheduled_start_edit / disable_reviews_locally) and supply only the fields that type needs (e.g. make_decision → winning_group_id; rollout → group_id + rollout_percentage; update_owners → owners; update_settings → settings). Requires a key owned by a user. path_id = the experiment's ID.
Create a new gate (feature flag), including its rules (who should pass it) its ID (how we'll refer to it in-code) and its IDtype, which it'll randomize users on.
Open a review proposing a change to a gate (feature flag). The change is NOT applied to the live gate yet — it must be approved (Approve_Gate_Review) and then committed (Commit_Gate_Review). Provide a description, an optional set of requested reviewers (use Get_Gate_Eligible_Reviewers to find valid IDs), and a `change` carrying EXACTLY ONE proposed operation (e.g. rules, is_enabled, is_archived, delete). Requires a key owned by a user (review actions are attributed to the key owner). path_id = the gate's name/ID.
Create a new layer, including its name, ID type, and optional target apps or team ownership.
Create a new Param Store (a reusable, named collection of typed parameters) in this Statsig project. Provide a name (the in-code identifier), a displayName, and a description. The store is created empty — add parameters afterward with Update_Param_Store. Optionally set targetAppIDs, tags, and team.
Create a new segment, including its name, type, optional ID, ID type, and rules for rule-based segments.
Delete an experiment (A/B test) by ID. Destructive and irreversible — confirm the ID before calling. On a team that requires reviews, prefer proposing the deletion through review (Create_Experiment_Review with type "delete" → approve → commit) instead of deleting directly. Requires a key owned by a user. path_id = the experiment's ID.
Delete a Param Store by name. Destructive and irreversible — it removes a store that SDKs may be reading. Confirm the name before calling.
Edit an in-flight autotune review's metadata — description and/or requested reviewers. Supply any subset; an omitted field keeps the review's current value, and an empty body is rejected. Autotune reviews have no editable "content" (to change the proposed change, cancel and recreate). The review must still be mutable (pending or accepted). Requires a key owned by a user. path_id = the autotune's ID; path_reviewID = the review ID.
Edit an in-flight dynamic config review's metadata (description, requested reviewers) and/or its proposed `change`. Supply any subset; an empty body is rejected. The review must still be mutable (pending or accepted); content (`change`) can only be edited while pending and cannot change the review's type. Requires a key owned by a user. path_id = the dynamic config's name/ID; path_reviewID = the review ID.
Edit an in-flight experiment (A/B test) review's metadata — description and/or requested reviewers. Supply any subset; an omitted field keeps the review's current value, and an empty body is rejected. Experiment reviews have no editable "content" (to change the proposed change, cancel and recreate). The review must still be mutable (pending or accepted). Requires a key owned by a user. path_id = the experiment's ID; path_reviewID = the review ID.
Edit an in-flight gate (feature flag) review's metadata (description, requested reviewers) and/or its proposed `change`. Supply any subset; an empty body is rejected. The review must still be mutable (pending or accepted); content (`change`) can only be edited while pending and cannot change the review's type. Requires a key owned by a user. path_id = the gate's name/ID; path_reviewID = the review ID.
Fetch the full document for a search result id. Use the id returned by search.
List audit logs for this Statsig project. Supports filtering by id, sorting, tags, date range, and pagination.
List the users and reviewer groups eligible to approve/reject a review of this autotune experiment. Use this to pick valid reviewer_ids / reviewer_group_ids when creating or editing an autotune review. The response carries everyone_eligible (true when anyone may review), users (the flattened, deduped set of eligible individuals), and groups (each with its member user_ids). Note: project admins can always review and are NOT enumerated here. path_id = the autotune's ID.
Get a single review for an autotune experiment by its review ID, including its status, proposed change type, author, and requested reviewers. A review is a proposed change that goes through an approve → commit lifecycle before it is applied. path_id = the autotune's ID; path_reviewID = the review ID (from Get_List_of_Autotune_Reviews or Create_Autotune_Review).
Get the details (including rules, return values, and more) for a Dynamic Config (static, targetable JSON) in the Statsig console.
List the users and reviewer groups eligible to approve/reject a review of this dynamic config. Use this to pick valid reviewer_ids / reviewer_group_ids when creating or editing a dynamic config review. The response carries everyone_eligible (true when anyone may review), users (the flattened, deduped set of eligible individuals), and groups (each with its member user_ids). Note: project admins can always review and are NOT enumerated here. path_id = the dynamic config's name/ID.
Get a single review for a dynamic config by its review ID, including its status, proposed change, author, and requested reviewers. A review is a proposed change to the dynamic config that goes through an approve → commit lifecycle before it is applied. path_id = the dynamic config's name/ID; path_reviewID = the review ID (from Get_List_of_Dynamic_Config_Reviews or Create_Dynamic_Config_Review).
List historical versions of a Dynamic Config (static, targetable JSON object) to reconstruct a timeline of how it changed — rules, return values, defaults, and metadata across edits. Useful for debugging when dynamic config behavior changed and what changed it.
Get details including parameters (return values), groups, status & more of an experiment in Statsig. Use query_fields to return only specific top-level fields and keep the response small.
List the users and reviewer groups eligible to approve/reject a review of this experiment (A/B test). Use this to pick valid reviewer_ids / reviewer_group_ids when creating or editing an experiment review. The response carries everyone_eligible (true when anyone may review), users (the flattened, deduped set of eligible individuals), and groups (each with its member user_ids). Note: project admins can always review and are NOT enumerated here. path_id = the experiment's ID.
Get topline and dimensional breakdown results for one specific experiment metric. Use this when you already know the metric ID and need that metric broken down by dimensions. Do not use this tool for an experiment-wide summary across all pulse metrics; use Get_Experiment_Overall_Results instead.
Get overall pulse results for an experiment across all pulse metrics. Use this when you need the experiment-wide topline view or a cross-metric summary. Do not use this tool when you need the dimensional breakdown for one specific metric; use Get_Experiment_Metric_Dimension_Results instead.
Get a single review for an experiment (A/B test) by its review ID, including its status, proposed change type, author, and requested reviewers. A review is a proposed change that goes through an approve → commit lifecycle before it is applied. path_id = the experiment's ID; path_reviewID = the review ID (from Get_List_of_Experiment_Reviews or Create_Experiment_Review).
List historical versions of an experiment (AB Test) to reconstruct a timeline of how it changed — groups, allocation, status, parameters, and metadata across edits. Useful for debugging when experiment behavior changed and what changed it.
Get all details about a gate (feature flag) like its rules, idType, and more, from the Statsig Console. To judge whether a feature is actually live for a user, check status and isEnabled BEFORE reasoning about rules: when isEnabled is false the rules are NOT evaluated and every user receives the same blanket value — status "Launched" means all users pass (gate returns true) and status "Disabled" means all users fail (gate returns false). The rules apply only when isEnabled is true (status "In Progress"), where a user passes only if they match a passing rule. status "Archived" means the gate is retired.
List the users and reviewer groups eligible to approve/reject a review of this gate (feature flag). Use this to pick valid reviewer_ids / reviewer_group_ids when creating or editing a gate review. The response carries everyone_eligible (true when anyone may review), users (the flattened, deduped set of eligible individuals), and groups (each with its member user_ids). Note: project admins can always review and are NOT enumerated here. path_id = the gate's name/ID.
Get the metric results for a given gate and rule in the gate
Get a single review for a gate (feature flag) by its review ID, including its status, proposed change, author, and requested reviewers. A review is a proposed change to the gate that goes through an approve → commit lifecycle before it is applied. path_id = the gate's name/ID; path_reviewID = the review ID (from Get_List_of_Gate_Reviews or Create_Gate_Review).
List historical versions of a gate (feature flag) to reconstruct a timeline of how it changed — rules, IDtype, enabled state, and metadata across edits. Useful for debugging when gate behavior changed and what changed it.
Get all details about a layer, including its parameters and metadata, from the Statsig Console.
List the experiments in a layer, including each experiment's allocation and groups within the layer. The API enforces a maximum query_limit of 100. If query_limit is not provided, default to 100 (or fewer) and never exceed 100.
Get the conditional and ID overrides configured for a layer in the Statsig Console.
List the reviews for an autotune experiment, newest first. A review is a proposed change to the autotune (start / reallocate / make_decision / delete, etc.) that goes through an approve → commit lifecycle before it is applied to the live autotune. Defaults to a small page (the active/most-recent review is the usual interest); pass query_limit / query_page to page further back through history. Use path_id = the autotune's ID.
List the reviews for a dynamic config, newest first. A review is a proposed change to the dynamic config (rules, default_value, enabled state, archive, delete, etc.) that goes through an approve → commit lifecycle before it is applied to the live config. Defaults to a small page (the active/most-recent review is the usual interest); pass query_limit / query_page to page further back through history. Use path_id = the dynamic config's name/ID.
List all Dynamic Configs (static, targetable JSON objects) in this Statsig project. The API enforces a maximum query_limit of 100. If query_limit is not provided, default to 100 (or fewer) and never exceed 100.
List the reviews for an experiment (A/B test), newest first. A review is a proposed change to the experiment (start / stop / make_decision / rollout / settings, etc.) that goes through an approve → commit lifecycle before it is applied to the live experiment. Defaults to a small page (the active/most-recent review is the usual interest); pass query_limit / query_page to page further back through history. Use path_id = the experiment's ID.
List all experiments (AB Tests) in this Statsig project. Supports filtering by status, tags, creator, team (query_teamID), and created date range (query_createdStartDate / query_createdEndDate as YYYY-MM-DD). To fetch several specific experiments at once, pass query_ids (a batch read) instead of calling Get_Experiment_Details_by_ID repeatedly, and use query_fields to return only the fields you need and keep the response small. The API enforces a maximum query_limit of 100. If query_limit is not provided, default to 100 (or fewer) and never exceed 100.
List the reviews for a gate (feature flag), newest first. A review is a proposed change to the gate (rules, enabled state, archive, delete, etc.) that goes through an approve → commit lifecycle before it is applied to the live gate. Defaults to a small page (the active/most-recent review is the usual interest); pass query_limit / query_page to page further back through history. Use path_id = the gate's name/ID.
List all gates (feature flags) in this Statsig project. Live state for each gate is determined by status and isEnabled, not just rules: when isEnabled is false the rules are NOT evaluated — status "Launched" means every user passes (true) and status "Disabled" means every user fails (false); rules apply only when isEnabled is true (status "In Progress"). The API enforces a maximum query_limit of 100. If query_limit is not provided, default to 100 (or fewer) and never exceed 100.
List all layers in this Statsig project. The API enforces a maximum query_limit of 100. If query_limit is not provided, default to 100 (or fewer) and never exceed 100.
List all metric sources in this Statsig project. The API enforces a maximum query_limit of 100. If query_limit is not provided, default to 100 (or fewer) and never exceed 100.
List all metrics in this Statsig project. The API enforces a maximum query_limit of 100. If query_limit is not provided, default to 100 (or fewer) and never exceed 100.
List param stores in this Statsig project. The API enforces a maximum query_limit of 100. If query_limit is not provided, default to 100 (or fewer) and never exceed 100.
List all segments in this Statsig project.
List all tags in this Statsig project, returning each tag's id and name. Use this to resolve a tag name/text (e.g. "oslo-tier-0", "checkout") to its tag id, then pass those ids to the query_tags filter on tools like Get_List_of_Metrics — those filters expect tag ids, not tag names.
Get the full definition for a metric in Statsig, including its type, source, and configuration details.
Get a param store by name, including its description, typed parameters, and metadata.
Get all details about a segment in the Statsig Console.
Get the full input schema, description, and annotations for any Statsig MCP tool by name — including tools not shown in the default tool list (find them with Search_Tools). After fetching the schema, execute the tool with Invoke_Tool.
Get Experiment Summary charts and underlying data.
Execute any Statsig MCP tool by name with arguments — including tools not shown in the default tool list. Find tools with Search_Tools, get their exact input schema with Get_Tool_Schema, then execute them here. The target tool's own permissions apply (e.g. read-only orgs cannot invoke write tools).
Fetch log lines from Statsig Logs Explorer (MCP equivalent of `statsig-query logs`). Uses the same filter syntax as the console filter bar and CLI `--filter` (e.g. `service:scrapi AND tier:latest AND level:error`). Do not wrap filters in `#logs{ }`. Set `source` to `logs` (default), `events`, or `spans`. Supports time window (`start_ts`/`end_ts` in ms), `columns`, `limit`, and cursor pagination via `after`. For noisy results, follow up with `Cluster_Log_Patterns`.
Reject an in-flight review of an autotune experiment. Rejection is terminal — the proposed change is not applied and the review cannot be reopened (create a new review to retry). A `reason` is required. The acting user must be an eligible reviewer (see Get_Autotune_Eligible_Reviewers) and cannot reject their own review. Requires a key owned by a user. path_id = the autotune's ID; path_reviewID = the review ID.
Reject an in-flight review of a dynamic config. Rejection is terminal — the proposed change is not applied and the review cannot be reopened (create a new review to retry). A `reason` is required. The acting user must be an eligible reviewer (see Get_Dynamic_Config_Eligible_Reviewers) and cannot reject their own review. Requires a key owned by a user. path_id = the dynamic config's name/ID; path_reviewID = the review ID.
Reject an in-flight review of an experiment (A/B test). Rejection is terminal — the proposed change is not applied and the review cannot be reopened (create a new review to retry). A `reason` is required. The acting user must be an eligible reviewer (see Get_Experiment_Eligible_Reviewers) and cannot reject their own review. Requires a key owned by a user. path_id = the experiment's ID; path_reviewID = the review ID.
Reject an in-flight review of a gate (feature flag). Rejection is terminal — the proposed change is not applied and the review cannot be reopened (create a new review to retry). A `reason` is required. The acting user must be an eligible reviewer (see Get_Gate_Eligible_Reviewers) and cannot reject their own review. Requires a key owned by a user. path_id = the gate's name/ID; path_reviewID = the review ID.
Search the Statsig MCP data source and return relevant results. Use the fetch tool to retrieve full documents.
Search the full catalog of Statsig MCP tools by keyword. More tools exist than are listed by default — reviews (create/approve/reject/commit), autotunes, param stores, segments, layers, deletes, code cleanup, and more. Fetch a found tool's schema with Get_Tool_Schema, then execute it with Invoke_Tool.
Start code cleanup for a stale experiment by name, which creates a PR to remove the experiment from your codebase.
Start code cleanup for a gate by name, which creates a PR to remove the gate from your codebase.
Fully update a dynamic config, replacing everything the dynamic config currently has on the Statsig console with the data included in this POST request. Use the GET option to gather the attributes of the dynamic config, edit them, then use this tool. CRITICAL CONSTRAINTS: - the return value for each variant must be set with returnValueJson5. - Always include DefaultValue field in the POST request
Fully update an experiment, replacing everything the experiment currently has on the Statsig console with the data included in this POST request. Use the GET option to gather the attributes of the experiment, edit them, then use this Tool. For metrics, omit direction and hypothesizedValue unless the user explicitly asks for one-sided testing or one-sample testing. Metric direction enables one-sided testing; hypothesizedValue enables one-sample testing against a fixed baseline.
Fully update a gate, replacing everything the gate currently has on the Statsig console with the data included in this POST request. Use the GET option to gather the attributes of the gate, edit them, then use this tool.
Fully update a layer, replacing everything the layer currently has on the Statsig console with the data included in this POST request. Use the GET option to gather the attributes of the layer, edit them, then use this tool.
Update an existing Param Store by name. Set its description and/or its parameters. Each parameter is typed (string/boolean/number/object/array) and is either a static value or a reference to a gate, layer, dynamic config, or experiment. Note: the parameters field replaces the store's full parameter list, so include every parameter you want to keep. This modifies a live store that SDKs read.
Update a Statsig segment using the appropriate segment endpoint. Supports rule-based rule updates and add operations for ID list / user store ID list segments via params.query_operation.
The Statsig MCP integration connects your Dench AI CRM directly to Statsig MCP, so agents can read and act on your Statsig MCP data as part of everyday work — answering questions in chat, keeping your CRM in sync, and running automations without anyone copying data between tools.
86 actions are available for agents to invoke on your behalf. Every call runs through Statsig MCP's own authorization, scoped to the account you connect.
Sign in to your Dench workspace and open Integrations.
Find Statsig MCP and click Connect — you'll authorize access through Statsig MCP's own sign-in flow. No API keys or code required.
Ask an agent to use Statsig MCP in chat, or call it from an automation.
Manage or disconnect the connection any time from workspace settings.
The Dench Statsig MCP integration connects your AI CRM to Statsig MCP, so AI agents can work with your Statsig MCP data as part of chats, automations, and CRM workflows. You connect your account once, and every agent in your workspace can use it — governed by your workspace permissions.
The Statsig MCP integration currently exposes 86 actions, including Approve autotune review, Approve dynamic config review, Approve experiment review, Approve gate review, Cancel autotune review, and Cancel dynamic config review. Agents invoke them on your behalf from chat or from automations.
No. You connect Statsig MCP from your Dench workspace using Statsig MCP's own sign-in and authorization flow — no API keys to copy, no glue code to maintain.
Connections are authorized through Statsig MCP's own authentication flow, and Dench stores only the authorization needed to act on your behalf. You can review and disconnect the Statsig MCP connection from your workspace settings at any time.