Connect ConfigCat to Claude: Approve Changes and Review Audit Logs

If your team needs to connect ConfigCat to Claude to automate feature flag rollouts, approve Change Requests, or audit environment configuration logs, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and ConfigCat's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting ConfigCat to ChatGPT or explore our broader architectural overview on connecting ConfigCat to AI Agents.

Giving a Large Language Model (LLM) read and write access to your feature flag management system is a significant engineering challenge. You have to handle API authentication lifecycles, map massive JSON schemas to MCP tool definitions, and deal with ConfigCat's strict hierarchical data models. Every time ConfigCat updates an endpoint or changes a targeting rule schema, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for ConfigCat, connect it natively to Claude Desktop, and execute complex feature flag workflows using natural language.

The Engineering Reality of the ConfigCat API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against ConfigCat's APIs is painful. ConfigCat manages critical infrastructure state - its API reflects the necessary complexity of safe, staged deployments.

If you decide to build a custom ConfigCat MCP server, here are the specific integration challenges you will face:

Complex Hierarchical Data Models ConfigCat does not use a flat list of feature flags. The API is strictly hierarchical: Organizations contain Products, Products contain Configs and Environments, and Configs contain Settings (Flags). To flip a single feature flag, an LLM cannot just provide a flag name. It must know the specific config_id and environment_id context. Building an MCP server means creating tools that can recursively traverse this tree to find the correct UUIDs before attempting any state changes.

Change Request Lifecycles In enterprise setups, feature flags are governed by approval workflows. You cannot simply use a standard PUT request to update a flag's value. You must create a Change Request, add proposed changes, submit it for review, acquire approval from authorized team members, and finally apply it. An LLM interacting with ConfigCat needs tools specifically designed to handle these discrete state transitions, or it will constantly hit 403 Forbidden errors when trying to bypass required approvals.

JSON Patch Operations for Targeting Rules ConfigCat heavily relies on JSON Patch operations (application/json-patch+json) for partial updates, particularly when modifying rollout rules or targeting segments without wiping out existing logic. LLMs historically struggle with generating perfectly valid JSON Patch arrays (defining the correct op, path, and value syntax). Your MCP server must either wrap these operations in simpler, LLM-friendly arguments or provide extremely detailed JSON Schema definitions to prevent the model from corrupting your targeting rules.

How to Create the ConfigCat MCP Server

Truto eliminates the need to build and host your own translation layer. Because Truto's tool generation is dynamic and documentation-driven, it automatically derives MCP tools from ConfigCat's resource definitions and schemas.

You can create a ConfigCat MCP server using either the Truto UI or the API.

Method 1: Via the Truto UI

The fastest way to generate an MCP server is through the Truto dashboard.

1. Navigate to the Integrated Accounts page for your connected ConfigCat instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., restrict to read methods only, or filter by specific tool tags like change_requests).
5. Click Create and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/abc123def...).

Method 2: Via the Truto API

For teams embedding AI capabilities into their own platforms, you can programmatically generate MCP servers per tenant. Truto validates the configuration, generates a secure, hashed token in its key-value storage, and returns a ready-to-use URL.

Make a POST request to the /integrated-account/:id/mcp endpoint:

curl -X POST https://api.truto.one/integrated-account/<YOUR_INTEGRATED_ACCOUNT_ID>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "ConfigCat Change Management Server",
    "config": {
      "methods": ["read", "write"],
      "tags": ["change_requests", "audit_logs"]
    },
    "require_api_token_auth": true
  }'

The response contains the secure URL you will pass to Claude:

{
  "id": "mcp-789",
  "name": "ConfigCat Change Management Server",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

How to Connect the MCP Server to Claude

Once you have your Truto MCP URL, you can connect it to your LLM client. An MCP server is fully self-contained - the URL alone encodes the tenant context and available tools.

Method A: Via the Claude or ChatGPT UI

If you are using enterprise AI chat interfaces, you can add the server directly through the UI settings.

For Claude:

1. Open Claude and go to Settings.
2. Navigate to Integrations - Add MCP Server.
3. Paste the Truto MCP URL and click Add.

For ChatGPT:

1. Open ChatGPT and go to Settings - Apps - Advanced settings.
2. Enable Developer mode.
3. Under Custom connectors, click Add and paste your Truto MCP URL.

Method B: Via Manual Config File

If you are running Claude Desktop locally or building a custom LangChain/LangGraph agent, you use a JSON configuration file to establish a Server-Sent Events (SSE) transport connection.

Edit your claude_desktop_config.json file to include the @modelcontextprotocol/server-sse npx runner:

{
  "mcpServers": {
    "configcat_mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Note: If you created the server with require_api_token_auth: true, you must pass your Truto API key in the connection headers.

ConfigCat Hero Tools for Claude

Truto automatically exposes ConfigCat's API endpoints as distinct MCP tools. Here are the most high-leverage tools for automating feature flags and change management.

get_single_config_cat_change_request_by_id

This tool retrieves the complete details of a specific ConfigCat Change Request. It is essential for AI agents reviewing proposed rollout changes, as it returns the title, reasoning, approval status, and activity history of the request.

"Claude, get the details for Change Request ID 8f7b2c-49a1-4321 and summarize the proposed targeting rule modifications."

config_cat_change_requests_approve

This tool allows Claude to add an approval to an existing Change Request. When combined with Slack or Jira integrations, you can build agents that summarize PRs, verify test coverage, and automatically issue an approval in ConfigCat if all conditions are met.

"The QA tests have passed for the new checkout flow. Please add my approval to ConfigCat Change Request ID 8f7b2c-49a1-4321."

list_all_config_cat_product_auditlogs

Retrieves the audit log history for a specific ConfigCat Product. This is a critical security and IT ops tool. It allows Claude to investigate incidents by answering questions about who changed which flag and when.

"Pull the audit logs for the Core E-Commerce product for the last 24 hours. Did anyone modify the payment-gateway-v2 feature flag?"

list_all_config_cat_product_staleflags

ConfigCat automatically detects "zombie" flags - settings that have been fully rolled out (100% or 0%) for an extended period and are likely cluttering your codebase. This tool fetches that report.

"Fetch the stale flags report for our Mobile App product. Group them by the developer who created them so we can assign cleanup tasks."

config_cat_setting_values_v_2_bulk_partial_update

This is the workhorse for modifying flag rules without overwriting the entire configuration. It accepts JSON Patch operations, allowing Claude to safely append a new user ID to an existing targeting rule or adjust a percentage rollout.

"Update the 'beta-ui' setting in the Staging environment. Increase the percentage rollout to 50% and ensure user 'jane@example.com' is explicitly targeted."

create_a_config_cat_product_environment

Allows an agent to automatically provision new feature flag environments. Useful when dynamically spinning up ephemeral environments in your CI/CD pipeline.

"Create a new environment named 'PR-4092-Testing' under our Web Application product."

For the complete inventory of available ConfigCat tools and their exact schema definitions, visit the ConfigCat integration page.

Workflows in Action

Here is how these tools chain together to automate complex DevOps and release management tasks in the real world.

Workflow 1: Approving and Applying a Feature Release

Managing release approvals manually across Jira, Slack, and ConfigCat slows down engineering teams. You can instruct Claude to act as a release manager.

"Review Change Request 9876-abcd. If the proposed changes only affect the 'dark-mode' feature flag and the reason is documented, approve it and apply the changes immediately."

Execution steps:

1. Claude calls get_single_config_cat_change_request_by_id with id: "9876-abcd" to read the proposed changes and metadata.
2. Claude verifies the target flag and reason string against your instructions.
3. Claude calls config_cat_change_requests_approve with change_request_id: "9876-abcd" to log the approval.
4. Claude calls create_a_config_cat_change_request_apply with change_request_id: "9876-abcd" to publish the changes to the environment.

Result: The feature flag is approved and deployed, and the agent responds with a confirmation summary.

sequenceDiagram
    participant User as User
    participant Claude as Claude
    participant Truto as Truto MCP
    participant ConfigCat as ConfigCat API

    User->>Claude: "Review and approve CR 9876-abcd..."
    Claude->>Truto: Call get_single_config_cat_change_request_by_id
    Truto->>ConfigCat: GET /v1/change-requests/9876-abcd
    ConfigCat-->>Truto: Return CR details & proposed changes
    Truto-->>Claude: JSON response
    Claude->>Truto: Call config_cat_change_requests_approve
    Truto->>ConfigCat: POST /v1/change-requests/9876-abcd/approve
    ConfigCat-->>Truto: 200 OK
    Truto-->>Claude: Success
    Claude->>Truto: Call create_a_config_cat_change_request_apply
    Truto->>ConfigCat: POST /v1/change-requests/9876-abcd/apply
    ConfigCat-->>Truto: 200 OK
    Truto-->>Claude: Success
    Claude-->>User: "Change Request approved and deployed successfully."

Workflow 2: Incident Investigation via Audit Logs

When a bug hits production, finding out if a feature flag was accidentally toggled is usually the first troubleshooting step.

"We are seeing spikes in database latency in production. Check the ConfigCat audit logs for the 'Backend Services' product over the last 3 hours and tell me exactly which flags were modified and by whom."

Execution steps:

1. Claude calls list_all_config_cat_products to map 'Backend Services' to its UUID.
2. Claude calls list_all_config_cat_product_auditlogs passing the product_id and calculating the UTC time range for the last 3 hours.
3. Claude parses the returned JSON array, filtering for auditLogTypeEnum values indicating flag modifications.

Result: Claude provides a chronological list of exact flag changes, the environments affected, and the email address of the engineer who made the change, instantly isolating the potential cause of the incident.

Workflow 3: Stale Flag Hygiene

Technical debt accumulates quickly when feature flags are abandoned in the codebase. You can instruct Claude to automate your cleanup sprints.

"Find all stale feature flags in the 'Frontend App' product. For each stale flag, generate a report showing its name, how long it has been stale, and automatically disable the flag in our 'Development' environment as a first step."

Execution steps:

1. Claude calls list_all_config_cat_products to get the target product UUID.
2. Claude calls list_all_config_cat_product_staleflags with the product_id.
3. Claude calls list_all_config_cat_product_environments to get the UUID for 'Development'.
4. For each flag returned in the stale report, Claude calls config_cat_setting_values_v_2_bulk_update with the environment_id, passing defaultValue: false.

Result: The agent deactivates the dead flags in your dev environment and provides a formatted report of what needs to be removed from the source code.

Security and Access Control

Giving AI agents write access to configuration data requires strict guardrails. Truto MCP servers provide multiple layers of security to ensure Claude only touches what you explicitly allow.

• Method Filtering: When creating the server, you can restrict operations to safe methods by defining config: { methods: ["read"] }. This guarantees Claude can fetch audit logs and schemas but absolutely cannot toggle a flag or approve a change request.
• Tag Filtering: You can scope the MCP server to specific functional areas. For example, config: { tags: ["audit"] } ensures only audit log endpoints are exposed, hiding actual flag manipulation tools from the LLM.
• Required Authentication: By default, anyone with the MCP URL can invoke tools. By enabling require_api_token_auth: true, Truto enforces a second layer of security, requiring the client to pass a valid Truto API token in the Authorization header to execute any tool.
• Server Expiration: For temporary agent tasks, you can set an expires_at timestamp. Truto's durable objects automatically destroy the MCP server and revoke all access when the timer hits zero.

Rate Limits and Operational Constraints

When deploying AI agents against ConfigCat, understanding how rate limits are handled is critical for building resilient workflows.

Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When ConfigCat returns an HTTP 429 Too Many Requests error, Truto passes that error directly back to the caller (your agent).

To make this predictable for LLMs, Truto normalizes upstream rate limit information into standardized headers per the IETF specification:

• ratelimit-limit
• ratelimit-remaining
• ratelimit-reset

The caller (the agent framework or your custom orchestrator) is entirely responsible for reading these headers, implementing retry logic, and applying exponential backoff. Do not design your agent assuming the MCP server will absorb rate limit spikes during heavy batch operations like auditing hundreds of stale flags.

Take Control of Your Configuration Infrastructure

Connecting ConfigCat to Claude transforms feature flag management from a manual, click-heavy chore into an automated, conversational workflow. By leveraging a managed MCP architecture, you sidestep the tedious work of tracking API deprecations, managing OAuth tokens, and wrangling complex JSON schemas.

Whether you are automating Change Request approvals, diagnosing production incidents via audit logs, or cleaning up technical debt, Truto gives your AI agents the precise, secure tools they need to operate on your infrastructure safely.