Set up feature flags with Claude Code and other AI agents

Flagbearer has an MCP server, which lets an AI coding agent like Claude Code work with your flags directly. Connect it once, and the agent can add the SDK to your app, create flags, write the code that checks them and change who gets a feature, all from the conversation you're already having.

This guide goes from nothing to a feature behind a flag in a few minutes.

Connect your agent

One command adds the server to Claude Code:

claude mcp add --transport http flagbearer https://mcp.flagbearer.dev

The first time the agent uses it, Flagbearer opens in your browser. Pick the organization and the access it gets, Editor or Viewer, and click Connect. Other agents take the same URL in their own settings. The MCP docs have the details.

Ask for a feature behind a flag

Now describe what you want in plain words:

Put the new checkout behind a feature flag called new-checkout.

The agent takes it from there:

1. Creates the flag in Flagbearer. New flags start off everywhere, so nothing changes for your users yet.
2. Reads the current SDK docs for your platform, so the code it writes matches the SDK you'll install, not an old example.
3. Sets up the SDK if your app doesn't have it. Flagbearer gives the agent the steps in order: look for an existing client and reuse it, otherwise install the package and create one. For browser and mobile apps it's handed your environment's public client key. Server keys stay secret, so for a server app it reads yours from an environment variable and asks you to add it if it's missing.
4. Writes the check around your feature, with the existing behavior as the default, and tells you what it added and anything left for you to do.
5. Adds typed flag keys in TypeScript projects that use the browser, React Native or Node SDK, so a misspelled key is a type error.

Change who gets it, in a sentence

Rolling out is a conversation too:

Turn new-checkout on for our testers in production.

Roll new-checkout out to 25% of users.

The agent changes the flag, and your users see it within seconds, with no redeploy. Ask "which flags are on in production?" and it lists them with their rollouts.

Find out what a user saw

When a customer writes in, the agent can look them up by email:

What flags did jane@example.com have in production yesterday at 2pm, and what
has changed for them since?

It answers with each flag, on or off, the reason, and any change in between, so you can tell a flag's effect from an unrelated bug in a minute.

Flag code written the careful way

An agent connected to Flagbearer is given the same rules for writing flag code that we recommend to people, along with the SDK docs for your platform:

• The default keeps today's behavior, so your app acts the same until you turn the flag on.
• The check happens once, at the top of the feature, where it's easy to find and easy to remove.
• The existing code path stays as it is while the new one rolls out.
• Anything about access, pricing or data is enforced on your server.
• Both paths get tests.

When the rollout is done, ask the agent to remove the check and the old path from your code. Once that's shipped, delete the flag in the dashboard.

You stay in charge

• Production asks first. The agent confirms with you before changing a flag in production.
• Testers by default. Turning a flag on without a percentage reaches only your testers. The agent asks before turning it on for everyone.
• Your access, capped. It works in the one organization you picked, with the access you picked. Disconnect it any time from the organization's API tokens tab.
• Secret keys stay secret. The agent never sees a server key.

Check the setup

After the app has run with the new code, ask the agent to check the SDK setup. It reports anything that looks off, like a flag your code checks that doesn't exist, so small mistakes are caught early.

Next: plan the rollout

With the flag in place, see how to roll a feature out gradually.