Outages caused by a configuration update usually come down to small values that were slightly wrong:

• A timeout entered in seconds when the code expects milliseconds
• A URL pasted without the scheme
• A JSON document saved with a typo on one field, or a field missing
• A rollout percentage typed as 10 into a field that expected 0.1

Each of these mistakes is obvious in hindsight, but invisible at the moment someone clicks Save.

The service hosting the value is the only thing standing between that click and your users. It should know what a valid value looks like, and prevent those mistakes.

A value is not a string

Most services store a configuration value as one of a few loose types: boolean, string, number, JSON. That is enough to render an appropriate input field, but it is not enough to know the value makes sense in the context it will be used.

Your code and your application have specific expectations for each value. They expect the timeout to be a positive integer under thirty seconds. They expect an API endpoint to be HTTPS. They expect the theme to be one of light, dark, or system. They expect the JSON payload to have a version field, and an array of at most twenty items. None of that knowledge lives in the feature flag service, so the service cannot validate any of it.

In ConfigDirector, every config has a fine-grained type, and each type carries the constraints your application actually depends on:

• Integer and Float with minimum and maximum bounds. A search-page-size config bounded to 10 through 100 cannot be saved as 0 or as 10000. A free-shipping-threshold bounded to 0 through 500 cannot be saved as a negative number or as ten times what you meant.
• Timespan for bounded durations, so the unit is part of the input field rather than a comment nobody reads.
• URL with an HTTPS-only option. A URL without the scheme is no longer a possibility, nor is HTTP when you expect HTTPS.
• Enum with the allowed set of values. Not as variations of an experiment, but rather baked into the value type of a config used for any given purpose.
• JSON with a JSON Schema, covered in detail below.
• Boolean for feature flags and kill switches, which don't need complicated validation at save time, but do need monitoring and alerting for unexpected evaluation behavior.

The constraints are enforced when a value is saved, in every environment, through all interfaces, before anything reaches an SDK. A bad value never leaves the dashboard, the Terraform file, or the code assistant chat window.

JSON is where it matters most

JSON documents are the most powerful kind of remote config and also the most dangerous. A single document can drive a pricing table, a navigation menu, a set of rate limits, or an experiment's parameters. It is also the value most likely to be edited by hand or copied and pasted inadvertently from an unrelated JSON document, and most likely to fail at read time by the code consuming it.

A JSON Schema turns the structure your code expects into something the service can validate and enforce. In ConfigDirector, a JSON config can carry a schema (draft-07), and from then on every value the config can return is validated against the schema before it is saved. All values that could be returned by the service are validated: the default targeting rule value, every conditional rule value, percentage rollout value, every experiment variation, in every environment.

There is a second check. The schema itself is validated when you update it. Every existing value in every environment is checked against the new schema, and the schema change is rejected if any environment holds a value that would no longer pass. You cannot tighten a schema and leave staging holding a value that the schema would refuse. The values and the contract move together.

Validation has to apply everywhere a value can change

A check that only runs in the dashboard is a suggestion. Values change from more places than the dashboard, via the API, Terraform, a script someone wrote in an afternoon, and now AI coding assistants through an MCP server.

That last one deserves a closer look. When an assistant creates a flag or updates a rollout on your behalf, it is working from a description of the task, not from your source code. It will produce a plausible value. Plausible is not the same as valid. If the service enforces the type and the schema on every write, the assistant gets the same rejection message a person would see in the dashboard, and it can correct itself. If the service does not, the plausible (but invalid) value is now live.

In ConfigDirector, the same validations run for every path that can write a value. The dashboard, the Admin API, the Terraform provider, and the MCP server all go through it, and all of them get the same error messages.

The SDK is the last line, not the first

SDKs should be defensive, and ConfigDirector's are. If a value arrives that cannot be converted to the type your code asked for, the SDK returns the in-code default value you passed and reports why: the code requested a boolean but the config value is a string, or a JSON document that could not be coerced into the requested type. Your code keeps running.

That fallback is the right behavior to keep the application from failing, but it should not be a silent behavior. The in-code default value is usually the conservative choice and not the one you wanted in production. If a rollout falls back to "false" because the code asked for a boolean and the config is a string, the feature is not broken, it is just not happening.

So the SDKs report the reason for every fallback in their telemetry, and ConfigDirector watches for patterns to alert on:

• Type mismatches. Code is requesting a config as a type it cannot be converted to, for example reading an Enum config as a boolean. You get an alert naming the config, the environment, and the SDK that is doing it, while it is still happening.
• In-code default values that are not part of the targeting rules. This is a classic problem. When you first add the flag or config to the code you give it an in-code fallback default that makes sense at the time. Later, things change, the value evolves, but the in-code default stays the same. If the evaluation ever failed, and the SDK had to fall back to the default, the in-code fallback value is outdated and likely no longer what you would want. ConfigDirector detects this and alerts you about in-code defaults that don't match any of the values configured in the targeting rules, meaning it is very likely that the in-code default is outdated. You get notified as soon as the drift is detected, before that outdated fallback value becomes a problem.

Validation on save means the mistake is caught by the person making it, at the moment they make it, with a message that says what was wrong. The alerts cover the other end, the code drifting away from the config.

Try it

Create a JSON config, attach a schema, and try to save a value that does not match it. Then change the schema so an existing value no longer passes and watch the service refuse the change. It is a powerful feature, and once you have it you will not want a config service without it.

The docs on JSON Schema validation cover the limits and the details. The Free plan has no card and includes all of it.

What the MCP server is

The Model Context Protocol is how coding assistants such as Claude Code, Cursor, and Copilot interact with outside tools. A server exposes a set of tools, the assistant reads the tool descriptions and calls them when a task needs them.

ConfigDirector's MCP server is hosted, so there is nothing to install or run. It sits in front of the same Admin API that the dashboard and the Terraform provider use, and it authenticates with an ordinary API token. Every update it makes goes through the same validation as an update from the dashboard, it is recorded in the audit log with the source MCP, and counts as one Admin API request per tool call.

Connecting Claude Code

Create an API token in the dashboard with the permissions you want the assistant to have. For a first try, read permissions on projects, environments, and configs are enough to explore. To support a full workflow, add the create, update settings, and update targeting rules permissions on configs. Copy the token to your clipboard before dismissing the page (the token is only shown at creation time).

Then add the MCP server to claude. The token is read from an environment variable, so it never lands in a file you might commit:

claude mcp add --transport http configdirector https://mcp.configdirector.com \
  --header "Authorization: Bearer ${CONFIGDIRECTOR_TOKEN}"

Type /mcp inside Claude Code and the server shows as connected, with only the tools your token allows. Cursor, VS Code, Windsurf, Codex CLI, and Gemini CLI each have a two-line setup of their own. The MCP docs page has all of them.

A session

Here is what an ordinary afternoon looks like once the server is connected. Each request is typed to the assistant in plain words, the tool calls happen underneath.

Creating a kill switch. "Create a kill switch called payments-v2 in the checkout project, off in every environment." The assistant lists the projects to find checkout, creates the config with the kill switch role, and reports the key. The switch is off in every environment because that is the initial default targeting rule value it was created with.

Rolling out a flag. "In production, roll new-search out to 10 percent of users, and to everyone whose email ends in @example.com." The assistant reads the flag's current rules for production, then replaces them with two rules: a conditional rule that matches the email domain, and a percentage rule that splits the rest. Because the MCP server provides the assistant with the exact targeting rules format and the operators each attribute supports, it does not have to guess.

Checking what is still in use. "Which flags in the checkout project have not been evaluated in the last week?" The assistant reads the recent evaluation activity of each config, which comes from the SDKs' telemetry, and tells you which ones have not been requested by any SDK. Those are the candidates for cleanup, and the dashboard is where you archive them.

Open the audit log afterwards and each change is there, attributed to the token's owner with the source MCP, next to the changes made from the dashboard and from Terraform.

What the server will not do

The assistant only sees the tools its token has permission for. A read-only token produces a read-only assistant. There is no tool to archive a config, or to delete a project or an environment. Those destructive operations stay in the dashboard on purpose.

Each organization can make up to 60 tool calls per minute. Past that, the assistant is told to wait for the next minute rather than being cut off, which keeps a retry loop from doing any harm.

Try it

The docs page has the setup for every supported tool and the full list of what the assistant can do. If you already use ConfigDirector, an API token is all you need. If you do not, the Free plan includes the MCP server.