Skip to main content
Glama
configcat

ConfigCat MCP Server

Official
by configcat

update-setting-value-v2

Update a feature flag or setting in a specific environment using JSON Patch operations to modify default values, targeting rules, or percentage evaluation attributes while leaving other fields unchanged.

Instructions

This endpoint updates the value of a Feature Flag or Setting with a collection of JSON Patch operations in a specified Environment.

Only the defaultValue, targetingRules, and percentageEvaluationAttribute fields are modifiable by this endpoint.

The advantage of using JSON Patch is that you can describe individual update operations on a resource without touching attributes that you don't want to change. It supports collection reordering, so it also can be used for reordering the targeting rules of a Feature Flag or Setting.

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

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

If we send an update request body as below:

[
  {
    "op": "replace",
    "path": "/targetingRules/0/value/boolValue",
    "value": true
  }
]

Only the first Targeting Rule's value is going to be set to false and all the other fields are remaining unchanged.

So we get a response like this:

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

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.
settingIdYesThe id of the Setting.
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.9/5.0
Behavior3/5

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

With no annotations, the description carries the behavior burden and does disclose partial-update semantics, modifiable fields, and unchanged behavior for omitted fields. However, the worked example is internally inconsistent: the patch sets the value to true but the text and response claim it is set to false, so the disclosed behavior is not fully reliable.

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 with the core action, followed by constraints, rationale, and a detailed example. It is long, but the JSON Patch example is substantial enough to justify the length; the inconsistent example is a content problem rather than a structural one.

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

Completeness4/5

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

For a mutation endpoint with no output schema, the description gives a response example, the set of modifiable fields, and the effect of omitted fields, which are important completion gaps. It does not discuss authentication or explicit routing to alternative endpoints, but the schema covers concurrency/approval parameters and the description otherwise provides enough context.

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%, so the schema carries most parameter meaning; the description adds context by showing a concrete JSON Patch request-body example and listing modifiable fields. The value of that addition is reduced by the example's true/false inconsistency.

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?

Opens with a specific statement of what the endpoint does: updates the value of a Feature Flag or Setting in a specified Environment using JSON Patch. It further clarifies the exact modifiable fields and keeps the operation distinct from replace-style siblings by emphasizing patch semantics.

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

Usage Guidelines4/5

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

Explains when JSON Patch is advantageous (partial updates without touching unrelated fields) and explicitly notes its use for reordering targeting rules. It does not name alternative sibling tools such as replace-setting-value-v2, but the context for choosing this patch-based endpoint is clear.

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