ConfigCat

@ConfigCat list all feature flags in the mobile-app config and show which ones are currently enabled in production

Found 12 feature flags in mobile-app config. Production environment status: 'new_checkout_flow' (enabled, 100% rollout), 'dark_mode' (enabled, targeting beta users), 'payment_v2' (disabled), 'social_login' (enabled, 50% gradual rollout), 'offline_mode' (disabled), plus 7 additional flags. Each flag includes its key, type (boolean/string/number), current targeting rules, and last-modified timestamp. Use the flag IDs returned here to update individual evaluation formulas.

This read-heavy example demonstrates cross-environment visibility — essential when coordinating releases. Requires API key with read access to the specified product and config. The MCP returns structured metadata (IDs, types, tags) that downstream prompts can reference, but won't show the full targeting-rule logic unless you request a specific flag's evaluation formula.

@ConfigCat create a new boolean flag called 'ai_suggestions' in the web-app config, default it to false, and add a 'beta' tag

Created feature flag 'ai_suggestions' (ID: 67890) in web-app config. Type: boolean. Default value: false across all environments. Applied tag: 'beta'. The flag is now visible in your ConfigCat dashboard and ready for targeting rules. Note: this operation modified the config's structure; any in-flight dashboard edits may encounter optimistic-concurrency conflicts until users refresh.

This write example shows flag provisioning from chat — useful when spinning up experiments quickly. The MCP enforces unique keys per config and returns the new flag's ID for subsequent patch operations. Be aware: creating flags doesn't automatically enable them; you'll need a separate prompt to set environment-specific evaluation formulas. Side-effect: teammates editing the same config in the UI may see a version-conflict warning.

@ConfigCat compare the 'recommendation_engine' flag's targeting rules between staging and production, then draft a rollout plan to move staging's config to prod safely

Staging: 'recommendation_engine' targets segment 'internal_testers' (100% on) + 10% gradual rollout to all users. Production: flag exists but is fully disabled (0% rollout). Recommended rollout plan: (1) Enable for 'early_adopters' segment in prod (est. 200 users), monitor error rates for 24h. (2) If stable, increase gradual rollout to 25%, then 50%, then 100% over one week. (3) Remove staging-only segments before final prod push to avoid config drift. Use '@ConfigCat patch' to apply each step incrementally.

This synthesis example pairs the MCP's environment-comparison capability with the AI's planning logic — ideal for release coordination. The MCP fetches both evaluation formulas (including ordered targeting rules and percentage rollouts) and the AI identifies divergence. Requires read access to both environments. The draft plan is advisory; you must explicitly approve each patch operation since targeting changes affect live traffic.

When ConfigCat beats hardcoded gates for staged releases

A 6-person SaaS team shipping a redesigned billing flow wants to roll it out to 10% of users, then 50%, then all—without redeploying. ConfigCat's percentage-targeting rules let you patch the environment setting value from Switchy mid-rollout, adjusting the cohort in real time while the team watches error rates in another tab. The MCP's patch tool preserves your targeting order and concurrency version, so you won't clobber a teammate's parallel change. This works until you hit 30+ flags across 4+ environments; at that scale the list-and-patch loop gets tedious and you want a dedicated release dashboard. If your rollout cadence is weekly or slower and your flag count is under 20, ConfigCat in Switchy keeps the whole team in sync without leaving chat.

How ConfigCat MCP speeds up customer-specific troubleshooting

A 3-person support team fields a ticket: one enterprise customer sees the old checkout UI while others see the new one. The rep pulls the ConfigCat environment values in Switchy, filters by the checkout flag key, and spots a segment rule targeting that customer's org ID to the legacy experience. She patches the rule to remove the override, confirms the change in the concurrency version, and closes the ticket in 4 minutes. The MCP's get-environment-setting-value tool surfaces the full targeting formula without opening the vendor console, so the diagnosis happens in the same thread as the ticket. This breaks down when your product has 100+ customers with bespoke overrides; at that point you need audit logs and a proper feature-management workflow. For teams under 50 enterprise accounts, the MCP shortcut is faster than context-switching to the ConfigCat UI.

When listing flags in Switchy beats spreadsheet archaeology

A 5-person compliance team preparing for SOC 2 needs a current inventory of every feature flag touching PII, including which configs own them and which environments they're live in. The list-flags-and-settings tool returns keys, types, and tag metadata for one config at a time; the team runs it across 3 configs in Switchy, exports the JSON, and cross-references the PII tags they applied last quarter. The output is machine-readable, so they pipe it into a compliance doc template without manual transcription. This workflow assumes your tagging discipline is already in place—if your flags aren't tagged, the MCP just gives you a raw dump with no semantic grouping. For teams that tag flags consistently and run audits quarterly, the MCP turns a 2-hour spreadsheet hunt into a 15-minute Switchy query.