MCP Server
Introduction
The ConfigDirector MCP server allows AI coding assistants to read and update your projects, environments, configs, targeting rules, and segments. It runs as a hosted endpoint, so there is nothing to install:
https://mcp.configdirector.com
It speaks the Model Context Protocol over Streamable HTTP and authenticates with a ConfigDirector API token. Every update an assistant makes goes through the same validations as the dashboard and the Admin API. Updates to configs and segments show in the audit log with a source of MCP.
Code assistant tool calls count as Admin API requests in your organization's usage: one tool call counts as one Admin API request.
Create an API token
- In the ConfigDirector dashboard, open API tokens and create a token.
- Choose the permissions the assistant needs. For exploring and answering questions,
Projects: Read,Environments: Read, andConfigs: Readare enough. If you want the assistant to be able to create and update configs and flags, addConfigs: Create,Configs: Update settings, andConfigs: Update targeting rules. For segments, addSegments: Readto read them,Segments: Createto create them,Segments: Updateto change them, andSegments: Deleteto delete them. - It's recommended that you set an expiration on the token since it will be stored on your workstation to configure your coding tool of choice.
- Copy the token, and optionally save it into a password manager. Do not commit the token into source control.
- The examples below use an environment variable named
CONFIGDIRECTOR_TOKEN, wherever the tool supports that, to provide the API token.
For the project tag catalog, choose Tags: Read for listing and lookup and Tags: Create for creation. These permissions are independent of config permissions. Existing tokens do not gain tag scopes automatically.
The MCP server only exposes the tools that match your token's permissions, so a read-only token produces a read-only assistant.
What the assistant can do
| Tools | What they do |
|---|---|
list_projects, get_project, create_project, update_project | Retrieve projects general information. Create and update projects in your organization. |
list_environments, get_environment, create_environment, update_environment | Retrieve environments within a project. Create new environments, and update environments. |
list_configs, get_config, get_config_activity | Retrieve Configs, their targeting rules per environment, and their most recent evaluations. list_configs can list only the configs that have any of the given tags, or only the configs without tags. |
create_config, update_config_settings | Create configs, feature flags, kill switches, or experiments. Update their settings, for example, the allowed values in an enum. |
update_targeting_rules | Update the targeting rules of a config in a given environment. |
get_targeting_rules_reference | Retrieves the targeting rules format, operators, and target types. This is used by the assistant to write valid targeting rules |
list_segments, get_segment | Retrieve the segments of a project, with their condition groups, environment overrides, and the configs that use them. |
create_segment, update_segment, delete_segment | Create, update, and delete segments. A segment cannot be deleted while the targeting rules of a config use it. |
list_tags, get_tag, find_tag_by_name | Browse the shared project tag catalog and resolve a stable ID by name. Requires tags:read. |
create_tag | Create a shared project tag with a trimmed, case-insensitively unique name of 1–50 characters. Requires tags:create. |
Tag names preserve display casing and allow spaces and punctuation. Name lookup ignores differences in casing and leading or trailing whitespace. Tags do not affect evaluation or appear in SDK payloads. Listing configs by tag needs only Configs: Read. A tag that was deleted matches no config, so asking only for deleted tags lists no configs rather than all of them.
Things you can ask once connected:
- "List the flags in the checkout project."
- "Create a kill switch called payments-v2 in the checkout project, off in all environments."
- "In production, roll new-search out to 10 percent of users, and to everyone whose email ends in @example.com."
- "Create a beta testers segment for everyone whose email ends in @example.com, and turn new-search on for it in staging."
- "Which configs in production have not been evaluated in the last week?"
The assistant sees a short guide to ConfigDirector's vocabulary when it connects (roles, lifetimes, types, how targeting rules work, and segments), so you can talk about configs, feature flags, rollouts, and segments in plain terms.
Claude Code
Add the server for yourself in the current project (the default), for yourself in every project with --scope user, or for the whole team with --scope project, which writes .mcp.json in the project root:
claude mcp add --transport http configdirector https://mcp.configdirector.com \
--header "Authorization: Bearer ${CONFIGDIRECTOR_TOKEN}"
Or write .mcp.json by hand. Claude Code expands environment variables in the url and headers fields, so the token stays out of the repository:
{
"mcpServers": {
"configdirector": {
"type": "http",
"url": "https://mcp.configdirector.com",
"headers": {
"Authorization": "Bearer ${CONFIGDIRECTOR_TOKEN}"
}
}
}
}
Type /mcp inside Claude Code to check: the server should show as connected with its tools listed. From a terminal, claude mcp list shows the same.
Cursor
Create .cursor/mcp.json in the project, or ~/.cursor/mcp.json for every project. Cursor expands ${env:NAME} in this file:
{
"mcpServers": {
"configdirector": {
"url": "https://mcp.configdirector.com",
"headers": {
"Authorization": "Bearer ${env:CONFIGDIRECTOR_TOKEN}"
}
}
}
}
Open Cursor's MCP settings to confirm the server is enabled and its tools are listed. The variable has to be set in the environment Cursor was launched from.
VS Code with GitHub Copilot
Create .vscode/mcp.json. The inputs entry makes VS Code prompt for the token once and store it securely, so nothing sensitive goes in the file:
{
"inputs": [
{
"type": "promptString",
"id": "configdirector-token",
"description": "ConfigDirector API token",
"password": true
}
],
"servers": {
"configdirector": {
"type": "http",
"url": "https://mcp.configdirector.com",
"headers": {
"Authorization": "Bearer ${input:configdirector-token}"
}
}
}
}
Run MCP: List Servers from the command palette to start the server and see its status. The tools appear in the Copilot chat tools picker in agent mode.
Windsurf
Open the MCP settings from the Cascade panel, or edit ~/.codeium/windsurf/mcp_config.json. Windsurf expands ${env:NAME} in this file:
{
"mcpServers": {
"configdirector": {
"serverUrl": "https://mcp.configdirector.com",
"headers": {
"Authorization": "Bearer ${env:CONFIGDIRECTOR_TOKEN}"
}
}
}
}
OpenAI Codex CLI
Add to ~/.codex/config.toml. Codex reads the token from the named environment variable at startup:
[mcp_servers.configdirector]
url = "https://mcp.configdirector.com"
bearer_token_env_var = "CONFIGDIRECTOR_TOKEN"
Run codex mcp list to confirm.
Gemini CLI
Add to ~/.gemini/settings.json, or to the project's .gemini/settings.json. Gemini CLI expands $NAME in string values:
{
"mcpServers": {
"configdirector": {
"httpUrl": "https://mcp.configdirector.com",
"headers": {
"Authorization": "Bearer $CONFIGDIRECTOR_TOKEN"
}
}
}
}
Or add it from the command line:
gemini mcp add --transport http configdirector https://mcp.configdirector.com \
--header "Authorization: Bearer ${CONFIGDIRECTOR_TOKEN}"
Type /mcp in Gemini CLI to see the server and its tools.
Claude Desktop and other tools without header support
Claude Desktop's custom connectors expect OAuth sign-in, which the ConfigDirector server does not offer yet. Until then, bridge it with mcp-remote, which runs locally and forwards to the hosted server with your token. Edit claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"configdirector": {
"command": "npx",
"args": ["mcp-remote", "https://mcp.configdirector.com", "--header", "Authorization:${AUTH_HEADER}"],
"env": {
"AUTH_HEADER": "Bearer <your token>"
}
}
}
}
The header value goes through an environment variable because some desktop clients split arguments on spaces. The same bridge works for any client that can only launch a local command.
Limits and billing
- Each tool call counts as one Admin API request against the monthly free allowance. Connecting and listing tools does not.
- An organization can make up to 60 tool calls per minute across all of its tokens. If that limit is exceeded, the assistant receives a message asking it to wait until the next minute.
- Any update the assistant makes is validated like any other: type constraints, JSON Schema, and the hourly JSON Schema budgets on Free all apply, and the assistant receives the same messages you would see in the dashboard.
- Every update appears in the audit log of the config or segment with the source MCP and the token owner's name.
Security notes
- Prefer environment variables or your editor's secret storage over tokens written into config files. Project-level files such as
.mcp.jsonand.cursor/mcp.jsonare usually committed, do not add an API token to them. - Give each tool its own token with the smallest permission set needed. Revoke the token from the API tokens page when you are no longer using the tool.
- You can rename a token or change its permissions from the API tokens page without replacing the token. Assistants see newly allowed tools after they reconnect.
- The MCP server never returns SDK keys or API tokens.