Skip to main content
Glama
configcat

ConfigCat MCP Server

Official

post-setting-values-v2

Batch replace feature flags and settings in a specific environment. Include the full updated state for each flag to avoid resetting omitted fields.

Instructions

This endpoint batch updates the Feature Flags and Settings of a Config identified by the configId parameter in a specified Environment identified by the environmentId parameter.

Only those Feature Flags and Settings are updated which are part of the request, all the others are left untouched.

Important: As this endpoint is doing a complete replace on those Feature Flags and Settings, which are set in the request. It's important to set every other field that you don't want to change in its original state. Not listing a field means that it will reset.

For example: We have the following resource of a Feature Flag.

{
  "settingFormulas": [
    {
      "defaultValue": {
        "boolValue": false
      },
      "targetingRules": [
        {
          "conditions": [
            {
              "userCondition": {
                "comparisonAttribute": "Email",
                "comparator": "sensitiveTextEquals",
                "comparisonValue": {
                  "stringValue": "test@example.com"
                }
              }
            }
          ],
          "percentageOptions": [],
          "value": {
            "boolValue": true
          }
        }
      ],
      "settingId": 1
    }
  ]
}

If we send a batch replace request body as below:

{ 
  "updateFormulas": [
    {
      "defaultValue": {
        "boolValue": false
      },
      "settingId": 1
    }
  ]
}

Then besides that the default value is set to true, all Targeting Rules of the related Feature Flag are deleted. So we get a response like this:

{
  "settingFormulas": [
    {
      "defaultValue": {
        "boolValue": false
      },
      "targetingRules": [],
      "setting": 
      {
        "settingId": 1
      }
    }
  ]
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configIdYes
environmentIdYes
reasonNo
requestBodyYes
Behavior5/5

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

The description clearly discloses the critical behavior: it does a complete replace of Feature Flags and Settings included in the request, resetting any omitted fields. The detailed JSON example illustrates this destructive nature effectively. With no annotations provided, the description fully compensates.

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

Conciseness3/5

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

The description is adequate in length but includes a lengthy JSON example that could be shortened or moved to a separate reference. The core textual information is front-loaded, but the example dominates the description, making it less concise.

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?

Given the tool's complexity (4 parameters, nested objects, no output schema), the description covers the critical replace behavior and provides an illustrative example. However, it omits details about the reason parameter, return values, and error conditions, leaving gaps in completeness.

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

Parameters2/5

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

Although the input schema is complex with 4 parameters and deep nesting, the description only mentions configId and environmentId explicitly. The reason parameter is not explained, and the requestBody structure is only shown via example without describing each field's purpose. With 0% schema description coverage, the description adds insufficient value beyond the schema itself.

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's function: batch updating Feature Flags and Settings for a specific config and environment. It differentiates itself from sibling tools like replace-setting-value by indicating it handles multiple updates in a single request, and the 'v2' suffix implies a distinct version with specific behavior.

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

Usage Guidelines3/5

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

The description implies that the tool is for batch updates, but does not explicitly state when to use it versus alternatives (e.g., individual updates via replace-setting-value). It warns about the replace behavior but lacks explicit context on when not to use this tool.

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

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/configcat/mcp-server'

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