Model Context Protocol (MCP)

Three parts. At the front, the client is whatever AI tool you already use, such as Claude Code, Cursor, VS Code Copilot, or an autonomous agent. Behind it an MCP server publishes the tools and does the translating, and underneath that sits the ordinary flag platform API that the dashboard and your own scripts already call, so nothing the agent does happens on a private side channel. Featureflip's server (@featureflip/mcp) runs on demand through npx with no service to deploy, authenticates with the same bearer token as the REST API, and turns each tool call into an ordinary API request that is audit-logged and attributed to that token. The MCP server guide lists every tool, and a walkthrough of the three agent workflows covers wrapping new code, ramping a rollout, and cleaning up stale flags.

An MCP server sits on the configuration plane. It creates flags, sets variations, toggles environments, and writes targeting rules, all of which are deliberate low-frequency changes. That same plane can be driven declaratively instead, from files under version control, which is the flags as code approach. It does not evaluate flags. Your application still reads a value for a given user through an SDK on the request path, in memory, which is the split feature management platforms draw between administering a flag and reading one. Most established flag vendors now ship an MCP server, so the interface itself has become ordinary. They differ on two things worth checking: who can reach it, since some gate the platform behind a paid tier, and how carefully the tool set is scoped. Featureflip leaves the foot-guns out entirely, with no tool to mint SDK keys or delete a project, and marks destructive tools so the client asks before running them.