Skip to main content
Glama
Sign In
GrowthBook MCP Server

GrowthBook MCP Server

Official
by growthbook
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

create_feature_flag

Generate and manage feature flags using a defined schema in the GrowthBook MCP Server. Specify ID, value type, default value, and file extension to create flags for controlled feature rollouts.

Instructions

Create, add, or wrap an element with a feature flag.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "valueType": "<valueType>",
      "defaultValue": "<defaultValue>",
      "fileExtension": "<fileExtension>"
    },
    "name": "create_feature_flag"
  }
}

Input Schema

NameRequiredDescriptionDefault
archivedNoWhether the feature flag is archived
defaultValueYesThe default value of the feature flag
descriptionNoA description of the feature flag
fileExtensionYesThe extension of the current file. If it's unclear, ask the user.
idYesA unique key name for the feature
projectNoThe project the feature flag belongs to
tagsNoTags for the feature flag
valueTypeYesThe value type the feature flag will return

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states it's for creation/adding/wrapping, implying a write operation, but doesn't specify what happens after creation (e.g., where the flag is stored, whether it's immediately active, if it requires permissions, or what the response looks like). For a tool with 8 parameters and no annotations, this leaves significant gaps in understanding the tool's behavior and effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence with no wasted words. However, the use of multiple verbs ('Create, add, or wrap') slightly reduces clarity without adding value, and it could be more front-loaded with a clearer primary action. Overall, it's efficient but not perfectly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, 4 required, no output schema, and no annotations), the description is inadequate. It doesn't explain the outcome of the creation (e.g., what is returned, where the flag is stored), doesn't differentiate from siblings, and provides minimal behavioral context. For a creation tool with significant parameters, this leaves too many gaps for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, meaning all parameters are documented in the schema itself (e.g., 'id' as a unique key name, 'fileExtension' with specific enum values). The description adds no additional meaning about parameters beyond what's in the schema—it doesn't explain how parameters relate to each other or provide usage context. With high schema coverage, the baseline is 3 even without param info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create, add, or wrap an element with a feature flag' uses multiple verbs (create, add, wrap) which creates ambiguity about the exact action. It mentions 'feature flag' as the resource but doesn't specify what kind of element is being wrapped or where this creation happens (e.g., in code, in a configuration system). Compared to siblings like 'create_force_rule' or 'create_sdk_connection', it's not clearly differentiated beyond the general domain of feature flags.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like 'generate_flag_types', 'get_feature_flags', and 'get_single_feature_flag' that might be related, but the description doesn't indicate whether this is for initial creation versus updates, or when to use it versus other creation tools. No prerequisites or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools

Related Tools