announcements

Introducing the Zenmanage MCP Server: Manage Flags From Your AI Assistant

The Zenmanage MCP server lets Claude, Cursor, and other AI assistants read and manage your feature flags directly — hosted, nothing to install, authenticated with your own token.

The Zenmanage MCP server connects your AI assistant directly to your flags. Point Claude, Cursor, or VS Code at a hosted URL, and it can look up flag state, create flags, and manage rollouts — authenticated as you, guarded against destructive mistakes, and fully audited.

You're in an editor, working with an AI assistant on a feature, and you need to know whether new-checkout-flow is live in production. So you tab away, open the Zenmanage dashboard, find the flag, check the environment, tab back, and paste the answer into your prompt. Multiply that by every flag you touch in a session and it adds up to a lot of context-switching for a one-line answer.

Today we're introducing the Zenmanage MCP server — a hosted Model Context Protocol server that gives your AI assistant direct, authenticated access to your flags. No more tab-switching to check flag state, and no more asking a teammate to flip a flag on your behalf — your assistant can do both, safely.

Nothing to Install

The server is hosted at https://mcp.zenmanage.com/mcp. There's no package to install and nothing to keep updated — you point your client at that URL with your own Zenmanage token in the Authorization header, and it's live. Claude Code, Claude Desktop, Cursor, and VS Code with GitHub Copilot are all supported today, each with a few lines of config.

Every tool call authenticates as you. The server doesn't hold Zenmanage credentials of its own, and it doesn't log or store anything about your token — a tool call can only ever do what your token could already do directly. You get to pick the shape of that access, too: a personal access token authenticates as your full account, no scope picker required, while a management API token lets you hand out an explicit, narrow set of scopes — flags:read, flags:write, targets:write, and so on — which is what you want for a shared or unattended connection like CI or a team-wide bot.

Read Tools: Ask, Don't Click

The read tools cover the questions you'd otherwise answer by clicking around the dashboard: list_flags to see what exists in a project, get_flag for a single flag's configuration, and evaluate_flag to resolve a flag's live value in a specific environment the same way an SDK client would. Ask your assistant "is new-checkout-flow on in production?" mid-conversation, and it just answers.

There are also tools for walking the structure underneath a flag — list_targets, list_target_rules, list_flag_values — so an assistant can trace exactly why a flag is resolving the way it is before you ask it to change anything.

Write Tools: Guarded by Default

Write access is where "let an AI assistant touch production flags" starts to sound risky, so we built the write tools to fail closed. Every delete_* tool refuses to run unless it's called with an explicit confirm: true — an assistant can't talk itself into deleting a flag as a side effect of a vague request. Writes accept an idempotency_key so a retried call can't double-apply. And every write lands in the same audit trail as a change made through the app or the API — you can always see exactly what an assistant did and when.

Within those guardrails, the write tools cover real work: create_flag and update_flag for flag lifecycle, a full set of targeting-rule tools for building up match criteria, and publish_target plus rollout tools for shipping a change — including a percentage rollout, scheduled for later if you want it. Ask your assistant to "create a flag for the new pricing page and roll it out to 5% of production," and it can do the whole sequence: create the flag, define the value, publish a target with a manual rollout at 5%. You still see every step in the audit log.

Why This, Why Now

A lot of the work you do around feature flags isn't really flag work — it's context assembly. Which flag controls this behavior? What's it currently set to in staging versus production? Who's targeted? That's exactly the kind of lookup an AI assistant already sitting in your editor is well-positioned to do, if it can reach the data.

We didn't want that to mean giving an assistant a standing API key with full access and hoping for the best. Scoped tokens and safe-by-default writes mean you can extend exactly the amount of trust you're comfortable with — read-only for a teammate's assistant, write access with a narrow scope for your own, nothing destructive without an explicit confirmation either way.

Get Started

The MCP server is live now for every Zenmanage account. Here's where to go next:

  • MCP Server documentation — ready-to-paste configs for Claude Code, Claude Desktop, Cursor, and VS Code, plus the full tool and scope reference.
  • Start your free trial — create an account, generate a token, and connect your assistant in a few minutes.
Let your AI assistant manage flags — safely
Connect Claude, Cursor, or Copilot to your Zenmanage flags with a token you control. No package to install, no standing credentials.
Read the docs

This is the first release of the MCP server, and we're actively building on it. If you have thoughts on which tools would save you the most tab-switching, we want to hear them — reach out at hello@zenmanage.com.

Enjoyed this article?

Share it with your network.