How to automate feature flags in GitHub Copilot with real workflow examples

If you have been following along, you already know why connecting GitHub Copilot to your feature flag system matters. The short version: AI-generated code ships fast, but without guardrails it creates inconsistency and risk. Feature flags give you runtime control over that code. But if creating and managing flags requires manual steps outside the IDE, developers will skip them when they are in a hurry. That is where automation comes in.

This post shows you how to automate feature flag workflows in GitHub Copilot using the Unleash MCP server. We will cover installation, configuration, and three real workflow examples: evaluating and wrapping a risky change, managing rollouts across environments, and cleaning up flags after a successful release. By the end, you will have a working setup and the patterns to scale it across your team.

Let’s get into it.

What You Need Before Starting

The Unleash MCP server runs as a local process that communicates with GitHub Copilot via the Model Context Protocol (MCP). GitHub Copilot supports MCP in several environments: VS Code, JetBrains IDEs (IntelliJ, PyCharm, WebStorm), Visual Studio, and Neovim. This guide uses VS Code as the primary example since it is the most common setup. For other environments, see the GitHub Copilot integration documentation.

Here is what you need:

• Node.js 18+ – The server is distributed as an npm package
• VS Code 1.102+ – Native MCP support is generally available in this version (other IDEs have similar requirements)
• An Unleash instance – Cloud or self-hosted, with API access
• A Personal Access Token (PAT) – With permissions to create and manage feature flags

If you are on an older VS Code version, MCP support may be experimental or unavailable. Upgrade before proceeding.

Installing the MCP Server

The fastest way to run the server is via npx. No global install required. But for a proper setup, you want the server to start automatically when you open your IDE. The steps below are for VS Code. JetBrains, Visual Studio, and Neovim use different configuration files, but the same MCP server and credentials.

Create a file at .vscode/mcp.json in your project root:

{
  "servers": {
    "unleash-mcp": {
      "name": "Unleash MCP",
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
      "envFile": "~/.unleash/mcp.env"
    }
  }
}

Notice the envFile property. Instead of inlining your credentials (bad idea for version control), we point to a file outside the project. This keeps secrets out of your repo and makes the config reusable across projects.

Create the env file at ~/.unleash/mcp.env:

UNLEASH_BASE_URL=https://your-instance.getunleash.io/api
UNLEASH_PAT=your-personal-access-token
UNLEASH_DEFAULT_PROJECT=default

Replace the values with your actual Unleash instance URL, PAT, and default project. The UNLEASH_DEFAULT_PROJECT is optional but saves you from specifying it on every tool call.

Reload VS Code by running Developer: reload window from the Command Palette. The server should start automatically.

Verifying the Setup

Open the Chat view (`Cmd+Shift+I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and click the Tools icon (wrench). You should see the Unleash MCP tools listed:

• evaluate_change
• detect_flag
• create_flag
• wrap_change
• set_flag_rollout
• get_flag_state
• toggle_flag_environment
• remove_flag_strategy
• cleanup_flag

If you do not see them, check:

1. The mcp.json file is in .vscode/ at the project root
2. Your env file path is correct and the file exists
3. Node.js and npm are available in your terminal
4. Your Unleash PAT has the right permissions

You can also run MCP: List Servers from the Command Palette and select Show Output to see logs:

[info] Starting server unleash-mcp
[info] Connection state: Starting
[info] Starting server from LocalProcess extension host
[info] Connection state: Starting
[info] Connection state: Running
[info] Discovered 9 tools

Real Workflow Example #1: Evaluate and Wrap a Risky Change

The MCP server exposes nine tools, but the core automation uses four of them in sequence:

1. evaluate_change – Analyze a code change and determine if it needs a flag
2. detect_flag – Check if a suitable flag already exists
3. create_flag – Create a new flag with proper naming and metadata
4. wrap_change – Generate framework-specific code to guard the feature

Here is a real example: adding Stripe payment processing to an e-commerce checkout.

Step 1: Evaluate the Change

Before writing any code, ask Copilot to evaluate whether this needs a flag:

Evaluate whether the Stripe payment integration should be behind a feature flag.The change modifies the checkout service and handles credit card processing.

Copilot calls evaluate_change with your description. The tool analyzes the risk level and returns a recommendation. For a payment integration, it will almost certainly recommend a flag.

The response includes a suggested flag name (e.g., stripe-payment-integration) following your project’s naming conventions.

Step 2: Check for Duplicates

Before creating a new flag, the server checks if a similar one already exists. This happens automatically when you follow the evaluate → create flow, but you can also call it explicitly:

Check if a feature flag for payment processing already exists before creating a new one.

Copilot calls detect_flag and searches for matching flags. If it finds one (say, payment-gateway-v2), it will suggest reusing it instead of creating a duplicate.

This matters in large codebases. Flag sprawl is real, and cleaning up stale flags is tedious work.

Step 3: Create the Flag

If no suitable flag exists, create one:

Create a release flag for the Stripe payment integration.

Copilot calls create_flag with:

• Name: stripe-payment-integration
• Type: release
• Description: Auto-generated from your prompt

The flag is automatically created in Unleash, disabled by default in all environments. You can verify it in the Unleash dashboard.

Step 4: Wrap the Code

Now generate the wrapping code:

Wrap the Stripe checkout handler with the stripe-payment-integration flag.

Copilot calls wrap_change and returns framework-specific code:

const { initialize, isEnabled } = require('unleash-client');

// Initialize once at app startup
const unleash = initialize({
  url: 'https://your-instance.getunleash.io/api',
  appName: 'checkout-service',
  customHeaders: { Authorization: process.env.UNLEASH_API_TOKEN }
});

app.post('/checkout', async (req, res) => {
  const context = { userId: req.user.id, beta: req.user.isBeta };

  if (isEnabled('stripe-payment-integration', context)) {
    // New Stripe payment flow
    const result = await stripeService.processPayment(req.body);
    return res.json(result);
  } else {
    // Existing payment flow
    const result = await legacyPaymentService.process(req.body);
    return res.json(result);
  }
});

The snippet matches your framework and includes context for user-level targeting. Accept it, adjust as needed, and commit.

Scaling Automation with Custom Instructions

The workflow above is powerful, but you do not want developers to remember to ask Copilot about flags every time. The real automation comes from project-level instructions that make flag evaluation automatic.

Create .github/copilot-instructions.md or AGENTS.md in your repo:

## Feature Flag Policy

When implementing new features or modifying high-risk code paths:

1. Always use the `evaluate_change` tool to assess whether the change needs a feature flag
2. Prefer reusing existing flags over creating new ones (use `detect_flag`)
3. Follow kebab-case naming: `domain-action-variant`
4. All payment, authentication, and external API changes MUST be flagged
5. Use `wrap_change` to generate framework-appropriate guard code

Now Copilot will consider these instructions on every interaction. When a developer asks to “add Stripe payments” Copilot will automatically evaluate, detect, create, and wrap without being explicitly asked.

This is how you scale automation and governance across a team without adding friction.

Real Workflow Example #2: Managing Rollouts Across Environments

Once a flag exists, you can automate rollout strategies and toggle environments without leaving the editor.

Check current state

What is the current state and rollout strategies for stripe-payment-integration?

Copilot calls get_flag_state and returns the flag metadata, enabled environments, and active strategies.

Enable in staging

Enable stripe-payment-integration in the staging environment.

Copilot calls toggle_flag_environment to flip the flag on for staging while keeping it disabled in production.

Configure a rollout (coming soon)

Set up a gradual rollout for stripe-payment-integration: 10% for 24 hours, then 50% for 48 hours, then 100%.

Copilot calls set_flag_rollout to configure the strategy. Note: automated progression with Impact Metrics is currently in beta. For now, milestones require manual advancement or external triggers.

Real Workflow Example #3: Cleaning Up After Rollout

Feature flags are temporary. Once a feature is fully shipped, the automation should help you remove the flag and the conditional code.

Clean up the stripe-payment-integration flag. The feature is fully rolled out.

Copilot calls cleanup_flag and returns:

• All files and line numbers where the flag is used
• Which code path to preserve (the “enabled” branch)
• Suggestions for tests to run after removal

Review the list, remove the conditional branches, and delete the flag from Unleash. Your codebase stays clean.

What’s Next

This setup gives you the foundation. From here, you can:

• Add more team members – Commit the .vscode/mcp.json to your repo (env file stays local)
• Configure team-wide custom instructions – Standardize flag policies across all developers
• Set up other IDEs – Use the same MCP server with JetBrains, Visual Studio, Neovim, or Copilot CLI
• Explore Impact Metrics – Automate and safeguard rollout progression based on real metrics

For the full technical reference, see the GitHub repository. For IDE-specific guides, check out the GitHub Copilot integration documentation.

The MCP server is currently experimental, but these automation patterns are production-tested. Start with low-risk flags, build confidence, and expand from there.

Happy flagging.