Productbrain MCP Server

ProductBrain MCP server

Drive your ProductBrain plan from an MCP client — Claude Desktop, Cursor, Claude Code — with tools for search, read, mutate, the methodology workflow, and the live view.

Design — a thin shim, on purpose

This server is a thin transport over ProductBrain's versioned v1 REST API. Each tool is one call to an existing /api/v1 endpoint. The REST contract stays canonical:

• It's stable when the MCP spec churns — the contract you depend on is the frozen v1 API, not the protocol.
• You can drop to raw HTTP or bring your own LLM at any time; MCP is one front-door, not the only one.
• Responses carry the same in-band _meta coaching the API returns, so your agent self-corrects.

Install

// Claude Desktop — claude_desktop_config.json
{
  "mcpServers": {
    "productbrain": {
      "command": "npx",
      "args": ["-y", "@productbrain-com/mcp"],
      "env": {
        "PRODUCTBRAIN_API_KEY": "pb_your_key",
        "PRODUCTBRAIN_PROJECT_ID": "your-project-id"
      }
    }
  }
}

# Claude Code
claude mcp add productbrain \
  -e PRODUCTBRAIN_API_KEY=pb_your_key \
  -e PRODUCTBRAIN_PROJECT_ID=your-project-id \
  -- npx -y @productbrain-com/mcp

Cursor and other clients: add an mcpServers entry with the same command/args/env.

Config (env)

Tools

Every agent-facing /api/v1 endpoint has a tool. One tool, one endpoint, same _meta coaching passed back verbatim.

The plan

The view

Projects

Webhooks

Share links

Members and budget

Full API reference: https://productbrain.com/docs/llm-guide.md.

Source, licence, registry

• Source: https://github.com/moxzas/productbrain-mcp (MIT). Issues and pull requests welcome there.
• npm: @productbrain-com/mcp. Every release is published from the repository's tag of the same version.
• MCP registry name: io.github.moxzas/productbrain (server.json in this repo is the registry manifest).
• The server sends User-Agent: productbrain-mcp/<version> so you can tell MCP traffic from raw REST calls in your own logs.

Proving it works

Two headless scripts in the repository (src/spike-proof.ts, src/parity-proof.ts; not shipped in the npm package), both run against a real deployment. Use a throwaway project on your own account:

PRODUCTBRAIN_API_KEY=pb_your_key \
PRODUCTBRAIN_PROJECT_ID=your-sandbox-project \
npm run spike     # transport + auth + one read + one write

PRODUCTBRAIN_API_KEY=pb_your_key \
npm run parity    # every non-plan tool once, on a throwaway project

parity creates its own throwaway project and cleans up after itself (archiving it at the end — there is no project-delete endpoint).

The Team-tier tools (add_agent_seat, invite_contributor) return 403 team_tier_required on a Builder key, and that counts as a pass — with one caveat worth knowing. It proves the shim reached the right route and passed the error and its _meta tip straight through; it does not validate the request body, because the tier gate runs before the body is read. Run parity with a Team-tier key to check those two properly.