Skip to main content
Glama
configcat

ConfigCat MCP Server

Official
by configcat

post-setting-values-v2

Batch update feature flags and settings with their complete configuration. Omitted fields are reset, so include all current values and targeting rules to preserve them.

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
reasonNoThe reason note for the Audit Log if the Product's "Config changes require a reason" preference is turned on.
configIdYesThe identifier of the Config.
requestBodyYes
environmentIdYesThe identifier of the Environment.
bypassApprovalNoWhether to bypass the approval process and directly apply the change. This is only applicable for users with bypass approval permission.
latestVersionIdNoOptional. The version identifier of the last change made to the Feature Flag or Setting in the Environment. It can be used to make sure concurrent updates are not overwriting each other. If provided and the version identifier does not match the current version, the update will be rejected with a 409 Conflict response. The latest version id can be acquired from the `LastVersionId` property of the response models.
Install Server

TDQS

A3.6/5.0
Behavior4/5

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, and it rises to the occasion on the most critical trait: the complete-replace semantics. It explicitly warns 'Not listing a field means that it will reset' and proves it with a concrete before/after example showing targeting rules deleted when omitted. It does not cover auth requirements, approval-process interactions, or concurrency/version-conflict behavior, which are relevant gaps for a mutating endpoint.

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 front-loaded: purpose in the first sentence, the critical warning in the second paragraph, and the demonstration example last. The three JSON blocks are lengthy but earned — for a destructive operation, the concrete before/request/after example is the clearest way to convey the reset behavior and prevents catastrophic misuse. It is long but every section justifies its existence.

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 — nested requestBody object, six parameters, destructive behavior — and the absence of both annotations and an output schema, more is expected from the description. It nails the single most dangerous behavior (field omission resets values) but omits complementary context: when to choose it over update/replace/single-value siblings, approval-process behavior related to bypassApproval, and optimistic-concurrency behavior for latestVersionId. The inline example does at least hint at the response shape.

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 83% (5 of 6 parameters described), so the baseline is 3 and the schema carries most of the parameter-level meaning. The description adds value by explaining the replace semantics that apply to the requestBody.updateFormulas structure — the critical 'omitted fields get reset' rule is not in the schema. It also references configId and environmentId by name, but adds no format or constraint detail beyond the schema.

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

Purpose4/5

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

The opening sentence states a specific verb and resource: 'batch updates the Feature Flags and Settings of a Config identified by the configId parameter in a specified Environment.' This clearly distinguishes it from single-flag tools like update-setting-value-v2 and replace-setting-value-v2 by emphasizing the batch nature. However, it does not explicitly differentiate itself from the sibling post-setting-values (v1), relying on the name suffix for that distinction.

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 usage context is implied through the framing of 'batch updates' — an agent can infer this is the tool for updating multiple flags/settings at once rather than one at a time. The 'Important' section provides strong guidance on how to construct the request safely (set every field you don't want to change). However, it never explicitly names alternatives or states when-not-to-use-this-tool, leaving sibling routing to inference.

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

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