Unleash MCP Server

A purpose-driven Model Context Protocol (MCP) server for managing Unleash feature flags. This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.

Overview

This MCP server provides tools that integrate with the Unleash Admin API. It evaluates code changes to decide when a feature flag is needed, creates flags with proper validation and typing, and detects existing flags to prevent duplicates or encourage reuse. The server streams progress for visibility during operations, handles errors gracefully with helpful hints, and follows best practices from the Unleash documentation.

Every tool falls into one of these use cases:

See the Tool reference section for detailed parameters and output for each tool.

Workflows

The sections below walk through each use case. For agent-specific prompt examples and setup, see the dedicated integration guides for Claude Code, Cursor, GitHub Copilot, Kiro, and OpenCode.

Get started

You have two ways to run the Unleash MCP server:

• Local MCP server: Runs inside your LLM client on your machine. Use this setup if your organization allows installing MCP servers on developer laptops. See Run the MCP server locally.
• Remote MCP server: Hosted by your Unleash instance. Use this setup if developers cannot install local MCP servers, or if you want a single, managed entry point for all clients.

Run the MCP server locally

This section covers the different ways to install and run the Unleash MCP server locally. You can either follow a setup for agents (such as Claude Code and Codex), run the MCP as a standalone process using npx, or use a local development setup.

Prerequisites

Before you can run the server locally, you need the following:

• Node.js 18 or higher
• Yarn package manager or npm
• An Unleash instance (hosted or self-hosted)
• A personal access token with permissions to create feature flags

Agent setup

You can add the MCP server directly to Claude Code or Codex. Agent configurations are path-specific. You must run the following command from the root directory of the project where you want to use the MCP.

For Claude Code:

claude mcp add unleash \
    --env UNLEASH_BASE_URL={{your-instance-url}} \
    --env UNLEASH_PAT={{your-personal-access-token}} \
    -- npx -y @unleash/mcp@latest --log-level error

Check out the dedicated Claude Code integration guide for additional guidance and best practices.

For Codex:

codex mcp add unleash \
    --env UNLEASH_BASE_URL={{your-instance-url}} \
    --env UNLEASH_PAT={{your-personal-access-token}} \
    -- npx -y @unleash/mcp@latest --log-level error

To opt in to or out of feedback reports without a consent prompt, add --env UNLEASH_MCP_SEND_FEEDBACK=true or --env UNLEASH_MCP_SEND_FEEDBACK=false to either command.

For other agents, see the dedicated integration guides:

• Cursor
• GitHub Copilot (VS Code and Copilot CLI)
• Kiro

Quickstart with npx

You can run the MCP server as a standalone process without cloning the repository using npx. Provide configuration through environment variables or a local .env file in the directory where you run the command:

UNLEASH_BASE_URL={{your-instance-url}} \
UNLEASH_PAT={{your-personal-access-token}} \
UNLEASH_DEFAULT_PROJECT={{default_project_id}} \
npx @unleash/mcp@latest --log-level debug

The CLI supports the same flags as the local build (for example, --dry-run, --log-level).

Local development setup

Follow these steps to set up the project for local development.

1. Install dependencies

Clone the repository and install dependencies using Yarn.

git clone https://github.com/Unleash/unleash-mcp.git
cd unleash-mcp
yarn install

2. Configure environment variables

Copy .env.example to .env and fill in your Unleash credentials:

cp .env.example .env

Edit .env:

UNLEASH_BASE_URL={{your-instance-url}}
UNLEASH_PAT={{your-personal-access-token}}
UNLEASH_DEFAULT_PROJECT={{default_project_id}}  # Optional: the project the MCP should use by default

3. Build the project

yarn build

Output will be in the dist/ directory.

4. (Optional) Run checks

Run type checking, linting, and tests:

# Type checking and linting
yarn lint
# Run tests (the Vitest framework is configured, but no test suites yet)
yarn test

Running the server

Development mode with hot reload

yarn dev

Production mode

node dist/index.js

With CLI flags

# Dry run mode (simulates API calls without actually creating flags)
node dist/index.js --dry-run
# Custom log level
node dist/index.js --log-level debug
# Combine flags
node dist/index.js --dry-run --log-level debug

Remote MCP server

The remote MCP server lets LLM clients connect to a Streamable HTTP MCP server hosted by your Unleash instance, without installing anything locally. This is useful when developers cannot run MCP servers on their laptops, or when you want to manage MCP access centrally.

When enabled, your Unleash instance exposes an MCP endpoint at:

https://<your-instance-url>/api/admin/mcp

The remote MCP server exposes the same tools as the local server. For feedback reports, an admin decides for the whole instance instead of each user opting in. See Feedback from the remote server.

Enable the remote MCP server

To enable the remote MCP server on your instance:

Connect a client

Point your MCP client at the endpoint shown in Admin settings > Remote MCP server. You don’t need an OAuth client ID or client secret. MCP clients register themselves with your instance the first time they connect.

Authenticate with one of the following options:

claude mcp add --transport http unleash https://<your-instance-url>/api/admin/mcp

Feedback from the remote server

For the remote MCP server, an admin turns feedback reports on or off for the whole instance. Users don’t see a consent prompt.

To change the setting, go to Admin settings > Remote MCP server and toggle Send feedback from the Remote MCP Server to Unleash. The setting is enabled by default, including on existing instances after you upgrade, and only takes effect while the remote MCP server is enabled.

When the setting is enabled, the remote server shares the same anonymous diagnostic reports as the local server. See What is recorded. When the setting is disabled, remote clients don’t see the send_feedback tool.

Tool reference

This section describes each of the core tools in detail, including its purpose, parameters, and output.

Create flag

The create_flag tool creates a new feature flag in Unleash with comprehensive validation and progress tracking.

When to use

Use this tool when you have already determined that a feature flag is required (for example, after running evaluate_change) and you are ready to create it with the correct type and metadata.

Parameters

The tool accepts the following parameters:

• name (required): Unique feature flag name within the project.
• type (required): Feature flag type indicating lifecycle and intent.
  • release: Gradual feature rollouts to users.
  • experiment: A/B tests and experiments.
  • operational: System behavior and operational toggles.
  • kill-switch: Emergency shutdowns or circuit breakers.
  • permission: Control feature access based on user roles or entitlements.
• description (required): Clear explanation of what the flag controls and why it exists.
• projectId (optional): Target project (defaults to UNLEASH_DEFAULT_PROJECT).
• impressionData (optional): Enable analytics tracking (defaults to false).

Usage example

Agent prompt

Use create_flag with:
- name: "new-checkout-flow"
- type: "release"
- description: "Gradual rollout of the redesigned checkout experience"
- projectId: "ecommerce"

Tool payload

{
  "name": "new-checkout-flow",
  "type": "release",
  "description": "Gradual rollout of the redesigned checkout experience with improved conversion tracking",
  "projectId": "ecommerce",
  "impressionData": true
}

Tool output

On success, the tool returns a JSON object containing the new feature flag’s URL in the Unleash Admin UI, an MCP resource link for programmatic access, creation timestamp, and configuration details.

Evaluate change

The evaluate_change tool evaluates whether a code change should be behind a feature flag. It examines the structure, context, and potential risk of the change and returns a recommendation with an explanation and next steps.

When to use

Use evaluate_change at the beginning of a feature or modification when you want to understand whether the work requires a feature flag. This tool is also helpful when you are unsure which flag type to use or want guidance on rollout planning.

How it works

The tool returns detailed, markdown-formatted guidance for the LLM assistant based on Unleash best practices.

The guidance includes:

• Parent flag detection: Checks if code is already protected by existing flags.
• Risk assessment: Analyzes code patterns to identify risky operations.
• Code type evaluation: Classifies the change (for example, test, config, feature, or bug fix).
• Recommendation: Suggests whether to create a flag, use an existing flag, or skip the flag.
• Next actions: Provides specific instructions on what to do next.

When evaluate_change determines a flag is needed, it provides explicit instructions to:

1. Call create_flag tool to create the feature flag.
2. Call wrap_change tool to get language-specific code wrapping guidance.
3. Implement the wrapped code following the detected patterns.

The evaluation process

The tool follows a clear evaluation process:

Step 1: Gather code changes (git diff, read files)
        ↓
Step 2: Check for parent flags (avoiding nesting)
        ↓
Step 3: Assess code type (test? config? feature?)
        ↓
Step 4: Evaluate risk (auth? payments? API changes?)
        ↓
Step 5: Calculate risk score
        ↓
Step 6: Make recommendation
        ↓
Step 7: Take action (create flag or proceed without)

Risk assessment

The tool uses language-agnostic patterns to score risk:

• Critical risk (Score +5): For example, auth, payments, security, and database operations.
• High risk (Score +3): For example, API changes, external services, or new classes.
• Medium risk (Score +2): For example, async operations or state management.
• Low risk (Score +1): For example, bug fixes, refactors, or small changes.

Parent flag detection

The tool looks for common patterns across languages, such as:

• Conditionals: if (isEnabled('flag')), if client.is_enabled('flag'):
• Assignments: const enabled = useFlag('flag')
• Hooks: const enabled = useFlag('flag') → {enabled && <Component />}
• Guards: if (!isEnabled('flag')) return;
• Wrappers: withFeatureFlag('flag', () => {...})

Parameters

All parameters are optional, but more context leads to better recommendations:

• repository (string): Repository name or path.
• branch (string): Current branch name.
• files (array): List of files being changed.
• description (string): Description of the change.
• riskLevel (enum): low, medium, high, or critical, as assessed by the user.
• codeContext (string): Surrounding code for parent flag detection.

Usage example

Agent prompt

Simple usage where you let the agent gather context:

Use evaluate_change to help me determine if I need a feature flag

Explicit instructions:

Use evaluate_change with:
- description: "Add Stripe payment processing"
- riskLevel: "high"

Tool payload

{
  "repository": "my-app",
  "branch": "feature/stripe-integration",
  "files": ["src/payments/stripe.ts"],
  "description": "Add Stripe payment processing",
  "riskLevel": "high",
  "codeContext": "surrounding code for parent flag detection"
}

Tool output

Returns a JSON object with the evaluation result, including a needsFlag boolean, a recommendation (e.g., “create_new”), a suggested flag name, risk level, and a detailed explanation.

{
  "needsFlag": true,
  "reason": "new_feature",
  "recommendation": "create_new",
  "suggestedFlag": "stripe-payment-integration",
  "riskLevel": "critical",
  "riskScore": 5,
  "explanation": "This change integrates Stripe payments, which is critical risk...",
  "confidence": 0.9
}

Detect flag

The detect_flag tool finds existing feature flags in the codebase so you can reuse them instead of creating duplicates. This tool is automatically integrated into the evaluate_change workflow but can also be used manually.

When to use

Use this tool before creating a new feature flag or during code evaluation to check for existing flags that might already cover your use case. This helps prevent flag duplication.

How it works

The tool returns comprehensive search instructions and uses multiple detection strategies:

• File-based detection: Search in files you’re modifying for existing flags.
• Git history analysis: Look for recently added flags in commit history.
• Semantic name matching: Match descriptions to existing flag names.
• Code context analysis: Inspect code around the change.

The tool then follows a scoring process:

Step 1: Execute file-based search (grep for flag patterns in target files)
        ↓
Step 2: Search git history for recent flag additions
        ↓
Step 3: Perform semantic matching (description → flag names)
        ↓
Step 4: Analyze code context (if provided)
        ↓
Step 5: Combine scores from all methods
        ↓
Step 6: Return best candidate with confidence score

Confidence levels

The tool returns candidates with confidence scores:

• High ≥0.7: Strong match; reuse is recommended.
• Medium 0.4-0.7: Possible match; review manually.
• Low <0.4: Weak match; likely create a new flag.

Parameters

• description (required): Description of the change or feature. For example, "payment processing with Stripe", "new checkout flow".
• files (optional): Files being modified. For example, ["src/payments/stripe.ts", "src/checkout/flow.ts"].
• codeContext (optional): Nearby code to scan for flags.

Usage example

Agent prompt

Check for existing flags before creating a flag:

Use detect_flag with description "payment processing with Stripe"

Integrated automatically in evaluation:

Use evaluate_change - automatically searches for existing flags

Tool payload

{
  "description": "payment processing with Stripe",
  "files": ["src/payments/stripe.ts"]
}

Tool output

Returns a JSON object indicating if a flag was found. If flagFound is true, it includes a candidate object with the flag’s name, location, confidence score, and the reason for the match.

Match found:

{
  "flagFound": true,
  "candidate": {
    "name": "stripe-payment-integration",
    "location": "src/payments/stripe.ts:42",
    "context": "if (client.isEnabled('stripe-payment-integration')) {",
    "confidence": 0.85,
    "reasoning": "Found in same file you're modifying, added 2 days ago",
    "detectionMethod": "file-based"
  }
}

No match found:

{
  "flagFound": false,
  "candidate": null
}

Wrap change

The tool wrap_change generates language-specific code snippets and guidance for wrapping code with feature flags. It helps LLMs and developers follow existing patterns in the codebase and use flags correctly.

When to use

Use this tool after you have created a feature flag (with create_flag) and need to implement it in your code. It’s especially useful when you want to ensure you are following existing codebase patterns or need framework-specific examples (e.g., React, Django).

How it works

This tool is the final step in the evaluate_change → create_flag → wrap_change workflow.

The tool provides the following guidance in its response:

1. Search instructions: Step-by-step guide for finding existing flag patterns in your codebase using grep.
2. Pattern detection: Identifies common patterns (for example, imports, client variable names, method names, or wrapping styles).
3. Default templates: Fallback code snippets if no patterns are found.
4. Framework-specific examples: Specialized patterns for React, Express, Django, and others.
5. Multiple patterns: If-blocks, guard clauses, hooks, decorators, middleware, and more.

Supported languages and frameworks:

• TypeScript/JavaScript: Node.js, React Hooks, Express middleware.
• Python: FastAPI, Django, Flask decorators.
• Go: Standard if-blocks, HTTP middleware.
• Ruby: Rails controllers.
• PHP: Laravel controllers.
• C#: .NET/ASP.NET controllers.
• Java: Spring Boot.
• Rust: Actix/Rocket handlers.

Parameters

• flagName (required): Feature flag name to wrap the code with. For example: "new-checkout-flow", or "stripe-integration".
• language (optional): Programming language (auto-detected from fileName if not provided). Supported: typescript, javascript, python, go, ruby, php, csharp, java, rust
• fileName (optional): File name being modified (helps detect language), For example: "checkout.ts", "payment.py", or "handler.go".
• codeContext (optional): Surrounding code to help detect existing patterns.
• frameworkHint (optional): Framework for specialized templates. For example, "React", "Express", "Django", "Rails", or "Spring Boot".

Usage example

Agent prompt

Use wrap_change with:
- flagName: "new-checkout-flow"
- fileName: "src/components/checkout.ts"
- frameworkHint: "React"

Tool payload

{
  "flagName": "new-checkout-flow",
  "fileName": "checkout.ts",
  "frameworkHint": "React"
}

Tool output

Returns a comprehensive, markdown-formatted string that guides the user on how to wrap their code. This includes a quickstart, search instructions, wrapping instructions with placeholders, all available templates for the language, and links to SDK documentation.

# Feature Flag Wrapping Guide: "new-checkout-flow"
**Language:** TypeScript
**Framework:** React
## Quick Start
[Recommended pattern with import and usage]
## How to Search for Existing Flag Patterns
[Step-by-step Grep instructions]
## How to Wrap Code with Feature Flag
[Wrapping instructions with examples]
## All Available Templates
[If-block, guard clause, hooks, ternary, etc.]

Send feedback

The send_feedback tool shares anonymous diagnostic feedback reports with Unleash to help improve the MCP server. Unleash uses these reports to prioritize fixes and new tools.

You don’t call this tool yourself. The assistant calls it automatically.

When to use

The assistant sends a report before it replies to you in the following cases:

• tool_error: A tool call returns an error.
• unsupported_action: You ask for something the MCP server can’t do yet.
• unexpected_result: A tool call succeeds, but the result isn’t what the assistant expected.

The assistant doesn’t send a report for authentication errors (HTTP 401 or 403), or when send_feedback itself fails.

Consent

The local MCP server sends feedback reports only after you opt in. The first time the assistant calls send_feedback, your client shows a consent prompt. What happens next depends on your response:

• You accept: The MCP server sends the report and saves that you opted in. You don’t see the prompt again.
• You decline: The MCP server doesn’t send the report and saves that you opted out. You don’t see the prompt again.
• You cancel or don’t respond within 60 seconds: The MCP server doesn’t send the report and doesn’t save anything. You see the prompt again in your next session.

In some clients, you don’t see the consent prompt. See Clients without a consent prompt.

The MCP server saves whether you opted in or out in a file named feedback_consent.json. All clients on your machine that show the consent prompt read this file, so you respond to the prompt only once. The file is in your platform’s configuration directory:

~/Library/Application Support/unleash-mcp/feedback_consent.json

To store the file in a different directory, set UNLEASH_MCP_CONFIG_DIR. To see the prompt again, delete the file.

To skip the prompt, set UNLEASH_MCP_SEND_FEEDBACK to true or false. The variable takes precedence over feedback_consent.json. With false, the assistant doesn’t see the send_feedback tool. Use the variable for CI and for centrally managed MCP configuration.

The remote MCP server doesn’t show a consent prompt. Instead, an admin turns feedback reports on or off for the whole instance. See Feedback from the remote server.

Clients without a consent prompt

In the following clients, you don’t see the consent prompt. To opt in or out, set UNLEASH_MCP_SEND_FEEDBACK to true or false.

What is recorded

Each report contains only the following fields:

• Issue type, tool name, and normalized error code
• MCP server version, client name, and client version
• A short summary that the assistant writes

The tool name and error code follow a fixed format, so they can’t contain free text. The assistant is instructed to leave flag names, project IDs, code, URLs, and tokens out of the summary. Reports never include raw error messages or your personal access token.

By default, reports go to Unleash, not to your Unleash instance. To send them to your own endpoint instead, see Send reports to your own endpoint. See also Data and privacy.

Send reports to your own endpoint

To collect feedback reports yourself instead of sending them to Unleash, set UNLEASH_FEEDBACK_URL to the base URL of your endpoint, for example https://feedback.example.com. The URL must start with http:// or https://.

The MCP server then sends each report as a POST request to {UNLEASH_FEEDBACK_URL}/feedback with a JSON body. The areasForImprovement field holds the report fields from What is recorded as a JSON-encoded string:

{
  "category": "mcp",
  "userType": null,
  "difficultyScore": null,
  "positive": null,
  "areasForImprovement": "{\"issueType\":\"tool_error\",\"summary\":\"Setting the rollout failed with a server error.\",\"tool\":\"set_flag_rollout\",\"errorCode\":\"HTTP_500\",\"mcpVersion\":\"0.5.0\",\"client\":\"claude-code\",\"clientVersion\":\"2.1.80\"}"
}

Reports sent to your own endpoint don’t reach Unleash. Consent works the same way: the MCP server sends reports only after you opt in.

Parameters

• issueType (required): tool_error, unsupported_action, or unexpected_result.
• summary (required): One or two sentences describing what went wrong or what was requested (maximum 500 characters).
• tool (optional): Name of the MCP tool involved, for example create_flag. Omit for unsupported requests.
• errorCode (optional): Normalized error code from the failed tool result, for example HTTP_500 or VALIDATION_ERROR.

Output

Returns a confirmation that the report was sent, or would be sent in --dry-run mode. If you haven’t opted in, returns a message that feedback is disabled. The structured content includes success, sent, dryRun, and message. If the MCP server can’t save whether you opted in or out to feedback_consent.json, the result also includes a warning. In that case, your choice applies to the current session only, and you see the prompt again in your next session.

Architecture

The server follows a focused, purpose-driven design:

• Thin surface area: Only the endpoints needed for the core capabilities.
• Purpose-driven: Each module serves a specific, well-defined purpose.
• Explicit validation: Zod schemas validate all inputs before API calls.
• Error normalization: All errors converted to {code, message, hint} format.
• Progress streaming: Long-running operations provide visibility.
• Best practices integration: Guidance from Unleash docs embedded in tool descriptions.
• Opt-in feedback: The local server sends feedback reports only after you opt in, and each report contains a fixed set of fields.

Configuration

This section provides a quick reference for all configuration options.

Environment variables:

• UNLEASH_BASE_URL: Your Unleash instance URL (required).
• UNLEASH_PAT: Personal access token (required).
• UNLEASH_DEFAULT_PROJECT: The default project ID the MCP should use (optional).
• UNLEASH_MCP_SEND_FEEDBACK: Set to true or false to opt in to or out of feedback reports without a consent prompt (optional). Takes precedence over feedback_consent.json. With false, the assistant doesn’t see the send_feedback tool.
• UNLEASH_FEEDBACK_URL: Base URL of your own endpoint for feedback reports (optional). By default, reports go to Unleash. See Send reports to your own endpoint.
• UNLEASH_MCP_CONFIG_DIR: Directory for feedback_consent.json (optional). Defaults to your platform’s configuration directory. See Consent.

CLI flags:

• --dry-run: Simulate operations without making actual API calls.
• --log-level: Set logging verbosity (debug, info, warn, error).

Protect production environments

AI assistants can make mistakes and toggle the wrong flag. When change requests are enabled for an environment, the MCP server submits a change request instead of applying the change directly. A human must approve the request before it takes effect, preventing accidental changes whether made manually or by an AI assistant.

Enable change requests on any environment where unreviewed changes pose a risk, especially production. For configuration steps, see change requests.

Best practices

This server encourages Unleash best practices from the official documentation:

Flag lifecycle

1. Create with intent: Choose the right flag type to signal purpose.
2. Document clearly: Write descriptions that explain the “why”.
3. Plan for cleanup: Feature flags are temporary; plan their removal.
4. Monitor usage: Enable impression data for important flags.

Flag types

• Release flags: For gradual feature rollouts (remove after full rollout).
• Experiment flags: For A/B tests (remove after analysis).
• Operational flags: For system behavior (longer-lived, review periodically).
• Kill switches: For emergency controls (maintain until feature is stable).
• Permission flags: For access control (longer-lived, review permissions).
• Sunset flags: For planned feature removal.

Naming conventions

• Use kebab-case: new-checkout-flow
• Be descriptive: enable-ai-recommendations not flag1.
• Include scope when needed: mobile-push-notifications.

API reference

This server uses the Unleash Admin API. For complete API documentation, see:

• Unleash Admin API OpenAPI Spec
• Unleash API Documentation

Endpoints used

• POST /api/admin/projects/{projectId}/features - Create feature flag

send_feedback doesn’t call your Unleash instance. It sends reports to Unleash, or to POST {UNLEASH_FEEDBACK_URL}/feedback if you set your own endpoint.

Troubleshooting

Configuration issues

Error: “UNLEASH_BASE_URL must be a valid URL”: Ensure your base URL is complete, including protocol. For example, https://app.unleash-hosted.com/instance. Remove any trailing slashes.

Error: “UNLEASH_PAT is required”: Check that your .env file exists and contains UNLEASH_PAT={{your-personal-access-token}}. Verify that the token is valid in Unleash.

API issues

Error: “HTTP_401”: Your personal access token may be invalid or expired. Generate a new token under Profile > View Profile settings > Personal API tokens > New token.

Error: “HTTP_403”: Your token doesn’t have permission to create flags in this project. Review your role and permissions in Unleash.

Error: “HTTP_404”: The project ID doesn’t exist. Confirm the project ID in Unleash Admin UI.

Error: “HTTP_409”: A flag with this name already exists in the project. Use a different name or reuse the existing flag.

Feedback issues

“Feedback is disabled”: You declined the consent prompt, your client couldn’t show it, or UNLEASH_MCP_SEND_FEEDBACK is set to false. To opt in, set UNLEASH_MCP_SEND_FEEDBACK=true. To see the prompt again, delete feedback_consent.json. See Consent.

Error: “Failed to connect to the Unleash feedback endpoint”: The MCP server can’t reach the address that receives feedback reports. Check your network connection. If you set UNLEASH_FEEDBACK_URL, check that the URL is correct. Flag operations aren’t affected.

License

MIT

Contributing

This is a purpose-driven project with a focused scope. Contributions should:

• Align with the three core use cases (evaluate and wrap code in feature flags, manage rollouts, clean up after rollout).
• Maintain the thin, purpose-driven architecture.
• Follow Unleash best practices.
• Include clear documentation.