brandpilot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BRANDPILOT_ORIGIN | No | Target origin - override to point at a local dev server | https://brandpilot.dev |
| DESIGNFLOW_HANDOFF_KEY | No | Default Bearer key for design-scoped tools. Can also be provided per call via handoffKey, which overrides this environment variable. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_systemsA | List the public design systems in the BrandPilot pool (name, slug, brand color, token count, status). |
| get_system_adoptionA | Full adoption manifest for a public system: tokens, components, pages, brand asset URLs and the binding design-direction block. |
| get_system_tokensA | Export a public system's tokens in one format: globals-css, colors-ts, spacing-ts, typography-ts, tailwind-theme or brand-manifest. Calls the legacy /api/systems/export endpoint, not a v1 path - the export route has no v1 equivalent yet. |
| get_agent_promptB | Markdown onboarding doc for a public system: the two copy-paste prompts an external AI coding agent uses to bootstrap a design package and sync it to Claude Design. |
| get_design_handoffA | The design's continuation bundle as JSON: brief, tokens, board digest, the continuation contract (hard floor first, then the latitude level), live inventory, coherence audit and the import contract. Available mid-flow (project paused at EXTERNAL_DESIGN) and post-completion. |
| get_design_prompt_packB | The app-authored sequential Claude Design prompt pack (markdown): anchor sheet first, then template-aware component sheets and page prompts, each embedding the latitude contract in force. Regenerated from live data on every call. |
| import_design_artifactsA | Import externally designed work back into DesignFlow. Rows land as DRAFT on the carrier project's Deliverables tab for human review - nothing auto-approves. Components: self-contained HTML with inline styles. Pages: standalone HTML documents. Assets: PNG (base64 or URL) with optional sourceCode. |
| finish_external_designA | Validates that components and pages were imported, optionally accepts every pending imported draft, then resumes the pipeline at the coherence audit toward Design Review. Only valid while the project is paused at EXTERNAL_DESIGN. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
The tools are mostly distinct, but get_design_prompt_pack and get_design_handoff both return design-related documentation, and get_system_adoption and get_system_tokens both retrieve system data. Descriptions clarify formats and content, so an agent should be able to tell them apart with careful reading.
All tools follow a consistent verb_noun snake_case pattern: get, list, import, finish. The nouns are descriptive compounds, and no mixing of conventions or vague verbs appears.
With 8 tools, the server is well-scoped for its design-system purpose. Each tool serves a clear role—retrieval for various system artifacts, plus import and completion actions—without redundancy or bloat.
The set covers the external design import workflow well, from listing and retrieving system data to importing artifacts and finishing the pipeline. Minor gaps exist (e.g., no explicit project listing or system creation), but they don't block the core intended flow.