# ConfigCat/mcp-server [Health: Active] **Category:** πŸ’» Developer Tools **Repository:** https://github.com/configcat/mcp-server **GitHub Stars:** 17 **npm Downloads (last month):** 1679 **Views:** 3 **Installs:** 0 **Upvotes:** 0 **Directory Page:** https://allmcps.com/mcp/configcat-mcp-server ## Description MCP server for interacting with ConfigCat feature flag platform. Supports managing feature flags, configs, environments, products and organizations. ## Tools Capabilities this server exposes over MCP: - **get-change-request** β€” Returns the details of a specific Change Request. - **update-change-request** β€” Updates the metadata of a Change Request, such as title, note, schedule, etc. - **list-change-requests** β€” Returns Change Requests of a Product with optional filtering and pagination. - **list-organizations** β€” This endpoint returns the list of the Organizations that belongs to the user. - **list-products** β€” This endpoint returns the list of the Products that belongs to the user. - **list-tags** β€” This endpoint returns the list of the Tags in a specified Product, identified by the `productId` parameter. - **create-tag** β€” This endpoint creates a new Tag in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **list-webhooks** β€” This endpoint returns the list of the Webhooks that belongs to the given Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **list-configs** β€” This endpoint returns the list of the Configs that belongs to the given Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **create-config** β€” This endpoint creates a new Config in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **list-environments** β€” This endpoint returns the list of the Environments that belongs to the given Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **create-environment** β€” This endpoint creates a new Environment in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **list-permission-groups** β€” This endpoint returns the list of the Permission Groups that belongs to the given Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **create-permission-group** β€” This endpoint creates a new Permission Group in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **list-integrations** β€” This endpoint returns the list of the Integrations that belongs to the given Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **create-integration** β€” This endpoint creates a new Integration in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. The Parameters dictionary differs for each IntegrationType: - Datadog - `apikey`: Required. Datadog API key. - `site`: Datadog site. Available values: `Us`, `Eu`, `Us1Fed`, `Us3`, `Us5`. Default: `Us`. - Slack Connecting the Slack integration through the Public Management API will not post messages with the ConfigCat Feature Flags Slack app but with an incoming webhook. - `incoming_webhook.url`: Required. The [incoming webhook URL](https://api.slack.com/messaging/webhooks) where the integration should post messages. - `includeSensitiveData`: Set to "true" to include [sensitive (hashed) comparison values](https://configcat.com/docs/targeting/targeting-rule/user-condition/#confidential-text-comparators). By default, the integration will mask these values in the posted messages. We recommend hiding sensitive comparison values for shared or public Slack channels. - Amplitude - `apiKey`: Required. Amplitude API Key. - `secretKey`: Required. Amplitude Secret Key. - Mixpanel - `serviceAccountUserName`: Required. Mixpanel Service Account Username. - `serviceAccountSecret`: Required. Mixpanel Service Account Secret. - `projectId`: Required. Mixpanel Project ID. - `server`: Mixpanel Server. Available values: `StandardServer`, `EUResidencyServer`. Default: `StandardServer`. - Twilio Segment - `writeKey`: Required. Twilio Segment Write Key. - `server`: Twilio Segment Server. Available values: `Us`, `Eu`. Default: `Us`. - PubNub (work in progress) - **list-segments** β€” This endpoint returns the list of the Segments that belongs to the given Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **create-segment** β€” This endpoint creates a new Segment in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **list-settings** β€” This endpoint returns the list of the Feature Flags and Settings defined in a specified Config, identified by the `configId` parameter. - **create-setting** β€” This endpoint creates a new Feature Flag or Setting in a specified Config identified by the `configId` parameter. **Important:** The `key` attribute must be unique within the given Config. - **list-auditlogs** β€” This endpoint returns the list of Audit log items for a given Product and the result can be optionally filtered by Config and/or Environment. - **list-staleflags** β€” This endpoint returns the list of Zombie (stale) flags for a given Product and the result can be optionally filtered by various parameters. - **get-code-references** β€” Get References for Feature Flag or Setting - **get-config** β€” This endpoint returns the metadata of a Config identified by the `configId`. - **update-config** β€” This endpoint updates a Config identified by the `configId` parameter. - **delete-config** β€” This endpoint removes a Config identified by the `configId` parameter. - **get-environment** β€” This endpoint returns the metadata of an Environment identified by the `environmentId`. - **update-environment** β€” This endpoint updates an Environment identified by the `environmentId` parameter. - **delete-environment** β€” This endpoint removes an Environment identified by the `environmentId` parameter. If the `cleanupAuditLogs` flag is set to true, it also deletes the audit log records related to the environment (except for the `Created a new environment` and `Deleted an environment` records). - **get-permission-group** β€” This endpoint returns the metadata of a Permission Group identified by the `permissionGroupId`. - **update-permission-group** β€” This endpoint updates a Permission Group identified by the `permissionGroupId` parameter. - **delete-permission-group** β€” This endpoint removes a Permission Group identified by the `permissionGroupId` parameter. - **get-integration** β€” This endpoint returns the metadata of an Integration identified by the `integrationId`. - **update-integration** β€” This endpoint updates a Config identified by the `integrationId` parameter. The Parameters dictionary differs for each IntegrationType: - Datadog - `apikey`: Required. Datadog API key. - `site`: Datadog site. Available values: `Us`, `Eu`, `Us1Fed`, `Us3`, `Us5`. Default: `Us`. - Slack Connecting the Slack integration through the Public Management API will not post messages with the ConfigCat Feature Flags Slack app but with an incoming webhook. - `incoming_webhook.url`: Required. The [incoming webhook URL](https://api.slack.com/messaging/webhooks) where the integration should post messages. - `includeSensitiveData`: Set to "true" to include [sensitive (hashed) comparison values](https://configcat.com/docs/targeting/targeting-rule/user-condition/#confidential-text-comparators). By default, the integration will mask these values in the posted messages. We recommend hiding sensitive comparison values for shared or public Slack channels. - Amplitude - `apiKey`: Required. Amplitude API Key. - `secretKey`: Required. Amplitude Secret Key. - Mixpanel - `serviceAccountUserName`: Required. Mixpanel Service Account Username. - `serviceAccountSecret`: Required. Mixpanel Service Account Secret. - `projectId`: Required. Mixpanel Project ID. - `server`: Mixpanel Server. Available values: `StandardServer`, `EUResidencyServer`. Default: `StandardServer`. - Twilio Segment - `writeKey`: Required. Twilio Segment Write Key. - `server`: Twilio Segment Server. Available values: `Us`, `Eu`. Default: `Us`. - PubNub (work in progress) - **delete-integration** β€” This endpoint removes a Integration identified by the `integrationId` parameter. - **get-sdk-keys** β€” This endpoint returns the SDK Key for your Config in a specified Environment. - **list-organization-auditlogs** β€” This endpoint returns the list of Audit log items for a given Organization and the result can be optionally filtered by Product and/or Config and/or Environment. - **list-organization-members** β€” This endpoint returns the list of Members that belongs to the given Organization, identified by the `organizationId` parameter. The results may vary based on the access level of the user who calls the endpoint: - When it's called with Organization Admin privileges, the result will contain each member in the Organization. - When it's called without Organization Admin privileges, the result will contain each Organization Admin along with members of those products where the caller has `Team members and permission groups` (`canManageMembers`) permission. - **list-pending-invitations-org** β€” This endpoint returns the list of pending invitations within the given Organization identified by the `organizationId` parameter. - **list-pending-invitations** β€” This endpoint returns the list of pending invitations within the given Product identified by the `productId` parameter. - **list-predefined-variations** β€” This endpoint returns the predefined variations along with their usages in the Environments for a Feature Flag or Setting identified by the `settingId` parameter. - **update-predefined-variations** β€” This endpoint updates the predefined variations for a Feature Flag or Setting identified by the `settingId` parameter. **Important:** You can only update a predefined variation's value if it is not used anywhere in your feature flags. - **get-product** β€” This endpoint returns the metadata of a Product identified by the `productId`. - **update-product** β€” This endpoint updates a Product identified by the `productId` parameter. - **delete-product** β€” This endpoint removes a Product identified by the `productId` parameter. - **list-product-members** β€” This endpoint returns the list of Members that belongs to the given Product, identified by the `productId` parameter. - **get-product-preferences** β€” This endpoint returns the preferences of a Product identified by the `productId`. - **update-product-preferences** β€” This endpoint updates the preferences of a Product identified by the `productId` parameter. - **get-change-request-proposed-changes** β€” Returns the proposed changes to the Settings included in a Change Request. - **update-change-request-proposed-changes** β€” Updates the proposed changes to the Settings included in a Change Request. - **get-segment** β€” This endpoint returns the metadata of a Segment identified by the `segmentId`. - **update-segment** β€” This endpoint updates a Segment identified by the `segmentId` parameter. - **delete-segment** β€” This endpoint removes a Segment identified by the `segmentId` parameter. - **get-setting** β€” This endpoint returns the metadata attributes of a Feature Flag or Setting identified by the `settingId` parameter. - **replace-setting** β€” This endpoint replaces the whole value of a Feature Flag or Setting identified by the `settingId` parameter. **Important:** As this endpoint is doing a complete replace, it's important to set every other attribute that you don't want to change in its original state. Not listing one means it will reset. - **delete-setting** β€” This endpoint removes a Feature Flag or Setting from a specified Config, identified by the `configId` parameter. - **update-setting** β€” This endpoint updates the metadata of a Feature Flag or Setting with a collection of [JSON Patch](https://jsonpatch.com) operations in a specified Config. Only the `name`, `hint` and `tags` attributes are modifiable by this endpoint. The `tags` attribute is a simple collection of the [tag IDs](#operation/list-tags) attached to the given setting. 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. For example: We have the following resource. ```json { "settingId": 5345, "key": "myGrandFeature", "name": "Tihs is a naem with soem typos.", "hint": "This flag controls my grandioso feature.", "settingType": "boolean", "tags": [ { "tagId": 0, "name": "sample tag", "color": "whale" } ] } ``` If we send an update request body as below (it changes the `name` and adds the already existing tag with the id `2`): ```json [ { "op": "replace", "path": "/name", "value": "This is the name without typos." }, { "op": "add", "path": "/tags/-", "value": 2 } ] ``` Only the `name` and `tags` are updated and all the other attributes remain unchanged. So we get a response like this: ```json { "settingId": 5345, "key": "myGrandFeature", "name": "This is the name without typos.", "hint": "This flag controls my grandioso feature.", "settingType": "boolean", "tags": [ { "tagId": 0, "name": "sample tag", "color": "whale" }, { "tagId": 2, "name": "another tag", "color": "koala" } ] } ``` - **list-settings-by-tag** β€” This endpoint returns the list of the Settings that has the specified Tag, identified by the `tagId` parameter. - **get-setting-value** β€” This endpoint returns the value of a Feature Flag or Setting in a specified Environment identified by the `environmentId` parameter. The most important attributes in the response are the `value`, `rolloutRules` and `percentageRules`. The `value` represents what the clients will get when the evaluation requests of our SDKs are not matching to any of the defined Targeting or Percentage Rules, or when there are no additional rules to evaluate. The `rolloutRules` and `percentageRules` attributes are representing the current Targeting and Percentage Rules configuration of the actual Feature Flag or Setting in an **ordered** collection, which means the order of the returned rules is matching to the evaluation order. You can read more about these rules [here](https://configcat.com/docs/targeting/targeting-overview). - **replace-setting-value** β€” This endpoint replaces the whole value of a Feature Flag or Setting in a specified Environment. Only the `value`, `rolloutRules` and `percentageRules` attributes are modifiable by this endpoint. **Important:** As this endpoint is doing a complete replace, it's important to set every other attribute that you don't want to change in its original state. Not listing one means it will reset. For example: We have the following resource. ```json { "rolloutPercentageItems": [ { "percentage": 30, "value": true }, { "percentage": 70, "value": false } ], "rolloutRules": [], "value": false } ``` If we send a replace request body as below: ```json { "value": true } ``` Then besides that the default value is set to `true`, all the Percentage Rules are deleted. So we get a response like this: ```json { "rolloutPercentageItems": [], "rolloutRules": [], "value": true } ``` The `rolloutRules` property describes two types of rules: - **Targeting rules**: When you want to add or update a targeting rule, the `comparator`, `comparisonAttribute`, and `comparisonValue` members are required. - **Segment rules**: When you want to add add or update a segment rule, the `segmentId` which identifies the desired segment and the `segmentComparator` members are required. - **update-setting-value** β€” This endpoint updates the value of a Feature Flag or Setting with a collection of [JSON Patch](https://jsonpatch.com) operations in a specified Environment. Only the `value`, `rolloutRules` and `percentageRules` attributes 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. ```json { "rolloutPercentageItems": [ { "percentage": 30, "value": true }, { "percentage": 70, "value": false } ], "rolloutRules": [], "value": false } ``` If we send an update request body as below: ```json [ { "op": "replace", "path": "/value", "value": true } ] ``` Only the default value is going to be set to `true` and all the Percentage Rules are remaining unchanged. So we get a response like this: ```json { "rolloutPercentageItems": [ { "percentage": 30, "value": true }, { "percentage": 70, "value": false } ], "rolloutRules": [], "value": true } ``` The `rolloutRules` property describes two types of rules: - **Targeting rules**: When you want to add or update a targeting rule, the `comparator`, `comparisonAttribute`, and `comparisonValue` members are required. - **Segment rules**: When you want to add add or update a segment rule, the `segmentId` which identifies the desired segment and the `segmentComparator` members are required. - **get-setting-value-v2** β€” This endpoint returns the value of a Feature Flag or Setting in a specified Environment identified by the `environmentId` parameter. The most important fields in the response are the `defaultValue`, `targetingRules`, and `percentageEvaluationAttribute`. The `defaultValue` represents what the clients will get when the evaluation requests of our SDKs are not matching to any of the defined Targeting Rules, or when there are no additional rules to evaluate. The `targetingRules` represents the current Targeting Rule configuration of the actual Feature Flag or Setting in an **ordered** collection, which means the order of the returned rules is matching to the evaluation order. You can read more about these rules [here](https://configcat.com/docs/targeting/targeting-overview/). The `percentageEvaluationAttribute` represents the custom [User Object](https://configcat.com/docs/targeting/user-object/) attribute that must be used for [percentage evaluation](https://configcat.com/docs/targeting/percentage-options/) of the Feature Flag or Setting. - **replace-setting-value-v2** β€” This endpoint replaces the value and the Targeting Rules of a Feature Flag or Setting in a specified Environment identified by the SDK key passed in the `X-CONFIGCAT-SDKKEY` header. Only the `defaultValue`, `targetingRules`, and `percentageEvaluationAttribute` fields are modifiable by this endpoint. **Important:** As this endpoint is doing a complete replace, it's important to set every other field that you don't want to change to its original state. Not listing one means it will reset. For example: We have the following resource of a Feature Flag. ```json { "defaultValue": { "boolValue": false }, "targetingRules": [ { "conditions": [ { "userCondition": { "comparisonAttribute": "Email", "comparator": "sensitiveTextEquals", "comparisonValue": { "stringValue": "test@example.com" } } } ], "percentageOptions": [], "value": { "boolValue": true } } ] } ``` If we send a replace request body as below: ```json { "defaultValue": { "boolValue": true } } ``` Then besides that the default served value is set to `true`, all the Targeting Rules are deleted. So we get a response like this: ```json { "defaultValue": { "boolValue": true }, "targetingRules": [] } ``` - **update-setting-value-v2** β€” This endpoint updates the value of a Feature Flag or Setting with a collection of [JSON Patch](https://jsonpatch.com) 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. ```json { "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: ```json [ { "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: ```json { "defaultValue": { "boolValue": false }, "targetingRules": [ { "conditions": [ { "userCondition": { "comparisonAttribute": "Email", "comparator": "sensitiveTextEquals", "comparisonValue": { "stringValue": "test@example.com" } } } ], "percentageOptions": [], "value": { "boolValue": false } } ] } ``` - **get-setting-values** β€” This endpoint returns the value of a specified Config's Feature Flags or Settings identified by the `configId` parameter in a specified Environment identified by the `environmentId` parameter. The most important attributes in the response are the `value`, `rolloutRules` and `percentageRules`. The `value` represents what the clients will get when the evaluation requests of our SDKs are not matching to any of the defined Targeting or Percentage Rules, or when there are no additional rules to evaluate. The `rolloutRules` and `percentageRules` attributes are representing the current Targeting and Percentage Rules configuration of the actual Feature Flag or Setting in an **ordered** collection, which means the order of the returned rules is matching to the evaluation order. You can read more about these rules [here](https://configcat.com/docs/targeting/targeting-overview/). - **post-setting-values** β€” This endpoint replaces the values of a specified Config's Feature Flags or Settings identified by the `configId` parameter in a specified Environment identified by the `environmentId` parameter. Only the `value`, `rolloutRules` and `percentageRules` attributes are modifiable by this endpoint. **Important:** As this endpoint is doing a complete replace, it's important to set every other attribute that you don't want to change in its original state. Not listing one means it will reset. For example: We have the following resource. ```json { "settingValues": [ { "rolloutPercentageItems": [ { "percentage": 30, "value": true }, { "percentage": 70, "value": false } ], "rolloutRules": [], "value": false, "settingId": 1 } ] } ``` If we send a replace request body as below: ```json { "settingValues": [ { "value": true, "settingId": 1 } ] } ``` Then besides that the default value is set to `true`, all the Percentage Rules are deleted. So we get a response like this: ```json { "settingValues": [ { "rolloutPercentageItems": [], "rolloutRules": [], "value": true, "setting": { "settingId": 1 } } ] } ``` The `rolloutRules` property describes two types of rules: - **Targeting rules**: When you want to add or update a targeting rule, the `comparator`, `comparisonAttribute`, and `comparisonValue` members are required. - **Segment rules**: When you want to add add or update a segment rule, the `segmentId` which identifies the desired segment and the `segmentComparator` members are required. - **get-setting-values-v2** β€” This endpoint returns all Feature Flag and Setting values of a Config identified by the `configId` parameter in a specified Environment identified by the `environmentId` parameter. The most important fields in the response are the `defaultValue`, `targetingRules`. The `defaultValue` represents what the clients will get when the evaluation requests of our SDKs are not matching to any of the defined Targeting Rules, or when there are no additional rules to evaluate. The `targetingRules` represents the current Targeting Rule configuration of the actual Feature Flag or Setting in an **ordered** collection, which means the order of the returned rules is matching to the evaluation order. You can read more about these rules [here](https://configcat.com/docs/targeting/targeting-overview/). The `percentageEvaluationAttribute` represents the custom [User Object](https://configcat.com/docs/targeting/user-object/) attribute that must be used for [percentage evaluation](https://configcat.com/docs/targeting/percentage-options/) of the Feature Flag or Setting. - **post-setting-values-v2** β€” 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. ```json { "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: ```json { "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: ```json { "settingFormulas": [ { "defaultValue": { "boolValue": false }, "targetingRules": [], "setting": { "settingId": 1 } } ] } ``` - **get-tag** β€” This endpoint returns the metadata of a Tag identified by the `tagId`. - **update-tag** β€” This endpoint updates a Tag identified by the `tagId` parameter. - **delete-tag** β€” This endpoint deletes a Tag identified by the `tagId` parameter. To remove a Tag from a Feature Flag or Setting use the [Update Flag](#operation/update-setting) endpoint. - **get-webhook** β€” This endpoint returns the metadata of a Webhook identified by the `webhookId`. - **replace-webhook** β€” This endpoint replaces the whole value of a Webhook identified by the `webhookId` parameter. **Important:** As this endpoint is doing a complete replace, it's important to set every other attribute that you don't want to change in its original state. Not listing one means it will reset. - **delete-webhook** β€” This endpoint removes a Webhook identified by the `webhookId` parameter. - **update-webhook** β€” This endpoint updates a Webhook identified by the `webhookId` parameter with a collection of [JSON Patch](https://jsonpatch.com) operations. 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. For example: We have the following resource. ```json { "webhookId": 6, "url": "https://example.com/hook", "httpMethod": "post", "content": "null", "webHookHeaders": [] } ``` If we send an update request body as below (it changes the `content` field and adds a new HTTP header): ```json [ { "op": "replace", "path": "/content", "value": "Some webhook content." }, { "op": "add", "path": "/webHookHeaders/-", "value": { "key": "X-Custom-Header", "value": "Custom header value" } } ] ``` Only the `content` and `webHookHeaders` are updated and all the other attributes remain unchanged. So we get a response like this: ```json { "webhookId": 6, "url": "https://example.com/hook", "httpMethod": "post", "content": "Some webhook content.", "webHookHeaders": [ { "key": "X-Custom-Header", "value": "Custom header value", "isSecure": false } ] } ``` - **get-webhook-signing-keys** β€” This endpoint returns the signing keys of a Webhook identified by the `webhookId`. Signing keys are used for ensuring the Webhook requests you receive are actually sent by ConfigCat. Here you can read more about Webhook request verification. - **add-change-request-comment** β€” Adds a new comment to the Change Request. - **apply-change-request** β€” Applies the Change Request. The proposed changes will be applied and published immediately. - **approve-change-request** β€” Adds your approval to the Change Request. - **claim-change-request-ownership** β€” Claims ownership of the Change Request. - **close-change-request** β€” Closes the Change Request without applying it. - **create-change-request** β€” Creates a new Change Request for the specified Config and Environment. - **create-product** β€” This endpoint creates a new Product in a specified Organization identified by the `organizationId` parameter, which can be obtained from the [List Organizations](#operation/list-organizations) endpoint. - **create-webhook** β€” This endpoint creates a new Webhook in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint. - **invite-member** β€” This endpoint invites a Member into the given Product identified by the `productId` parameter. - **remove-change-request-approval** β€” Removes your existing approval from the Change Request. - **resolve-change-request-setting-conflicts** β€” Updates the proposed changes to a Setting included in the Change Request to resolve conflicts caused by concurrently published changes. - **update-member-permissions** β€” This endpoint updates the permissions of a Member identified by the `userId`. This endpoint can also be used to move a Member between Permission Groups within a Product. Only a single Permission Group can be set per Product. - **delete-organization-member** β€” This endpoint removes a Member identified by the `userId` from the given Organization identified by the `organizationId` parameter. - **update-change-request-comment** β€” Updates an existing Change Request comment. - **delete-change-request-comment** β€” Deletes a Change Request comment. - **delete-invitation** β€” This endpoint removes an Invitation identified by the `invitationId` parameter. - **delete-product-member** β€” This endpoint removes a Member identified by the `userId` from the given Product identified by the `productId` parameter. - **delete-change-request-proposed-change** β€” Removes a setting from a Change Request. - **update-sdk-documentation** β€” If the user asks for coding related to a feature flag (such as integrating the ConfigCat SDK, adding a feature flag, or removing a feature flag), always call the tool "update-sdk-documentation" first to download the latest ConfigCat SDK documentation. 1. Analyze the SDK URLs listed in the following SDK Reference list. 2. Then call the tool "update-sdk-documentation" with specific URL from the SDK Reference list to fetch relevant documentation page. ## SDK Reference - [Android (Java) SDK Reference](https://configcat.com/docs/sdk-reference/android.md): ConfigCat Android SDK Reference. This is a step-by-step guide on how to use feature flags in your Android Java application. - [ConfigCat package for Laravel](https://configcat.com/docs/sdk-reference/community/laravel.md): ConfigCat package for Laravel. Implement feature flags within your PHP Laravel application using ConfigCat. - [ConfigCat SDK for Vue.js](https://configcat.com/docs/sdk-reference/community/vue.md): Unofficial Vue SDK for ConfigCat feature flags. Based on ConfigCat's JavaScript SDK. - [C++ SDK Reference](https://configcat.com/docs/sdk-reference/cpp.md): ConfigCat C++ SDK Reference. This is a step-by-step guide on how to use feature flags in your C++ application. - [Dart (Flutter) SDK Reference](https://configcat.com/docs/sdk-reference/dart.md): ConfigCat Dart (Flutter) SDK Reference. This is a step-by-step guide on how to use feature flags in your Dart (Flutter) apps. - [.NET SDK Reference](https://configcat.com/docs/sdk-reference/dotnet.md): ConfigCat .NET SDK Reference. This is a step-by-step guide on how to use feature flags in your .NET application. - [Using the ConfigCat SDK in DI‑Based .NET Applications](https://configcat.com/docs/sdk-reference/dotnet/generic-host.md): Using the ConfigCat SDK in DI-based .NET applications. This is a step-by-step guide on how to use feature flags in your ASP.NET Core applications and other modern .NET applications built on .NET Generic Host or .NET's standard dependency injection. - [Elixir SDK Reference](https://configcat.com/docs/sdk-reference/elixir.md): ConfigCat Elixir SDK Reference. This is a step-by-step guide on how to use feature flags in your Elixir project. - [Go SDK Reference](https://configcat.com/docs/sdk-reference/go.md): ConfigCat Go SDK Reference. This is a step-by-step guide on how to use feature flags in your Go applications. - [Swift (iOS) SDK Reference](https://configcat.com/docs/sdk-reference/ios.md): ConfigCat Swift (iOS) SDK Reference. This is a step-by-step guide on how to use feature flags in your iOS mobile application. - [Java SDK reference](https://configcat.com/docs/sdk-reference/java.md): ConfigCat Java SDK Reference. This is a step-by-step guide on how to use feature flags in your Java application. - [Browser (JavaScript) SDK](https://configcat.com/docs/sdk-reference/js/browser.md): ConfigCat Browser (JavaScript) SDK Reference. This is a step-by-step guide on how to use feature flags in your frontend applications and Web Workers running in the browser. - [Bun SDK](https://configcat.com/docs/sdk-reference/js/bun.md): ConfigCat Bun SDK Reference. This is a step-by-step guide on how to use feature flags in your Bun applications. - [Chromium Extension SDK](https://configcat.com/docs/sdk-reference/js/chromium-extension.md): ConfigCat Chromium Extension SDK Reference. This is a step-by-step guide on how to use feature flags in your extensions for Chromium-based browsers (Chrome, Edge, etc.) - [Cloudflare Worker SDK](https://configcat.com/docs/sdk-reference/js/cloudflare-worker.md): ConfigCat Cloudflare Worker SDK Reference. This is a step-by-step guide on how to use feature flags in your Cloudflare Workers. - [Deno SDK](https://configcat.com/docs/sdk-reference/js/deno.md): ConfigCat Deno SDK Reference. This is a step-by-step guide on how to use feature flags in your Deno applications. - [Node.js SDK](https://configcat.com/docs/sdk-reference/js/node.md): ConfigCat Node.js SDK Reference. This is a step-by-step guide on how to use feature flags in your Node.js applications. - [ConfigCat SDK for JavaScript](https://configcat.com/docs/sdk-reference/js/overview.md): ConfigCat SDK for JavaScript Reference. This is a step-by-step guide on how to use feature flags in your JavaScript applications. - [Kotlin Multiplatform SDK Reference](https://configcat.com/docs/sdk-reference/kotlin.md): ConfigCat Kotlin Multiplatform SDK Reference. This is a step-by-step guide on how to use feature flags in your Kotlin Multiplatform apps. - [OpenFeature Providers](https://configcat.com/docs/sdk-reference/openfeature.md): Integrate feature flags using OpenFeature's vendor-agnostic API with ConfigCat OpenFeature providers. Supported for .NET, Java, Python, Go, JavaScript, React, Node.js, and more. - [Using ConfigCat's OpenFeature Provider in Angular](https://configcat.com/docs/sdk-reference/openfeature/angular.md): This is a step-by-step guide on how to use ConfigCat with the OpenFeature Angular SDK. - [OpenFeature Provider for .NET](https://configcat.com/docs/sdk-reference/openfeature/dotnet.md): ConfigCat OpenFeature Provider for .NET. This is a step-by-step guide on how to use ConfigCat with the OpenFeature .NET SDK. - [OpenFeature Provider for Go](https://configcat.com/docs/sdk-reference/openfeature/go.md): ConfigCat OpenFeature Provider for Go. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Go SDK. - [OpenFeature Provider for Java](https://configcat.com/docs/sdk-reference/openfeature/java.md): ConfigCat OpenFeature Provider for Java. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Java SDK. - [OpenFeature Provider for JavaScript](https://configcat.com/docs/sdk-reference/openfeature/js.md): ConfigCat OpenFeature Provider for JavaScript. This is a step-by-step guide on how to use ConfigCat with the OpenFeature JavaScript SDK. - [OpenFeature Provider for Kotlin](https://configcat.com/docs/sdk-reference/openfeature/kotlin.md): ConfigCat OpenFeature Provider for Kotlin. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Kotlin SDK. - [Using ConfigCat's OpenFeature Provider in NestJS](https://configcat.com/docs/sdk-reference/openfeature/nestjs.md): This is a step-by-step guide on how to use ConfigCat with the OpenFeature NestJS SDK. - [OpenFeature Provider for Node.js](https://configcat.com/docs/sdk-reference/openfeature/node.md): ConfigCat OpenFeature Provider for Node.js. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Node.js SDK. - [OpenFeature Provider for PHP](https://configcat.com/docs/sdk-reference/openfeature/php.md): ConfigCat OpenFeature Provider for PHP. This is a step-by-step guide on how to use ConfigCat with the OpenFeature PHP SDK. - [OpenFeature Provider for Python](https://configcat.com/docs/sdk-reference/openfeature/python.md): ConfigCat OpenFeature Provider for Python. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Python SDK. - [Using ConfigCat's OpenFeature Provider in React](https://configcat.com/docs/sdk-reference/openfeature/react.md): This is a step-by-step guide on how to use ConfigCat with the OpenFeature React SDK. - [OpenFeature Provider for Ruby](https://configcat.com/docs/sdk-reference/openfeature/ruby.md): ConfigCat OpenFeature Provider for Ruby. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Ruby SDK. - [OpenFeature Provider for Rust](https://configcat.com/docs/sdk-reference/openfeature/rust.md): ConfigCat OpenFeature Provider for Rust. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Rust SDK. - [OpenFeature Provider for Swift](https://configcat.com/docs/sdk-reference/openfeature/swift.md): ConfigCat OpenFeature Provider for Swift. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Swift SDK. - [ConfigCat SDK Overview](https://configcat.com/docs/sdk-reference/overview.md): List of all supported technologies like .NET, Java, JavaScript, Node.js, Deno, Bun, Cloudflare Worker, PHP, Python, Ruby, Go, Android, Swift, iOS, Elixir, Dart, Flutter, Angular, React, Vue.js, Chromium Extension, Kotlin Multiplatform, Laravel, Server-Side Rendered apps, etc. - [PHP SDK Reference](https://configcat.com/docs/sdk-reference/php.md): ConfigCat PHP SDK Reference. This is a step-by-step guide on how to use feature flags in your PHP application. - [Python SDK Reference](https://configcat.com/docs/sdk-reference/python.md): ConfigCat Python SDK Reference. This is a step-by-step guide on how to use feature flags in your Python application. - [React SDK Reference](https://configcat.com/docs/sdk-reference/react.md): ConfigCat React SDK Reference. This is a step-by-step guide on how to use feature flags in your React applications. - [Ruby SDK Reference](https://configcat.com/docs/sdk-reference/ruby.md): ConfigCat Ruby SDK Reference. This is a step-by-step guide on how to use feature flags in your Ruby application. - [Rust SDK Reference](https://configcat.com/docs/sdk-reference/rust.md): ConfigCat Rust SDK Reference. This is a step-by-step guide on how to use feature flags in your Rust applications. - [Using the ConfigCat SDK in Unity](https://configcat.com/docs/sdk-reference/unity.md): Using the ConfigCat SDK in Unity. This is a step-by-step guide on how to use feature flags in your Unity project. - [Unreal Engine SDK Reference](https://configcat.com/docs/sdk-reference/unreal.md): ConfigCat Unreal Engine SDK Reference. This is a step-by-step guide on how to use feature flags in your Unreal Engine project. ## Claude Desktop Quick Installation Install path detected from listing signals. Uses `npx` (confidence: high): ```json "mcpServers": { "mcp-server": { "command": "npx", "args": ["-y","@configcat/mcp-server"], "env": { "CONFIGCAT_API_USER": "", "CONFIGCAT_API_PASS": "", "CONFIGCAT_BASE_URL": "" } } } ``` **Requires environment variables:** `CONFIGCAT_API_USER`, `CONFIGCAT_API_PASS`, `CONFIGCAT_BASE_URL` β€” the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for). ## Documentation ## What ConfigCat/mcp-server MCP server does ConfigCat/mcp-server MCP server exposes ConfigCat’s public Management API through the Model Context Protocol. It is intended for developers who want an MCP client to inspect or administer feature flag resources without building separate API calls into each workflow. The server covers organization and product discovery, configuration and environment management, feature flags and settings, tags, segments, permission groups, webhooks, integrations, and change requests. Diagnostic tools provide audit log queries, stale-flag reports, and code references. It also includes tools for retrieving SDK documentation and implementation examples. The available operations include listing, creating, reading, updating, and deleting many resource types. Feature flag workflows include setting values, predefined variations, tags, and Config V2 variants where provided by the API. Change request tools support metadata, proposed changes, comments, approvals, ownership, application, closure, and conflict resolution. ## How it works An MCP-compatible client starts the server as a local process and exposes its tools to the model. The server authenticates to ConfigCat’s public Management API with a username and password, then performs operations against the requested organization, product, config, environment, or other resource. Many tools use identifiers returned by earlier calls. For example, a client can list products, use a product ID to find configs or environments, and then use a config ID to inspect or create settings. Creating a setting requires a key that is unique within its config. Integration creation accepts integration-specific parameters. Documented options include Datadog, Slack, Amplitude, Mixpanel, and Twilio Segment. PubNub is identified as work in progress. Slack configuration uses an incoming webhook URL through the Public Management API, rather than posting through the ConfigCat Feature Flags Slack app. ## Setup and configuration ConfigCat/mcp-server MCP server can be launched with npx: ```json { "command": "npx", "args": ["-y", "@configcat/mcp-server"] } ``` Set these environment variables for authentication: - `CONFIGCAT_API_USER`: ConfigCat Management API basic-auth username. - `CONFIGCAT_API_PASS`: ConfigCat Management API basic-auth password. - `CONFIGCAT_BASE_URL`: Management API host; defaults to `https://api.configcat.com`. Cursor and Claude Desktop use an `mcpServers` configuration section; VS Code uses a `.vscode/mcp.json` file with a `servers` section. Add the credentials to the client’s environment configuration and restart or reload the client as required. ## Tools and capabilities ConfigCat/mcp-server MCP server includes tools for: - Listing and managing organizations, products, members, invitations, and permission groups. - Creating and maintaining configs, environments, segments, tags, settings, and feature flag values. - Reading and changing webhooks, signing keys, integrations, and SDK keys. - Listing audit logs, stale flags, code references, and product resources. - Creating, reviewing, approving, applying, closing, and updating change requests. - Retrieving SDK documentation and code examples for feature flag implementation. ConfigCat’s API rate limits still apply. The server respects those limits and returns an error when a request exceeds them. _Full upstream README: https://allmcps.com/mcp/configcat-mcp-server/readme_