The Unleash MCP server lets AI agents manage Unleash feature flags, rollouts, and flag-related code changes.
Discover and inspect projects, flags, and flag state, including active vs archived inventories.
Create feature flags with a type, description, project, and impression data.
Evaluate whether a code change needs a flag, detect existing flags, and get wrapping/cleanup guidance for many languages.
Configure rollout strategies and variants, enable/disable flags per environment, and remove strategies.
Run broader Unleash workflows described in the README: search, evaluate, release, kill switches, experiments, manage/configure, audit, docs, and feedback.
It does not delete flags; it can archive/revive them, remove strategies, or guide code cleanup.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Unleash MCP Server create a new feature flag for the dark mode rollout"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets AI agents work with Unleash the way you'd work in the Unleash UI: find flags, roll them out, check who gets them, and see what changed. It's in alpha and isn't published to npm, so you run it from source.
Tool | Description | Example prompt |
| Find projects, flags, segments, context fields, tags, tag types, flag creators, release templates, event types and environments by name. | "Which flags in the checkout project are tagged team:payments?" |
| Read a project, flag, context field or segment in full. | "Show me everything about the new-checkout flag." |
| Tell whether a flag is enabled, disabled or unknown for a context in an environment. | "Does user 42 get new-checkout in production?" |
| Turn a flag on for audiences, split by value or through a release template, or turn it off. Creates the flag if it doesn't exist. Opens a change request where the environment requires one. | "Roll out new-checkout to 10% of users in production." |
| Turn a permanent kill switch on or off, for everyone or chosen audiences. Creates the switch if it doesn't exist. Opens a change request where the environment requires one. | "Turn off payments in production." |
| Run an A/B test: give audiences values such as control and treatment, by share or one each, or stop it. Creates a missing flag. Opens a change request where the environment requires one. | "Split checkout 50/50 between control and the new flow." |
| Define flags, set a parent dependency, mark flags completed, archive and revive them. Doesn't delete flags. | "Archive the old-banner flag." |
| Change context fields and their legal values, segments, tag types and tags, release templates and projects. | "Create a beta-testers segment for userId 1, 2 and 3." |
| Read what changed, who changed it and when, over at most 31 days. | "What changed in production yesterday?" |
| Answer questions about feature flag practices and Unleash itself from the current Unleash documentation. | "How should I clean up old flags?" |
| Report to Unleash where the server fell short. Asks you first, unless | None: the agent calls it on its own. |
Related MCP server: OpenFeature MCP Server
You need Node 24 or later and pnpm.
Clone the repository and switch to the v2 branch:
git clone https://github.com/Unleash/unleash-mcp.git
cd unleash-mcp
git checkout v2This gets you the v2 source.
Install the dependencies:
pnpm installNode runs the TypeScript source directly, so there's no build step.
In Unleash, create a personal access token under Profile > Personal API tokens. The server acts with that user's permissions.
Register the server with your MCP client. For Claude Code:
claude mcp add unleash \
-e UNLEASH_BASE_URL=https://your-instance.getunleash.io \
-e UNLEASH_PAT=user:your-personal-access-token \
-- node /absolute/path/to/unleash-mcp/src/index.tsThis adds a stdio server named unleash to Claude Code. For clients configured with JSON, such as Claude Desktop, Cursor or VS Code, add this to their MCP servers:
{
"mcpServers": {
"unleash": {
"command": "node",
"args": ["/absolute/path/to/unleash-mcp/src/index.ts"],
"env": {
"UNLEASH_BASE_URL": "https://your-instance.getunleash.io",
"UNLEASH_PAT": "user:your-personal-access-token"
}
}
}
}Ask your agent "List my Unleash projects". If it answers with your projects, the server is running.
Variable | Required | Description |
| Yes | URL of your Unleash instance, such as |
| Yes | Personal access token the server calls Unleash with. |
| No |
|
| No | Unleash instance that receives |
| No | Directory that keeps your answer, |
send_feedback sends anonymous reports to Unleash when the server fell short: a tool error, a request no tool supports, or a wrong result. A report names the tool, the error and the MCP client the agent runs in. Say yes to help us fix what doesn't work for you.
Nothing is sent until you agree. The first report asks you through your MCP client, and your answer is kept in feedback_consent.json, so you're asked once. The file sits in an unleash-mcp directory under $XDG_CONFIG_HOME when it's set, otherwise under ~/Library/Application Support on macOS, %APPDATA% on Windows and ~/.config on Linux. Delete it to be asked again.
If you dismiss the question, or your client can't show it, feedback stays off until the next session. OpenCode, Gemini and Antigravity never show it, so there feedback stays off unless UNLEASH_MCP_SEND_FEEDBACK is true.
To keep secrets out of your client config, copy .env.example to .env, fill it in, and start the server with node --env-file=.env /absolute/path/to/unleash-mcp/src/index.ts.
Unleash Enterprise hosts this server, over Streamable HTTP, so nothing runs on your machine. An admin turns it on under Admin > Remote MCP Server; send_feedback reports are sent unless the admin turns them off there.
Register the server with your MCP client. For Claude Code:
claude mcp add unleash https://your-instance.getunleash.io/api/admin/mcp --transport httpFor Codex, add the server and then log in:
codex mcp add unleash --url https://your-instance.getunleash.io/api/admin/mcp
codex mcp login unleashThe login opens your browser to log in to Unleash; Claude Code does the same on first use. Unleash then creates a personal access token for the client, valid for 24 hours, and the server acts with your permissions.
Where a browser login isn't possible, such as in CI, send a personal access token of your own instead and no login happens:
claude mcp add unleash https://your-instance.getunleash.io/api/admin/mcp \
--transport http \
--header "Authorization: Bearer user:your-personal-access-token"Codex takes the token from an environment variable named in its config.toml, as bearer_token_env_var under [mcp_servers.unleash].
Development setup: running tests and the dev server in Claude Code.
Decisions: why the server works the way it does.
Remove a feature flag from the codebase while preserving the desired code path.
This tool provides comprehensive step-by-step instructions for safely removing feature flag code. It guides you through:
Finding all flag occurrences using Grep
Identifying different flag usage patterns (if-else, ternary, guards, etc.)
Removing flag checks while preserving the correct code path
Cleaning up unused imports and dead code
Verifying and testing the changes
When to use this tool:
After a feature flag has been rolled out to 100% and is no longer needed
When deprecating an experimental feature (preserve disabled path)
When cleaning up technical debt from old flags
After a kill switch is no longer necessary
Preserve Path Options:
"enabled": Keep code that runs when flag is true (most common for successful feature rollouts)
"disabled": Keep code that runs when flag is false (for removed experiments or kill switches)
If not provided: You will be instructed to ask the user which path to preserve
Workflow:
Call this tool with the flag name (optionally specify which path to preserve)
If preservePath not provided, you'll be instructed to ask the user via AskUserQuestion tool
Follow the returned instructions to search and remove flag code
Clean up imports and test the changes
Report summary of changes
Safety Features:
Comprehensive pattern identification (handles if-else, ternary, guards, etc.)
Language-agnostic guidance
Post-cleanup verification steps
Test execution reminders
Import cleanup guidance
This tool is inspired by the Unleash AI flag cleanup workflow used in production. See: https://github.com/Unleash/unleash/blob/main/.github/workflows/ai-flag-cleanup-pr.yml
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Optional: Specific files to clean up. If not provided, searches entire codebase. Useful for partial cleanup or when you already know which files contain the flag. | |
| flagName | Yes | Name of the feature flag to remove (e.g., "new-checkout-flow") | |
| language | No | Optional: Programming language for specialized guidance (e.g., "typescript", "python", "go"). Auto-detected from files if not provided. | |
| preservePath | No | Optional: Which code path to preserve: "enabled" = keep code that runs when flag is true (typical for rollouts), "disabled" = keep code that runs when flag is false (for removed features). If not provided, you will be instructed to ask the user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details the workflow: returns step-by-step instructions, may ask user if preservePath not provided, handles multiple patterns, and includes safety features. It also mentions it is language-agnostic and provides verification steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured with clear sections (workflow, safety features, preserve path options). It is front-loaded with the core purpose. Minor verbosity exists (e.g., link to workflow inspiration), but overall earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description is remarkably complete. It covers when to use each parameter, workflow steps, safety measures, and post-cleanup tasks. No gaps remain for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters described). The description adds significant value beyond the schema: explains preservePath options and consequences, clarifies optionality of files and language, and gives example for flagName. Baseline is 3, but additional context justifies 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states precisely: 'Remove a feature flag from the codebase while preserving the desired code path.' This specific verb+resource clearly distinguishes it from sibling tools like create_flag, detect_flag, and toggle_flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'When to use this tool' section listing concrete scenarios (e.g., after flag rollout to 100%, deprecating experimental features). While it does not explicitly say when NOT to use, the scenarios are specific and complement sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new feature flag in Unleash.
This tool creates a feature flag with the specified configuration. Choose the appropriate flag type:
release: For gradual feature rollouts to users
experiment: For A/B tests and experiments
operational: For system behavior and operational toggles
kill-switch: For emergency shutdowns or circuit breakers
permission: For role-based access control
Best practices:
Use clear, descriptive names (e.g., "new-checkout-flow" not "flag1")
Write comprehensive descriptions explaining the flag's purpose
Choose the right type to signal intent and lifecycle
Plan for flag removal after successful rollout
See: https://docs.getunleash.io/topics/feature-flags/best-practices-using-feature-flags-at-scale
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Feature flag name (must be unique within the project). Use descriptive names like "new-checkout-flow" | |
| type | Yes | Feature flag type - determines the lifecycle and usage pattern | |
| projectId | No | Project ID where the flag will be created (optional if UNLEASH_DEFAULT_PROJECT is set) | |
| description | Yes | Clear description of what this flag controls, why it exists, and when it should be removed | |
| impressionData | No | Enable impression data collection for analytics (optional, defaults to false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden. It explains the creation action and flag types but lacks disclosure of side effects, error handling, or prerequisites like permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and bullet points. It is front-loaded with the core purpose. However, it includes an external link and some redundancy in the best practices list, which could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the creation of flags with type guidance and best practices. Lacks explanation of the return value or confirmation behavior, but for a creation tool it is fairly complete given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context for flag types and best practices, which complements the schema but does not significantly enhance parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new feature flag in Unleash, and lists distinct flag types with their specific purposes. It effectively distinguishes from sibling tools like cleanup_flag or detect_flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on when to use each flag type and best practices. However, it does not explicitly state when not to use this tool compared to alternatives, missing some usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover existing feature flags in the codebase to prevent duplicates and encourage reuse.
This tool provides comprehensive search instructions for finding existing flags through multiple detection strategies:
File-based detection: Search in files being modified
Git history analysis: Find recently added flags
Semantic name matching: Match description to flag names
Code context analysis: Find flags near modification point
Use this tool when:
About to create a new feature flag
Evaluating whether a flag is needed
Want to check if similar functionality is already flagged
The tool returns detailed search instructions that guide you through:
Executing searches using Bash and Grep tools
Scoring candidates from multiple detection methods
Combining results to find the best match
Returning a confidence-scored recommendation
Workflow Integration: This tool is automatically called by 'evaluate_change' before recommending 'create_flag'. You can also call it directly when you want to search for existing flags.
Output: Returns markdown guidance with:
Step-by-step search instructions for each detection method
Scoring criteria and weight calculations
Expected JSON response format
Confidence level interpretation
After following the instructions and finding results, you should return a JSON object indicating whether a flag was found and, if so, its details with a confidence score.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Optional: List of files being modified to search for flags in the same area | |
| codeContext | No | Optional: Code context around the modification point to analyze for nearby flags | |
| description | Yes | Description of the change or feature you want to find flags for (e.g., "payment processing with Stripe") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses that the tool returns search instructions, not actual flags. It explains the multi-step process, output format, and expected user actions, making behavioral expectations completely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, strategies, usage, workflow, and output. It is somewhat verbose but every section adds value, and the front-loading of purpose is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides complete guidance: explains the tool's meta-nature, return format (markdown instructions), workflow steps, and expected final output format. It covers all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for all three parameters. The tool description adds context by relating parameters to detection strategies (e.g., files to file-based detection), enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers existing feature flags to prevent duplicates and encourage reuse, listing specific detection strategies. It distinguishes itself from sibling tools like create_flag and list_flags by describing its role as a discovery tool before creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: when about to create a new flag, evaluating necessity, or checking for similar functionality. Also mentions it's automatically called by evaluate_change before create_flag, providing clear workflow integration context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides comprehensive guidance for evaluating whether code changes require feature flags.
This tool returns detailed evaluation guidelines including:
Workflow for systematic evaluation
Parent flag detection patterns (avoid nesting)
Risk assessment criteria
Code type evaluation (test, config, feature, etc.)
Decision tree logic
Best practices from Unleash documentation
MANDATORY next action instructions: Explicit tool call sequence (create_flag → wrap_change → implement)
Use this tool when:
Starting work on a new feature or change
Unsure if a feature flag is needed
Want guidance on rollout strategy
Need help choosing flag type
IMPORTANT WORKFLOW: When this tool determines a flag is needed, it provides explicit instructions to:
Call 'create_flag' tool to create the feature flag in Unleash
Call 'wrap_change' tool to get code wrapping guidance
Implement the wrapped code following the patterns
The tool returns markdown-formatted guidance that helps you make informed decisions and take the correct next actions.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | List of files changed (optional) | |
| branch | No | Current branch name (optional) | |
| riskLevel | No | User-assessed risk level (optional) | |
| repository | No | Repository name or path (optional) | |
| codeContext | No | Surrounding code context for parent flag detection (optional) | |
| description | No | Description of the change (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns markdown-formatted guidance and gives mandatory next actions. However, it does not explicitly state that the tool is read-only or has no side effects, which is typical for a consultative tool. Missing safety/permission context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections using bullet points and bold text. It front-loads the purpose and key workflow steps. While thorough, it could be slightly more concise by trimming redundant phrases, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an evaluation tool with multiple decision factors and no output schema, the description is fairly complete. It explains what the tool returns, when to use it, and the subsequent workflow. It could benefit from a brief example of the output format, but it sufficiently covers the agent's needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description in the schema. The tool description does not add additional meaning or examples for individual parameters beyond what the schema already provides. Hence, it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides comprehensive guidance for evaluating whether code changes require feature flags. It lists specific outputs (workflow, patterns, criteria, decision tree) and distinguishes itself from sibling tools like create_flag or wrap_change by focusing on evaluation and then directing to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool (starting a feature, unsure about flag need, need rollout guidance, choosing flag type) and includes a mandatory workflow instructing subsequent tool calls. However, it does not mention when not to use it, such as when a flag is already confirmed unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current feature flag metadata and environment strategies from the Unleash Admin API.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project ID where the feature flag resides (optional if UNLEASH_DEFAULT_PROJECT is set) | |
| environment | No | Optional environment filter (case-insensitive) | |
| featureName | Yes | Feature flag name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states 'Fetch' without detailing side effects, permissions, rate limits, or output format. Lacks depth for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant information, front-loaded key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet description only vaguely mentions 'metadata and environment strategies'. Missing details on return format, pagination, error handling, or data structure. Incomplete for a fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters (100% coverage), so description adds minimal extra meaning. Mentions what is fetched but does not elaborate on parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses clear verb 'Fetch' and specifies resource 'feature flag metadata and environment strategies' from a known API, distinguishing it from sibling tools that create, delete, or toggle flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like evaluate_change or toggle_flag_environment. Context only implied by the read verb, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List feature flags in an Unleash project, with optional pagination and sort order. By default returns active flags only; set archived=true to list archived flags instead (active and archived flags are disjoint result sets in Unleash and cannot be combined in one response). Use this to discover flags before creating new ones, audit flag inventory for cleanup (call twice — once for active, once for archived), or scope a workflow to a specific project. Returns name, type, description, archived status, and URL for each flag.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of flags to return per page (default: server page size, typically 50) | |
| order | No | Sort order by flag name (default: asc) | |
| offset | No | Number of flags to skip for pagination (default: 0) | |
| archived | No | Set to true to list archived flags instead of active ones. Defaults to false (active flags only). Active and archived flags cannot be returned in the same response — call this tool twice (once with archived=false, once with archived=true) to assemble a full inventory for audit workflows. | |
| projectId | No | Project ID to list flags from (optional if UNLEASH_DEFAULT_PROJECT is set; auto-resolved when a single project exists) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the disjoint nature of active/archived, pagination support, and return fields (name, type, description, archived status, URL). Lacks depth on error behavior or authentication, but covers key behavioral traits for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, no wasted words. Front-loaded with purpose, followed by key behavioral notes, usage examples, and return fields. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description adequately explains pagination, sort, and the active/archived split. It lists return fields. Minor gaps: no mention of error states or rate limits, but core completeness is strong for a read-only list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—all parameters have detailed descriptions in the schema. The tool description adds no additional parameter-level semantics beyond restating the active/archived nuance already present in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'List feature flags in an Unleash project'—a specific verb and resource. It clearly distinguishes from siblings like create_flag or cleanup_flag by stating its role as a discovery/inventory tool. The name and task are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'discover flags before creating new ones, audit flag inventory for cleanup...' It also explains the need to call twice for active and archived, and notes that they are disjoint—this serves as a when-not-to-use guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Unleash projects available to the configured token, with optional pagination. Use this for discovery before scoping flag operations to a specific project. Returns project id, name, description, mode, creation time, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of projects to return per page (default: server page size, typically 20) | |
| order | No | Sort order by project creation time (default: desc, newest first) | |
| offset | No | Number of projects to skip for pagination (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool lists projects available to the token (implying auth), optionally supports pagination, and returns specific fields. However, it does not discuss rate limits, idempotency, or other behavioral details beyond what is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a distinct purpose: stating the operation and providing usage guidance. No superfluous words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the fields returned. Parameters are well-documented in the schema. The tool is simple (list projects) and the description covers purpose, usage context, auth, and output. It is complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds minimal extra meaning beyond the schema—it mentions 'optional pagination' which aligns with limit/offset, and lists return fields. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List'), resource ('Unleash projects'), and context ('available to the configured token'), with optional pagination. It distinguishes itself from sibling flag tools by focusing on projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool for 'discovery before scoping flag operations to a specific project,' providing clear context. It does not mention when not to use it or alternative tools, but the sibling list consists entirely of flag-related tools, making its role clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a strategy configuration from a feature flag environment. Use get_flag_state to discover strategy IDs before removal.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project ID where the feature flag resides (optional if UNLEASH_DEFAULT_PROJECT is set) | |
| strategyId | Yes | ID of the strategy to remove | |
| environment | Yes | Environment from which to remove the strategy | |
| featureName | Yes | Feature flag name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Delete' without indicating permissions, irreversibility, or side effects on the feature flag. The description lacks important behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the main purpose, second provides a critical usage hint. No redundant or unnecessary information, making the description efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and a key prerequisite, which is adequate for a simple 4-parameter tool. However, it omits any mention of return values (no output schema) and behavioral details like destructive nature beyond the verb 'Delete'. Completeness is functional but not enriched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters. The description adds no additional parameter meaning beyond what the schema provides. It references get_flag_state for strategy IDs but does not elaborate on parameter usage. Baseline score of 3 is appropriate given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Delete a strategy configuration from a feature flag environment' with a specific verb and resource. The mention of using get_flag_state to discover IDs distinguishes related tools and provides context for when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use get_flag_state to discover strategy IDs before removal, which is a clear prerequisite. However, it does not specify when not to use this tool or alternative approaches, but the context is well-provided for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure or update a flexibleRollout strategy for a feature flag environment with an optional rollout percentage and variants. This does NOT enable the feature; call toggle_flag_environment to turn environments on or off.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Optional descriptive title for the strategy | |
| groupId | No | Group ID for stickiness bucketing (defaults to the feature name) | |
| disabled | No | Disable the strategy (defaults to false) | |
| variants | No | Optional list of strategy-level variants | |
| projectId | No | Project ID where the feature flag resides (optional if UNLEASH_DEFAULT_PROJECT is set) | |
| stickiness | No | Stickiness field (defaults to "default") | |
| environment | Yes | Target environment | |
| featureName | Yes | Feature flag name | |
| rolloutPercentage | Yes | Rollout percentage (0-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a mutation (configures/updates) and clarifies non-enablement. However, it omits details on whether the strategy is replaced or merged, permission requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential: first states the core action, second clarifies a key constraint. No unnecessary words. Excellent front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description is too brief. It does not explain how variants are used, what constitutes a 'flexibleRollout strategy', or return behavior. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description inaccurately describes rolloutPercentage as 'optional' when it is required in the schema. This misstatement could mislead AI agents. The description adds no other significant parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action as configuring/updating a flexibleRollout strategy for a feature flag environment. It also explicitly states what it does NOT do (enable the feature), which distinguishes it from sibling tools like toggle_flag_environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use (for enabling features) and directs users to toggle_flag_environment instead. However, it does not address other use cases or alternatives among siblings like remove_flag_strategy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable a feature flag in a specific environment using the Unleash Admin API. For gradual rollouts, configure a flexibleRollout strategy first via set_flag_rollout.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | Set to true to enable the flag, or false to disable it | |
| projectId | No | Project ID where the feature flag resides (optional if UNLEASH_DEFAULT_PROJECT is set) | |
| environment | Yes | Environment to toggle | |
| featureName | Yes | Feature flag name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully cover behavior. It mentions using the Unleash Admin API and the toggle action, but does not discuss side effects, idempotency, permissions, or rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first defines the core purpose, the second provides key usage guidance. No redundancy, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; the description does not explain return values or error handling. While basic usage is covered, agents lack information on what to expect after invocation, which is important for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter details are already provided. The description reiterates enabling/disabling but adds little new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'enable or disable' and the resource 'feature flag in a specific environment', providing a specific action on a distinct resource. It distinguishes from sibling tools by referencing set_flag_rollout for gradual rollouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when not to use this tool (for gradual rollouts, use set_flag_rollout). It implies the appropriate use case (simple enable/disable), though it could explicitly state 'use for toggling entire environment'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate code snippets and guidance for wrapping changes with feature flags.
⚠️ CRITICAL: This tool enforces RUNTIME-CONTROLLABLE feature flags. You MUST place flag checks INSIDE execution paths (handlers, functions), NOT wrapping route registrations, middleware mounting, or controller registration.
This tool provides language-specific templates and instructions for protecting code changes with feature flags. It helps you:
Find existing feature flag patterns in your codebase
Match detected conventions (imports, method names, wrapping styles)
Generate appropriate code snippets for your language/framework
Follow Unleash SDK best practices
Ensure flags are runtime controllable (toggle without redeploy)
Supported languages:
TypeScript/JavaScript (Node, React, Vue, Angular)
Python (FastAPI, Django, Flask)
Go
Ruby (Rails)
PHP
C# (.NET)
Java (Spring Boot)
Rust
The tool uses a prompt-based approach: it provides detailed instructions for searching your codebase for existing patterns and matching their conventions. If no patterns are found, it provides sensible defaults based on Unleash SDK documentation.
Usage:
Call this tool with the flag name after creating a flag
Follow the search instructions to find existing patterns
Use the recommended template or match detected patterns
Test your implementation
Best suited for use after evaluate_change recommends a flag and create_flag creates it.
| Name | Required | Description | Default |
|---|---|---|---|
| fileName | No | File name being modified (helps detect language, e.g., "checkout.ts") | |
| flagName | Yes | Feature flag name to wrap the code with (e.g., "new-checkout-flow") | |
| language | No | Programming language (optional, auto-detected from fileName). Supported: typescript, javascript, python, go, ruby, php, csharp, java, rust | |
| codeContext | No | Optional: surrounding code to help detect existing patterns | |
| frameworkHint | No | Optional: framework hint for specialized templates (React, Express, Django, Rails, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool provides language-specific templates, searches for patterns, and uses a prompt-based approach. However, it doesn't detail side effects, limitations, or whether external calls are made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with sections and bullet points. Some redundancy exists, but it is efficiently organized for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fails to explain what the tool returns (e.g., code snippets, instructions). This is a significant gap, as the agent needs to know how to use the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have basic descriptions. The description adds operational context (e.g., language auto-detection from fileName) but doesn't significantly enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates code snippets and guidance for wrapping changes with feature flags, a specific action on a specific resource. It distinguishes from sibling tools like create_flag and detect_flag by focusing on the wrapping process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage steps and a critical warning about flag placement. It also advises when to use this tool in the workflow (after evaluate_change and create_flag). However, it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0cleanup_flagcreate_flagdetect_flagevaluate_changeget_flag_statelist_flagslist_projectsremove_flag_strategyset_flag_rollouttoggle_flag_environmentwrap_changeScored across 11 tools
Each tool serves a unique and clearly defined purpose in the feature flag lifecycle (creation, evaluation, detection, state, listing, strategy, toggling, cleanup, wrapping), with no overlapping functionality.
All tool names follow a consistent verb_noun snake_case pattern (e.g., cleanup_flag, create_flag, toggle_flag_environment), making predictions easy.
With 11 tools, the server covers the full lifecycle of feature flag management without being bloated; each tool is justified and valuable.
Covers almost all aspects: evaluation, detection, creation, state, listing, rollout, toggling, strategy removal, code wrapping, and cleanup. Missing explicit flag deletion from the admin API, but cleanup may subsume that.
Evaluate and inspect your Hypertune feature flags from your AI assistant.
Connect AI agents to CloudBees Unify: feature flags, CI/CD, release orchestration, and security
Run accessibility, contrast, and design token audits and file QA issues from your AI coding tool.
Manage ConfigDirector feature flags, remote configs, and targeting rules from AI assistants.
