ConfigCat MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONFIGCAT_API_PASS | Yes | ConfigCat Management API basic authentication password | |
| CONFIGCAT_API_USER | Yes | ConfigCat Management API basic authentication username | |
| CONFIGCAT_BASE_URL | No | ConfigCat Management API host | https://api.configcat.com |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get-change-requestB | Returns the details of a specific Change Request. |
| update-change-requestC | Updates the metadata of a Change Request, such as title, note, schedule, etc. |
| list-change-requestsA | Returns Change Requests of a Product with optional filtering and pagination. |
| list-organizationsA | This endpoint returns the list of the Organizations that belongs to the user. |
| list-productsA | This endpoint returns the list of the Products that belongs to the user. |
| list-tagsA | This endpoint returns the list of the Tags in a
specified Product, identified by the |
| create-tagC | This endpoint creates a new Tag in a specified Product
identified by the |
| list-webhooksA | This endpoint returns the list of the Webhooks that belongs to the given Product identified by the
|
| list-configsA | This endpoint returns the list of the Configs that belongs to the given Product identified by the
|
| create-configB | This endpoint creates a new Config in a specified Product
identified by the |
| list-environmentsA | This endpoint returns the list of the Environments that belongs to the given Product identified by the
|
| create-environmentB | This endpoint creates a new Environment in a specified Product
identified by the |
| list-permission-groupsA | This endpoint returns the list of the Permission Groups that belongs to the given Product identified by the
|
| create-permission-groupB | This endpoint creates a new Permission Group in a specified Product
identified by the |
| list-integrationsA | This endpoint returns the list of the Integrations that belongs to the given Product identified by the
|
| create-integrationA | This endpoint creates a new Integration in a specified Product
identified by the The Parameters dictionary differs for each IntegrationType:
|
| list-segmentsA | This endpoint returns the list of the Segments that belongs to the given Product identified by the
|
| create-segmentB | This endpoint creates a new Segment in a specified Product
identified by the |
| list-settingsA | This endpoint returns the list of the Feature Flags and Settings defined in a
specified Config, identified by the |
| create-settingA | This endpoint creates a new Feature Flag or Setting in a specified Config
identified by the Important: The |
| list-auditlogsB | 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-staleflagsB | 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-referencesC | Get References for Feature Flag or Setting |
| get-configB | This endpoint returns the metadata of a Config
identified by the |
| update-configB | This endpoint updates a Config identified by the |
| delete-configB | This endpoint removes a Config identified by the |
| get-environmentB | This endpoint returns the metadata of an Environment
identified by the |
| update-environmentB | This endpoint updates an Environment identified by the |
| delete-environmentA | This endpoint removes an Environment identified by the |
| get-permission-groupA | This endpoint returns the metadata of a Permission Group
identified by the |
| update-permission-groupC | This endpoint updates a Permission Group identified by the |
| delete-permission-groupB | This endpoint removes a Permission Group identified by the |
| get-integrationB | This endpoint returns the metadata of an Integration
identified by the |
| update-integrationB | This endpoint updates a Config identified by the The Parameters dictionary differs for each IntegrationType:
|
| delete-integrationB | This endpoint removes a Integration identified by the |
| get-sdk-keysB | This endpoint returns the SDK Key for your Config in a specified Environment. |
| list-organization-auditlogsB | 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-membersA | This endpoint returns the list of Members that belongs
to the given Organization, identified by the The results may vary based on the access level of the user who calls the endpoint:
|
| list-pending-invitations-orgA | This endpoint returns the list of pending invitations within the
given Organization identified by the |
| list-pending-invitationsA | This endpoint returns the list of pending invitations within the
given Product identified by the |
| list-predefined-variationsB | This endpoint returns the predefined variations along with their usages in the Environments for a Feature Flag or Setting identified by the |
| update-predefined-variationsB | This endpoint updates the predefined variations for a Feature Flag or Setting identified by the |
| get-productB | This endpoint returns the metadata of a Product
identified by the |
| update-productC | This endpoint updates a Product identified by the |
| delete-productA | This endpoint removes a Product identified by the |
| list-product-membersB | This endpoint returns the list of Members that belongs
to the given Product, identified by the |
| get-product-preferencesA | This endpoint returns the preferences of a Product
identified by the |
| update-product-preferencesB | This endpoint updates the preferences of a Product identified by the |
| get-change-request-proposed-changesA | Returns the proposed changes to the Settings included in a Change Request. |
| update-change-request-proposed-changesC | Updates the proposed changes to the Settings included in a Change Request. |
| get-segmentB | This endpoint returns the metadata of a Segment
identified by the |
| update-segmentB | This endpoint updates a Segment identified by the |
| delete-segmentC | This endpoint removes a Segment identified by the |
| get-settingB | This endpoint returns the metadata attributes of a Feature Flag or Setting
identified by the |
| replace-settingA | This endpoint replaces the whole value of a Feature Flag or Setting
identified by the 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-settingC | This endpoint removes a Feature Flag or Setting from a specified Config,
identified by the |
| update-settingA | This endpoint updates the metadata of a Feature Flag or Setting with a collection of JSON Patch operations in a specified Config. Only the 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. If we send an update request body as below (it changes the Only the |
| list-settings-by-tagB | This endpoint returns the list of the Settings that
has the specified Tag, identified by the |
| get-setting-valueA | This endpoint returns the value of a Feature Flag or Setting
in a specified Environment identified by the The most important attributes in the response are the The |
| replace-setting-valueA | This endpoint replaces the whole value of a Feature Flag or Setting in a specified Environment. Only the 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. If we send a replace request body as below: Then besides that the default value is set to The
|
| update-setting-valueA | This endpoint updates the value of a Feature Flag or Setting with a collection of JSON Patch operations in a specified Environment. Only the 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. If we send an update request body as below: Only the default value is going to be set to The
|
| get-setting-value-v2B | This endpoint returns the value of a Feature Flag or Setting
in a specified Environment identified by the The most important fields in the response are the The The |
| replace-setting-value-v2A | 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 Only the 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. If we send a replace request body as below: Then besides that the default served value is set to |
| update-setting-value-v2A | This endpoint updates the value of a Feature Flag or Setting with a collection of JSON Patch operations in a specified Environment. Only the 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. If we send an update request body as below: Only the first Targeting Rule's So we get a response like this: |
| get-setting-valuesB | This endpoint returns the value of a specified Config's Feature Flags or Settings identified by the The most important attributes in the response are the The |
| post-setting-valuesA | This endpoint replaces the values of a specified Config's Feature Flags or Settings identified by the Only the 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. If we send a replace request body as below: Then besides that the default value is set to The
|
| get-setting-values-v2B | This endpoint returns all Feature Flag and Setting values of a Config identified by the The most important fields in the response are the The The |
| post-setting-values-v2A | This endpoint batch updates the Feature Flags and Settings of a Config identified by the 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. If we send a batch replace request body as below: Then besides that the default value is set to |
| get-tagB | This endpoint returns the metadata of a Tag
identified by the |
| update-tagB | This endpoint updates a Tag identified by the |
| delete-tagA | This endpoint deletes a Tag identified by the |
| get-webhookB | This endpoint returns the metadata of a Webhook
identified by the |
| replace-webhookA | This endpoint replaces the whole value of a Webhook identified by the 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-webhookB | This endpoint removes a Webhook identified by the |
| update-webhookA | This endpoint updates a Webhook identified by the 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. If we send an update request body as below (it changes the Only the |
| get-webhook-signing-keysA | This endpoint returns the signing keys of a Webhook
identified by the 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-commentB | Adds a new comment to the Change Request. |
| apply-change-requestB | Applies the Change Request. The proposed changes will be applied and published immediately. |
| approve-change-requestC | Adds your approval to the Change Request. |
| claim-change-request-ownershipC | Claims ownership of the Change Request. |
| close-change-requestA | Closes the Change Request without applying it. |
| create-change-requestB | Creates a new Change Request for the specified Config and Environment. |
| create-productB | This endpoint creates a new Product in a specified Organization
identified by the |
| create-webhookD | This endpoint creates a new Webhook in a specified Product
identified by the |
| invite-memberC | This endpoint invites a Member into the given Product identified by the |
| remove-change-request-approvalB | Removes your existing approval from the Change Request. |
| resolve-change-request-setting-conflictsA | Updates the proposed changes to a Setting included in the Change Request to resolve conflicts caused by concurrently published changes. |
| update-member-permissionsB | This endpoint updates the permissions of a Member identified by the |
| delete-organization-memberB | This endpoint removes a Member identified by the |
| update-change-request-commentC | Updates an existing Change Request comment. |
| delete-change-request-commentB | Deletes a Change Request comment. |
| delete-invitationA | This endpoint removes an Invitation identified by the |
| delete-product-memberA | This endpoint removes a Member identified by the |
| delete-change-request-proposed-changeB | Removes a setting from a Change Request. |
| update-sdk-documentationB | 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.
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 95 tools
The v1/v2 tool pairs (get-setting-value/get-setting-value-v2, replace-setting-value/replace-setting-value-v2, update-setting-value/update-setting-value-v2, etc.) perform essentially the same operations with different response schemas, and no deprecation guidance helps agents choose. Additionally, update-setting vs update-setting-value vs replace-setting-value have subtle boundaries that names alone don't clarify.
The dominant pattern is consistent snake_case verb_noun (list-configs, create-environment, update-segment, delete-tag). However, there are notable deviations: list-staleflags lacks a separator, post-setting-values uses 'post' where every other full-replace endpoint uses 'replace', v2 suffixes appear inconsistently, and update-sdk-documentation breaks the resource-based convention entirely.
95 tools is an extreme count, well beyond even the 50+ threshold for a 1. While the ConfigCat Management API is genuinely broad, exposing nearly the entire API surface as individual MCP tools creates an overwhelming selection space for agents, especially with the redundant v1/v2 duplicates inflating the count.
The surface covers full CRUD for products, configs, environments, settings, segments, tags, webhooks, integrations, and permission groups, plus a rich change-request lifecycle. Minor gaps exist (no get/update/delete for organizations, no listing of change-request comments, no update/resend for invitations), but core workflows have no dead ends.