You already let an AI assistant write the code behind a feature flag. It scaffolds the component, wires the SDK call, and drops in the if (client.variation(...)) branch. Then the assistant stops at the editor boundary: it cannot create the flag, cannot turn it on in dev, cannot ramp it to 10% next week, and cannot tell you three months later that it is safe to delete. You alt-tab to the dashboard for all of that.
Featureflip closes that gap. The MCP server (@featureflip/mcp) gives AI coding assistants and autonomous agents a set of tools for managing your flags: create them, toggle them per environment, adjust targeting and rollouts, and find the ones ready for cleanup. The same assistant that wrote the flagged code can now manage the flag, over the Model Context Protocol, without you leaving the editor. This post covers what that means, how to add it to your editor in one line, the three workflows it is built for, and why it is safe to hand an agent a token.
Key Takeaways
- The Featureflip MCP server (
@featureflip/mcp) lets AI assistants (Claude Code, Cursor, Copilot, Cline) and autonomous agents manage flags through the Management API, from inside the editor.- It runs on demand via
npxwith no service to deploy, and it authenticates with the same bearer token the Management API uses: a Personal Access Token (ffp_) for interactive editor use, or a Service Token (ffs_) for CI and unattended agents.- It manages flag configuration, not evaluation. Your app still reads flags through an SDK on the hot path. The MCP server is for creating, toggling, targeting, and cleaning up.
- The tool set is deliberately flag-focused and safe to automate: the foot-guns (minting SDK keys, deleting projects or organizations) are left out, destructive tools are annotated so clients ask before running them, and every change is audit-logged and attributed to the token that made it.
- It is available on the free Solo plan, so agent-driven flag management is not gated behind an enterprise tier.
1. A fourth way to reach your flags
Featureflip has always had three front doors to the same flag configuration, each for a different caller.
The dashboard is for a person making a change by hand. The Management API is for a script, a CI job, or an internal tool changing configuration programmatically. The SDKs are for your application reading a flag’s value for a user, fast, on the request path.
The MCP server adds a fourth caller: the AI agent working alongside you. Model Context Protocol is an open standard for exposing tools to AI assistants, so any MCP-aware client, Claude Code, Cursor, VS Code Copilot, Cline, and others, can discover and call those tools directly. Under the hood the server is a thin translator. When your agent decides a flag should be created or toggled, it calls a tool; the server turns that into a Management API request and hands back the result. It is the automation surface you already have, reached the way an agent naturally works, one tool call at a time.
That is the important framing: the MCP server does not add a new source of truth or a second place your flags live. It is the Management API wearing an interface an AI assistant can use. Everything the agent does is a call you could have made yourself with curl.
2. Add it to your editor in one line
There is nothing to install ahead of time and nothing to run as a background service. Your MCP client launches the server on demand with npx, so the only prerequisite is a token.
Create one in the dashboard first. A Personal Access Token (prefixed ffp_, created under Settings → API Tokens) acts as you and is the right choice for interactive editor use, so the agent’s changes are attributed to you. A Service Token (prefixed ffs_, created under Organization Settings → Service Tokens) is a machine identity scoped to one organization, for CI or unattended agents. The token walkthrough is the same one the API uses, in the authentication docs.
In Claude Code, that is a single command:
claude mcp add featureflip -e FEATUREFLIP_TOKEN=ffp_your_token -- npx -y @featureflip/mcpMost other clients (Cursor, Cline, and anything that reads a standard MCP config file) take the same package as a JSON block:
{ "mcpServers": { "featureflip": { "command": "npx", "args": ["-y", "@featureflip/mcp"], "env": { "FEATUREFLIP_TOKEN": "ffp_your_token" } } }}Both forms run npx -y @featureflip/mcp. That is the whole setup. The MCP server docs have the per-client details and the full tool reference.
3. Three workflows it is built for
The tool set maps onto the life of a flag: introduce it, ramp it, retire it. Each stage is something you can now ask the agent to do in plain language, at the point in your work where it comes up.
Wrap new code in a flag. Ask the agent to put a new feature behind a flag and it calls wrap_feature. That creates the flag (disabled in every environment, the way all new flags start) and returns an SDK snippet in your project’s language, which the agent applies to your working tree. When you want to try it, ask it to enable the flag in dev and it calls toggle_flag for that one environment. The flag stays off everywhere else until you say otherwise, so nothing reaches a user by accident.
Ramp a rollout. For a flag that is already live, ask the agent to ramp it. It calls update_targeting with the rollout percentage set to 10, then 50, then 100 as your confidence grows, each call replacing the previous percentage rather than stacking on it. Because Featureflip uses sticky bucketing, a user who lands in the rollout stays in it as the percentage climbs. Before a wholesale change, a well-behaved agent reads the current rules with get_targeting first, so it edits from the real state rather than guessing.
Clean up shipped flags. Ask the agent to find cleanup candidates and it calls find_stale_flags, which returns flags that have been fully rolled out or left unchanged for a long stretch. Flag cleanup is the chore teams skip, and skipping it is how a codebase accumulates dead conditionals. For each candidate you confirm, the agent calls delete_flag and removes the matching branch from your code, leaving a single path where the flag used to be. A quick flag_status check first shows the flag’s state across every environment, so you confirm it really is finished before it goes.
4. It configures flags; it does not evaluate them
The most useful thing to understand about the MCP server is what it deliberately leaves out. It does not evaluate flags. When your application needs to know what value a flag has for a given user, right now, on the request path, that is the SDK’s job, and the server SDKs answer it locally in memory in about the time of a map lookup, with no network round trip.
The MCP server sits on the other side of that line, on the configuration plane. It creates the flag, sets its variations, decides which environments it is on, and writes the rules that determine who sees what. Those are low-frequency, deliberate changes. Keeping them off the evaluation path is the same separation the Management API is built around, and it is why an agent hammering the configuration API can never slow down the part of your stack that has to stay fast.
So the mental model stays clean. Use the MCP server (or the API, or the dashboard) to set a flag up. Use an SDK to read it out. The agent manages the switch; your code reads it.
5. Safe to hand an agent a token
Giving an autonomous process write access to your flags is a reasonable thing to be cautious about. The server is designed around that caution in four ways.
A curated tool set, not the whole API. The tools cover the flag lifecycle: projects, environments, flags, variations, targeting, and segment reads. The operations that would be genuinely dangerous in a loop are simply not exposed. There is no tool to mint or revoke SDK keys, no tool to delete a project or an organization, and segment writes stay in the dashboard. An agent cannot reach for a foot-gun that was never put on the table.
Destructive actions are labeled. Every tool carries a standard MCP annotation marking it read-only or destructive. Listing and status tools are read-only and safe to call freely; delete_flag, toggle_flag, and update_targeting are marked destructive, which is the signal most clients use to pause and ask for your confirmation before running them.
Errors are written for a machine to recover from. Featureflip’s API returns one frozen error shape, and the MCP server passes its hints straight through. A mistyped flag key comes back with a did_you_mean suggesting the closest match; a blocked action comes back with next_actions describing what to try instead. An agent reads those and self-corrects on the next call, instead of stalling and waiting for a human to decode a raw error.
Every change is on the record. A flag toggled over MCP is audit-logged and attributed to the token that made it, exactly like a change made by hand in the dashboard or with curl. Requests are rate-limited per token. If you use a Service Token scoped to one organization, its reach is bounded to that organization no matter what the agent asks for.
None of this is gated behind a sales call. The MCP server works on the free Solo plan, so letting an agent manage flags is available from the moment you sign up, not reserved for an enterprise tier.
The shorter version
Featureflip’s MCP server (@featureflip/mcp) gives AI assistants and agents a set of tools for managing feature flags from inside the editor, over the same Management API the dashboard and your scripts use. Add it to Claude Code or Cursor in one line with npx, authenticate with a Personal or Service token, and ask the agent to wrap new code in a flag, ramp a rollout from 10% to 100%, or find and delete flags that have shipped. It manages configuration, not evaluation, so your app still reads flags through an SDK on the hot path. The tool set is scoped to the flag lifecycle with the dangerous operations left out, destructive actions labeled so clients confirm them, errors written so an agent can self-correct, and every change audit-logged and attributed. It is available on the free Solo plan.
Frequently asked questions
Can AI agents manage my feature flags?
Yes. The Featureflip MCP server (@featureflip/mcp) exposes feature-flag management as tools that any MCP-aware AI assistant, such as Claude Code, Cursor, VS Code Copilot, or Cline, can call. An agent can create a flag, enable it in an environment, adjust its targeting and rollout percentage, and find flags that are safe to delete, all from inside your editor. Under the hood it calls the Management API with a token you provide.
What is the Featureflip MCP server?
It is a small program that speaks the Model Context Protocol, an open standard for giving AI assistants tools. It runs on demand through npx with nothing to deploy, and it translates an agent’s tool calls into Management API requests. It is the same flag configuration surface as the dashboard and the REST API, reached the way an AI agent works. The integration docs cover setup and the full tool list.
Which AI tools does it work with?
Any MCP client. That includes Claude Code, Cursor, VS Code with Copilot, and Cline, plus autonomous or CI agents that speak MCP. Interactive editors work best with a Personal Access Token (ffp_) so changes are attributed to you; unattended agents should use a Service Token (ffs_) scoped to one organization.
Does the MCP server evaluate flags?
No. It manages flag configuration: creating, toggling, targeting, and cleanup. Reading a flag’s value for a user at runtime is the job of the language SDKs, which evaluate locally in memory on your application’s request path. Keeping configuration and evaluation on separate surfaces is what keeps flag reads fast no matter how much an agent writes.
Is it safe to let an agent change flags?
It is built to be. The tool set is scoped to the flag lifecycle, with dangerous operations like minting SDK keys or deleting projects deliberately left out. Destructive tools are annotated so most clients ask for confirmation before running them, new flags start disabled in every environment, and every change is audit-logged and attributed to its token. A Service Token’s reach is bounded to a single organization.
Featureflip is a focused, flat-priced feature flag platform, and the MCP server brings its flag management into the editor where you and your AI assistant already work: create flags, ramp rollouts, and clean up shipped ones over the same audited Management API, with a tool set scoped to be safe to automate. Read the MCP server docs to wire it into your editor, see how it compares on the pricing page, and start on the free Solo plan without a credit card.