Skip to main content
Glama
growthbook

GrowthBook MCP Server

Official
by growthbook

create_force_rule

Set a feature to a specific value for targeted environments using conditions. Use this tool to enforce feature behavior in specific scenarios, ideal for controlled rollouts or conditional overrides.

Instructions

Create a new force rule on an existing feature. If the existing feature isn't apparent, create a new feature using create_feature_flag first. A force rule sets a feature to a specific value for a specific environment based on a condition. For A/B tests and experiments, use create_experiment instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
conditionNoApplied to everyone by default. Write conditions in MongoDB-style query syntax.
descriptionNo
environmentsYes
featureIdYesThe ID of the feature to create the rule on
fileExtensionYesThe extension of the current file. If it's unclear, ask the user.
valueYesThe type of the value should match the feature type

Implementation Reference

  • The handler function that implements the create_force_rule tool. It fetches default environments, constructs a payload with force rules for each environment, sends a POST request to update the feature flag, handles the response, and returns formatted content with GrowthBook link and code stub.
    async ({ featureId, description, condition, value, fileExtension }) => {
      try {
        // Fetch feature defaults first and surface to user
        const defaults = await getDefaults(apiKey, baseApiUrl);
        const defaultEnvironments = defaults.environments;
    
        const payload = {
          // Loop through the environments and create a rule for each one keyed by environment name
          environments: defaultEnvironments.reduce((acc, env) => {
            acc[env] = {
              enabled: false,
              rules: [
                {
                  type: "force",
                  description,
                  condition,
                  value,
                },
              ],
            };
            return acc;
          }, {} as Record<string, { enabled: boolean; rules: Array<any> }>),
        };
    
        const res = await fetch(`${baseApiUrl}/api/v1/features/${featureId}`, {
          method: "POST",
          headers: {
            Authorization: `Bearer ${apiKey}`,
            "Content-Type": "application/json",
          },
          body: JSON.stringify(payload),
        });
    
        await handleResNotOk(res);
    
        const data = await res.json();
    
        const linkToGrowthBook = generateLinkToGrowthBook(
          appOrigin,
          "features",
          featureId
        );
        const { docs, language, stub } = getDocsMetadata(fileExtension);
    
        const text = `This is the API response: ${JSON.stringify(data, null, 2)}
      
        Additionally, here is a template of what to show to the user:
    
        **✅ Your feature flag \`my-flag-name\` is ready!.**
        [View it in GrowthBook](${linkToGrowthBook})
    
        **How to use it in your code:**
        (To the LLM agent. Use the text below to properly add the feature flag to the codebase. Also, surface the relevant docs/implemenation to the user)
    
        ${stub}
    
        **Want to learn more?**
        See the [GrowthBook ${language} docs](${docs})
      `;
    
        return {
          content: [{ type: "text", text }],
        };
      } catch (error) {
        throw new Error(`Error creating force rule: ${error}`);
      }
    }
  • Input schema for the create_force_rule tool, defining parameters like featureId, description, fileExtension, condition, and value using Zod.
    {
      featureId: featureFlagSchema.id,
      description: featureFlagSchema.description.optional().default(""),
      fileExtension: featureFlagSchema.fileExtension,
      condition: z
        .string()
        .describe(
          "Applied to everyone by default. Write conditions in MongoDB-style query syntax."
        )
        .optional(),
      value: z
        .string()
        .describe("The type of the value should match the feature type"),
    },
  • Registration of the create_force_rule tool using server.tool, including description, schema, hints, and handler reference.
    /**
     * Tool: create_force_rule
     */
    server.tool(
      "create_force_rule",
      "Create a new force rule on an existing feature. If the existing feature isn't apparent, create a new feature using create_feature_flag first. A force rule sets a feature to a specific value based on a condition. For A/B tests and experiments, use create_experiment instead.",
      {
        featureId: featureFlagSchema.id,
        description: featureFlagSchema.description.optional().default(""),
        fileExtension: featureFlagSchema.fileExtension,
        condition: z
          .string()
          .describe(
            "Applied to everyone by default. Write conditions in MongoDB-style query syntax."
          )
          .optional(),
        value: z
          .string()
          .describe("The type of the value should match the feature type"),
      },
      {
        readOnlyHint: false,
      },
      async ({ featureId, description, condition, value, fileExtension }) => {
        try {
          // Fetch feature defaults first and surface to user
          const defaults = await getDefaults(apiKey, baseApiUrl);
          const defaultEnvironments = defaults.environments;
    
          const payload = {
            // Loop through the environments and create a rule for each one keyed by environment name
            environments: defaultEnvironments.reduce((acc, env) => {
              acc[env] = {
                enabled: false,
                rules: [
                  {
                    type: "force",
                    description,
                    condition,
                    value,
                  },
                ],
              };
              return acc;
            }, {} as Record<string, { enabled: boolean; rules: Array<any> }>),
          };
    
          const res = await fetch(`${baseApiUrl}/api/v1/features/${featureId}`, {
            method: "POST",
            headers: {
              Authorization: `Bearer ${apiKey}`,
              "Content-Type": "application/json",
            },
            body: JSON.stringify(payload),
          });
    
          await handleResNotOk(res);
    
          const data = await res.json();
    
          const linkToGrowthBook = generateLinkToGrowthBook(
            appOrigin,
            "features",
            featureId
          );
          const { docs, language, stub } = getDocsMetadata(fileExtension);
    
          const text = `This is the API response: ${JSON.stringify(data, null, 2)}
        
          Additionally, here is a template of what to show to the user:
    
          **✅ Your feature flag \`my-flag-name\` is ready!.**
          [View it in GrowthBook](${linkToGrowthBook})
      
          **How to use it in your code:**
          (To the LLM agent. Use the text below to properly add the feature flag to the codebase. Also, surface the relevant docs/implemenation to the user)
    
          ${stub}
    
          **Want to learn more?**
          See the [GrowthBook ${language} docs](${docs})
        `;
    
          return {
            content: [{ type: "text", text }],
          };
        } catch (error) {
          throw new Error(`Error creating force rule: ${error}`);
        }
      }
    );
Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the rule's purpose and dependencies but lacks details on permissions, rate limits, error handling, or what happens if the featureId is invalid. It adds some context but misses key behavioral traits for a creation tool.

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

Conciseness5/5

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

Three sentences front-loaded with the main purpose, followed by prerequisites and alternatives. Each sentence earns its place with no wasted words, making it efficient and well-structured.

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

Completeness3/5

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

For a creation tool with 6 parameters, 67% schema coverage, and no output schema or annotations, the description is adequate but incomplete. It covers usage and purpose but lacks details on return values, error cases, or full parameter semantics, leaving gaps for the agent.

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

Parameters4/5

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

Schema description coverage is 67%, and the description adds value by explaining that force rules set values based on conditions and environments, which clarifies the purpose of parameters like condition and environments beyond the schema. However, it doesn't detail parameter interactions or constraints like value matching feature type specifics.

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

Purpose5/5

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 force rule on an existing feature, specifying it sets a feature to a specific value for specific environments based on a condition. It distinguishes from sibling create_feature_flag (which creates features) and create_experiment (for A/B tests).

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

Usage Guidelines5/5

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

Explicit guidance is provided: use create_feature_flag first if the feature doesn't exist, and use create_experiment instead for A/B tests and experiments. This clearly defines when to use this tool versus alternatives.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/growthbook/growthbook-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server