Instead of a tool per endpoint, the competence sits in skills — bundled markdown workflows the agent reads before acting, so creating a feature flag follows GrowthBook's documented sequence rather than the model's guess at it. Splitting read from write is what lets a client gate mutations properly, and an expired token comes back as a 401 the client can refresh on rather than as a tool error somebody has to interpret.
A deliberately thin server: an authenticated GET passthrough, an authenticated POST/PUT/PATCH/DELETE passthrough, and two tools that list and read GrowthBook's bundled agent skills — markdown workflows saying which calls a given task needs.
- Any GrowthBook REST endpoint read by path, query string included, through one authenticated GET tool
- Any mutating call — POST, PUT, PATCH or DELETE — with a JSON body, through one authenticated write tool
- The bundled skills listed by name and description, and any of them read in full, including qualified child workflows such as feature-flags/references/flag-create
- Read and write kept as separate tools, so a client can honour readOnlyHint and destructiveHint properly
- Tool names prefixed growthbook_ so they stay unambiguous alongside other servers
- A capability-only surface at /mcp/api, or GB_SKILLS_ENABLED=false, when you want the passthroughs without the skills
A GrowthBook API key or personal access token in GB_API_KEY. npx @growthbook/mcp runs it over stdio, with GB_API_URL pointing at a self-hosted instance and defaulting to https://api.growthbook.io. For a remote setup, GB_MCP_TRANSPORT=http listens on GB_MCP_PORT 3333 bound to GB_MCP_HOST 127.0.0.1, and GB_MCP_URL is mandatory — the server refuses to start in HTTP mode without it — with OAuth advertised at /.well-known/oauth-protected-resource and OAUTH_AS_ENABLED=1 required on the GrowthBook API side. GB_HTTP_HEADER_* adds extra request headers, for instance for an access proxy in front of the API.
One command plus a key — npx @growthbook/mcp, then supply credentials
