Thin MCP server for GrowthBook — skill loader + authenticated API passthrough
GrowthBook MCP is a well-structured thin API wrapper with 4 tools. All tools have clear descriptions, proper Zod schemas with type definitions, and appropriate security annotations. Naming is verb-forward and clear. The main gaps: (1) parameter descriptions could be more prescriptive about constraints and formats, (2) output schemas are not formally documented in the code (responses are text blobs from the API), and (3) error handling guidance is minimal, tools return raw API responses without LLM-actionable recovery hints. The skill-loading tools are clever meta-tools that guide users through GrowthBook workflows, but lack pagination/limits documentation. Overall solidly above median community servers.
Make an authenticated GET request to the GrowthBook REST API. Use path (+ optional query string) exactly as shown in skill workflows that mention gb-call GET. Paths typically start with /api/v1/ or /api/v2/. Returns the raw response body on success. Queries the GrowthBook REST API — see https://docs.growthbook.io/api (OpenAPI: https://api.growthbook.io/api/v1/openapi.yaml).
Make an authenticated mutating request (POST, PUT, PATCH, or DELETE) to the GrowthBook REST API. Use method + path (+ optional JSON body) exactly as shown in skill workflows that mention gb-call with those methods. Paths typically start with /api/v1/ or /api/v2/. Returns the raw response body on success. Mutates the GrowthBook REST API — see https://docs.growthbook.io/api (OpenAPI: https://api.growthbook.io/api/v1/openapi.yaml).
List available top-level GrowthBook skill entry points (name + description). Call growthbook_read_skill with the relevant name. If the returned skill routes to a qualified child path (e.g. feature-flags/references/flag-create), call growthbook_read_skill again with that path. Skills encode how to accomplish GrowthBook tasks well; use growthbook_api_read / growthbook_api_write to execute the REST calls they describe.
Return the full markdown content of a GrowthBook skill by path. Pass a top-level name from growthbook_list_skills (e.g. feature-flags or flag-create), or a qualified child path named by a skill (e.g. feature-flags/references/flag-create). Follow the skill's workflow; when it shows `gb-call <METHOD> <PATH> [body]`, use growthbook_api_read for GET and growthbook_api_write for POST/PUT/PATCH/DELETE.
Output schemas not formally documented. Tools return raw text (API response body or markdown). LLMs cannot reliably extract structured data or plan downstream calls. For api_read/api_write, document that responses are JSON text; for skill tools, document that responses are JSON arrays or markdown strings.
Parameter 'path' in api_read/api_write lacks format and constraint documentation. Should specify: must start with /api/v1/ or /api/v2/, forbidden characters (if any), example patterns, max length. Currently relies on LLM inference.
Error handling returns raw API errors without recovery guidance. When API returns 400/401/404/500, tool should return structured error with actionable next steps: 'Invalid path. Must start with /api/v1/ or /api/v2/' or 'Authentication failed. Verify GB_API_TOKEN is set.' Currently LLM sees only isError=true and raw text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | 2026-07-28+ | v2 |
| 2026-03-09 | B | 70 | - | v1 |
growthbook_list_skills and growthbook_read_skill lack pagination/limits. If skill tree grows large, list_skills could return hundreds of entries, bloating context. Should document max result count and offer tree search/filtering to prevent context exhaustion.
growthbook_api_write 'body' parameter is described as 'Optional JSON request body as a string'. No guidance on format (is it a JSON string or already an object?), encoding, max size, or validation. Should clarify: 'JSON-encoded string (e.g., {"key": "value"}). Max 1MB. Will be sent as-is in request body.'
No idempotence or confirmation mechanism for destructive operations (DELETE, PUT). Agents can accidentally destroy resources if they retry or misunderstand scope. Consider adding 'dry_run' parameter or explicit confirm pattern for DELETE/PUT.