Skip to main content
The Feature Flags Plugin gates tools, resources, prompts, and skills based on feature flag evaluation — enabling progressive rollouts, A/B testing, and dynamic capability management for FrontMCP servers.

Why Use Feature Flags?

Declarative Gating

Annotate capabilities with featureFlag metadata — no conditional logic in your tool code

Multiple Providers

Split.io, LaunchDarkly, Unleash, static flags, or your own custom adapter

Per-User Targeting

Evaluate flags per user or session via auth context for targeted rollouts

Execution Gate

Blocks direct tool/call invocations that bypass the list filter — no sneaking past disabled flags

Installation

How It Works

1

Hook Registration

The plugin registers hooks on list flows for tools, resources, prompts, and skills
2

Metadata Collection

When capabilities are listed, the plugin collects featureFlag refs from each entry’s metadata
3

Batch Evaluation

Flags are batch-evaluated via the configured adapter in a single call
4

Capability Filtering

Capabilities with disabled flags are filtered out before reaching the client. An execution gate also blocks direct tool/call for disabled flags.

Quick Start

Basic Setup

Annotating a Tool

Programmatic Flag Checks

The plugin extends all execution contexts with this.featureFlags:

Adapters

Static

Best for: Development, testing, and demos with fixed flag values.

Split.io

Requires the @splitsoftware/splitio peer dependency:

LaunchDarkly

Requires the @launchdarkly/node-server-sdk peer dependency:

Unleash

Requires the unleash-client peer dependency:

Custom

Provide your own adapter implementing the FeatureFlagAdapter interface:
The FeatureFlagAdapter interface:

Annotating Capabilities

Add featureFlag to any tool, resource, prompt, or skill metadata. Capabilities with disabled flags are hidden from list responses and blocked from direct invocation.

String Shorthand

Object Form

Use the object form to specify a defaultValue — the fallback when the adapter throws or the flag is unknown:

FeatureFlagRef Fields

When using the string shorthand (featureFlag: 'key'), defaultValue is false.

Plugin Options

'static' | 'splitio' | 'launchdarkly' | 'unleash' | 'custom'
required
The feature flag provider to use
Record<string, boolean | FeatureFlagVariant>
Static flag values (only used with adapter: 'static')
object
Provider-specific configuration (varies by adapter):
  • Split.io: { apiKey: string }
  • LaunchDarkly: { sdkKey: string }
  • Unleash: { url: string, appName: string, apiKey?: string }
FeatureFlagAdapter
Custom adapter instance (only used with adapter: 'custom')
boolean
default:"false"
Global fallback when the adapter throws an error during evaluation
'session' | 'request' | 'none'
default:"'none'"
How to cache flag evaluation results:
  • session — cache per session, expires after cacheTtlMs
  • request — cache per request lifecycle
  • none — no caching, evaluate every time
number
default:"30000"
Cache TTL in milliseconds (used with cacheStrategy: 'session')
(ctx: FrontMcpContext) => string | undefined
Custom function to extract the user ID from the request context. By default, the plugin reads authInfo.extra.sub, authInfo.extra.userId, or authInfo.clientId.
(ctx: FrontMcpContext) => Record<string, unknown>
Custom function to extract targeting attributes from the request context. Attributes are passed to the adapter for per-user targeting rules.

API Reference

FeatureFlagAccessor Methods

Access via this.featureFlags in any execution context (ToolContext, AgentContext, etc.).
Promise<boolean>
Check if a feature flag is enabled. Uses caching if configured.
Promise<FeatureFlagVariant>
Get the variant for a multi-variate flag
Promise<Map<string, boolean>>
Batch evaluate multiple flags at once
Promise<boolean>
Resolve a FeatureFlagRef (string or object) to a boolean

Best Practices

The static adapter requires no external dependencies and gives you instant, predictable flag values during development. Switch to a real adapter (Split.io, LaunchDarkly, Unleash) for staging and production.
When the adapter throws (network error, service down), defaultValue controls whether the flag is treated as enabled or disabled. Set it globally or per-flag:
External adapters involve network calls. Use cacheStrategy: 'session' to avoid repeated evaluations:
For features that should remain available even when the flag service is down, use the object form with defaultValue: true:
This ensures the tool stays available if the adapter throws.

Complete Example


Source Code

View the feature flags plugin source code

Plugin Guide

Learn more about FrontMCP plugins

Remember Plugin

For session memory storage

Approval Plugin

For tool authorization workflows