Cursor and Unleash: Feature Flags built into your AI-first IDE

Cursor is not an IDE with an AI sidebar. It is an IDE rebuilt around AI. Agent mode writes code across multiple files, runs tests, and iterates without waiting for approval at each step. Cloud Agents clone repos and work in parallel while you do something else. The CLI lets you run agents from the terminal alongside your editor.

This architecture makes teams fast. It also makes governance harder. When an agent modifies a critical service, creates an API endpoint, or refactors authentication logic, there is no natural pause where someone asks: “Should this be behind a feature flag?”

The Unleash MCP server brings that question into the workflow automatically. Combined with Cursor’s Rules, Hooks, and plugin system, it creates a governance layer that is native to the IDE rather than bolted on afterward.

The governance gap in AI-first development

The DORA State of AI-Assisted Software Development report found that delivery stability tends to decrease as AI usage increases. This is not because AI produces bad code. It is because governance practices have not caught up with the speed of AI-assisted development.

Cursor compounds this dynamic in a specific way: it supports multiple models. A team might use Claude Opus for complex refactors, GPT-5 for quick edits, Gemini for documentation, and Cursor’s own Composer model for routine coding tasks. The Auto feature switches between models based on the task.

Each model may produce different patterns for the same feature flag operation. One might create a flag called enable_stripe, another stripe-payment-integration, a third new_payment_flow. Without a consistent layer underneath, the flexibility that makes Cursor powerful becomes a source of fragmentation.

Feature flags are supposed to reduce risk. But inconsistent flags, across models, across repos, across teams, create their own problems: duplicate toggles, naming drift, flags that nobody remembers to clean up.

In June 2025, a missing feature flag caused a global Google Cloud outage lasting over three hours. Google’s postmortem was blunt: if the configuration change had been flag-protected, recovery would have taken seconds. Google has world-class infrastructure engineering. They still got burned by a change that shipped without a flag.

When AI agents are making changes at machine speed, the margin for error shrinks further.

Connecting Cursor to your feature flag system

We built the Unleash MCP server to solve this problem. The Unleash MCP server exposes feature flag management capabilities directly to Cursor’s agent, regardless of which model is generating the code.

When the server is configured, Cursor’s agent gains access to tools that enforce your FeatureOps practices:

evaluate_change analyzes a code change and determines whether it needs a feature flag. The tool considers the type of modification, the files involved, and the risk level. A documentation update probably does not need a flag. A payment integration almost certainly does.

detect_flag checks whether a suitable flag already exists in Unleash. This prevents duplication. If your team already has a flag for payment processing, the agent will suggest reusing it rather than creating a new one.

create_flag generates a new feature flag with proper naming, typing, and documentation. The Unleash MCP server enforces your team’s conventions. No more arbitrary names cluttering the codebase.

wrap_change produces framework-specific code that guards the new feature behind the flag. Whether you work in React, Django, Go, Spring Boot, or any of the languages Unleash supports, the wrapping code follows patterns already in your codebase.

Supporting tools handle the rest of the lifecycle via API calls: set_flag_rollout configures rollout strategies, get_flag_state retrieves flag metadata, toggle_flag_environment controls per-environment activation, remove_flag_strategy cleans up strategies, and cleanup_flag guides safe removal of stale flags.

Feature flags are temporary by design. The Unleash MCP server treats the full lifecycle, from creation to cleanup, as part of the workflow.

Four layers of governance, native to the IDE

What makes the Cursor integration different is how the IDE’s own features layer on top of the MCP server. Cursor provides four mechanisms that turn MCP tools into automated governance.

Rules encode your policies

Cursor Rules live in .cursor/rules/ as version-controlled markdown files. You write a rule that says:

All changes in the payments domain require feature flags. Use kill-switch type for external provider integrations. Follow the naming convention payments-{feature}-{variant}.

Set the rule’s glob pattern to src/payments/**, and the agent will follow those instructions whenever it works with payment code. No prompting needed.Rules support four activation modes. “Always Apply” loads the rule into every session. “Apply Intelligently” lets the agent decide based on the rule’s description. “Apply to Specific Files” triggers on glob patterns. “Apply Manually” activates only when you invoke @rule-name. On Teams and Enterprise plans, administrators can create Team Rules with enforcement toggles that prevent developers from disabling mandatory policies.

Hooks validate and audit MCP operations

Cursor hooks are scripts in .cursor/hooks.json that fire at specific points in the agent loop. The beforeMCPExecution hook fires before any MCP tool call. You can write a hook that validates flag names against your naming convention before the request reaches the Unleash server.

If the name violates policy, the hook returns deny with a message. The agent adjusts and retries. The afterMCPExecution hook is useful for audit logging: record every flag creation, every toggle, every cleanup operation. Enterprise teams can distribute hooks via the web dashboard. They sync to all team members automatically.

Skills orchestrate multi-step workflows

Cursor supports skills as SKILL.md files within plugins. A /evaluate-and-flag skill defines the complete workflow: evaluate the change, check for duplicates, create the flag if needed, wrap the code, and suggest a rollout strategy.

Skills are invoked with a slash command or discovered automatically by the agent when the context is relevant. They bridge the gap between “here are the tools” and “here is how to use them together.”

Plugins bundle everything for distribution

Cursor’s plugin system packages Rules, Skills, MCP servers, and Hooks into a single installable unit. A FeatureOps plugin can bundle the Unleash MCP server configuration, rules for different domains, evaluation skills, and validation hooks. On Teams and Enterprise plans, administrators can add plugins to a Team Marketplace and set them as required, so every developer gets the same setup automatically. The plugin structure is team-specific by design: your rules, hooks, and naming conventions reflect how your organization builds software.

These layers stack. A developer working on a payment feature has the FeatureOps rule loaded automatically. The agent follows the rule’s instructions and calls the Unleash MCP server. A hook validates the flag name before creation. The skill orchestrates the multi-step workflow. The plugin ensures the entire setup is consistent across the team.

What this looks like in practice

A developer opens Cursor and starts working on a Stripe payment integration. As soon as the agent touches files in src/payments/, the glob-scoped FeatureOps rule loads. The rule instructs the agent to evaluate whether the change needs a flag.

The agent calls evaluate_change. The Unleash MCP server confirms the change is high-risk and suggests the name payments-stripe-integration. The agent calls detect_flag to check for duplicates. None found. It calls create_flag. Then a beforeMCPExecution hook validates the name against the naming convention and allows the request.

The agent implements the Stripe integration and wraps the new code:

if (unleash.isEnabled("payments-stripe-integration", context)) {
    return stripeService.processPayment(request);
} else {
    return legacyPaymentService.process(request);
}

The flag exists in Unleash, disabled by default. The team tests in staging, enables for internal users, then rolls out gradually. If error rates spike, the flag is disabled instantly. No deployment required.

Two weeks later, the feature is stable at 100%. The developer invokes /evaluate-and-flag and asks to clean up the flag. The agent calls cleanup_flag, removes the conditional code, preserves the Stripe path, and runs the test suite. The flag is archived on Unleash. No technical debt left behind.

The same workflow runs in the CLI:

agent "Add Stripe and flag it"

This triggers the same MCP tools, follows the same rules, and produces the same result. Cloud Agents can do this across multiple repos in parallel, opening PRs for review.

The full release picture

Creating flags is the beginning. Unleash provides the infrastructure for the entire release lifecycle.

Rollout strategies let you target specific users, regions, or percentages of traffic. Start with internal users, expand to beta testers, then gradually increase to 100%. Release templates define reusable rollout patterns with automatic pauses if error rates spike.

Impact Metrics collect production signals (request rates, error counts, latency) directly from your application via the Unleash SDK. These metrics tie directly to feature flags, so you can see exactly how a new feature affects your system. Automated progression advances the rollout when metrics are healthy and pauses when they are not.

Getting started

The fastest way to get started is the one-click install from cursor.directory. Click Add to Cursor, enter your Unleash API URL and personal access token, and the MCP server is ready.

For team use, we recommend moving credentials to an envFile so the configuration stays safe to commit. Alternatively, you can also create a new .cursor/mcp.json file in your project manually:

{
  "mcpServers": {
    "unleash": {
      "command": "npx",
      "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
      "envFile": "~/.unleash/mcp.env"
    }
  }
}

Commit this file to version control. Credentials come from the envFile, keeping secrets out of the repository. The same MCP server works in the Cursor CLI with no extra configuration.

The Unleash MCP server also works with Claude Code, GitHub Copilot, and Kiro. The Cursor integration adds Rules, Hooks, Skills, and Plugins on top, but the underlying MCP server is shared across all platforms.

For the full setup guide, including Rules templates, hook examples, and a complete plugin definition, see our Cursor integration documentation.

Governance that ships with the IDE

The pattern across the industry is clear: AI-assisted development is accelerating code production but not the governance practices that keep software stable. Feature flags are the control layer. But manually remembering to add them does not scale when agents are making changes autonomously.

Cursor’s architecture offers an answer. Rules encode policies. Hooks validate and audit. Skills orchestrate workflows. Plugins distribute the entire setup. The Unleash MCP server provides the tools that tie it all together.

The result is a workflow where AI writes the code, governance is enforced by the IDE, and releases are safe by default. Not because developers remember to follow the rules, but because the rules are built into the tool they already use.