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

1. In the ConfigDirector dashboard, open API tokens and create a token.
2. Choose the permissions the assistant needs. For exploring and answering questions, Projects: Read, Environments: Read, and Configs: Read are enough; add Contexts: Read for the assistant to evaluate a config for a context ConfigDirector has stored from SDK evaluations. If you want the assistant to be able to create and update configs and flags, add Configs: Create, Configs: Update settings, and Configs: Update targeting rules; add Configs: Archive for it to archive them. For segments, add Segments: Read to read them, Segments: Create to create them, Segments: Update to change them, and Segments: Delete to delete them.
3. 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.
4. Copy the token, and optionally save it into a password manager. Do not commit the token into source control.
5. 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

list_configs lists every config of the project unless the assistant narrows the list down. search lists the configs whose key or description contains some text, ignoring case. role, type, status and lifetime take one value each: a role (config, flag, kill-switch or experiment), a type (boolean, string, integer, float, enum, url, json or timespan), a lifecycle state (new, in-use, settled, archive-ready or stale), or temporary or permanent. tagIds lists the configs that have any of the given tags, and untagged only the configs without tags. A config is listed only when it matches every filter the assistant sends, and filtering needs only Configs: Read. For example, asking for the stale feature flags of a project sends role: flag and status: stale.

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. 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."
• "Which flags in the checkout project are settled and ready to remove from the code?"
• "Create a kill switch called payments-v2 in the checkout project, off in all environments."
• "new-checkout is staying for good. Make it a kill switch."
• "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?"
• "What does user 123 get for new-checkout in production, and why?"

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}'

The single quotes keep your shell from putting the token itself in the configuration: Claude Code reads CONFIGDIRECTOR_TOKEN each time it starts, so a token you replace takes effect on the next start, and --scope project commits only the variable's name.

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.

More than one organization

An API token belongs to one organization, so working for two organizations means one token each. Give each repository its own configuration that reads a variable named for the organization, such as CONFIGDIRECTOR_TOKEN_ACME and CONFIGDIRECTOR_TOKEN_GLOBEX, and set both variables in your shell. For Claude Code, add the server in each repository with the default scope, which is local to that repository and to you:

cd ~/code/acme-storefront
claude mcp add --transport http configdirector https://mcp.configdirector.com \
  --header 'Authorization: Bearer ${CONFIGDIRECTOR_TOKEN_ACME}'

cd ~/code/globex-portal
claude mcp add --transport http configdirector https://mcp.configdirector.com \
  --header 'Authorization: Bearer ${CONFIGDIRECTOR_TOKEN_GLOBEX}'

The same works for Cursor, VS Code and Gemini CLI, whose configuration file lives in the repository. Do not set CONFIGDIRECTOR_TOKEN for every terminal: the CLI uses that variable ahead of its own sign-ins, so a command in the other organization's repository would send the wrong token and stop.

Windsurf, Codex and Claude Desktop read one configuration for every repository, so the variable it names has to hold the right organization's token where the tool starts, for example from a loader such as direnv that sets it per directory. Otherwise, let that tool work for one organization, and reach the other through the CLI, which keeps one sign-in per organization.

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.json and .cursor/mcp.json are 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.