Betterflag
Back to blog

Feature Flags Over MCP: Give Your Coding Agent a Kill Switch

What happens when your feature flag platform is a first-class MCP server: how agents create flags, stage rollouts, and pull kill switches, and why guardrails and audit trails matter more than dashboards.

Mehdi
August 22, 2026
#mcp#feature-flags#agents#claude-code#cursor

Here's a workflow that's become completely normal in 2026: you describe a feature to Claude Code, it writes the code, opens the PR, and... then a human has to log into a dashboard, click "Create flag," type the flag key the agent invented, wire up three environments, and set a rollout percentage. The agent did the engineering; the human did the data entry.

That's backwards. The fix is boring and obvious once you see it: the flag platform should be an MCP server.

What MCP changes

MCP (Model Context Protocol) is the standard that lets agents call tools, the same protocol Claude Code, Cursor, Claude.ai, and most agentic IDEs speak natively. When your flag platform exposes its API as MCP tools, the agent that wrote the code can also:

  • create the flag it just referenced (create_flag)
  • turn it on in staging only (toggle_flag)
  • stage a percentage rollout in prod (set_rollout)
  • target it to your beta cohort (set_targeting)
  • check how it's evaluating in the wild (get_evaluation_stats)
  • and kill it instantly when the error rate spikes (kill_flag)

No tab switching, no copy-pasting flag keys, no "can someone with a seat do this for me."

Setup in one snippet

With Betterflag the server lives at mcp.betterflag.app. OAuth-capable clients can connect with no key handling at all: add the remote server and click Connect. Or with an agent key, in your project's .mcp.json:

{
"mcpServers": {
"@betterflag/sdk": {
"type": "http",
"url": "https://mcp.betterflag.app/mcp",
"headers": {
"Authorization": "Bearer bf_agt_..."
}
}
}
}

Or from the CLI:

claude mcp add --transport http betterflag https://mcp.betterflag.app/mcp \
--header "Authorization: Bearer bf_agt_..."

From that point, "create a flag called checkout-v2, off everywhere, then enable it in staging" is a sentence, not a ticket.

The parts that actually matter

Wrapping an API in MCP tools is a weekend project. The hard parts (the parts worth evaluating any vendor on) are what surrounds the tools:

Agent-scoped keys. An agent shouldn't authenticate as you. It should have its own key with its own scope, visible on its own page, revocable in one click without rotating your personal credentials. When a key leaks or an agent misbehaves, you cut that key, not your whole account.

Agent-attributed audit trails. When a flag flipped at 2 a.m., "who did this?" must have a real answer. Every action through the Betterflag MCP server is audited with the agent key that performed it. git blame for your runtime config, including the robots.

Approval guardrails. Full autonomy is the right default for staging and a terrifying default for production kill switches. Guardrails let you draw that line explicitly: for example, require human confirmation for prod-affecting actions while everything else executes directly. The agent proposes; you approve; the audit log records both.

Instant reversibility. The reason agents + flags is a safe combination at all: every change an agent makes behind a flag is one kill_flag away from off. Agents shipping without flags is the actually scary configuration.

Why this beats "the agent writes YAML"

A fair question: why not just have the agent edit a flags config file in the repo? Two reasons. First, latency: a config file change ships at deploy speed; a flag change over MCP propagates to the edge in seconds, which is the entire point of a kill switch. Second, blast radius: a config file in the repo has no per-action audit, no scoping, no guardrails, no rollback that doesn't involve a revert commit. You'd be rebuilding the platform, badly, in Git.

Where this goes

The dashboard isn't going away. It's becoming the observation layer. Humans review rollout curves, check the audit trail, approve the guarded actions. The write path increasingly belongs to agents, because they're the ones writing the code that needs the flags.

That's the bet Betterflag is built on: flags-only, one-meter pricing, MCP with full API parity from day one. Walk through a full release in Shipping a Feature From Claude Code. Alpha waitlist members lock in 50% off for life.

FAQ

What is an MCP server for feature flags?
An MCP (Model Context Protocol) server exposes flag operations as tools a coding agent can call: create_flag, set_rollout, kill_flag, and so on. The agent that wrote the code can also release it, without a human copying keys into a dashboard.
How do I add Betterflag MCP to Claude Code or Cursor?
OAuth: add https://mcp.betterflag.app/mcp as a remote server and click Connect. Or with an agent key, put the URL and Bearer token in .mcp.json, or run claude mcp add --transport http. Only tools/call is authenticated; the handshake is public so registries can crawl it.
Is it safe to let an agent flip production flags?
Staging can be autonomous. Production kill switches and 100% rollouts should be gated: agent-scoped keys, an audit log that names the agent, and optional human approval. Agents shipping without flags is the actually scary setup.
Why not keep flags in a YAML file in git?
A config-file change ships at deploy speed. A flag over MCP propagates in seconds, which is the point of a kill switch. A file also has no per-action audit, no scoped keys, and no rollback that is not a revert commit.