
BrandKit MCP
io.github.ejwhite7Published by GitHub account ejwhite7v2.1.0Updated Oct 24, 2026
Brand atomic system over MCP: verbal, visual, motion, tokens, and a magic_trick taste primer.
Overview
Serves a company's brand atomic system — verbal, visual, tokens and motion — to AI assistants as read-only MCP tools and resources.
- What you can do
- Read verbal identity: positioning, audience, messaging, differentiation, concepts and voice, each carrying a human-authored taste primer
- Read visual identity: colors and typography, fonts, assets, components, tokens and motion
- Search the brand full-text, validate usage against brand rules, and diff base versus web and product contexts
- Browse the same content as brand:// resources
- Update config and generated design/product docs with a local write tool (stdio only)
- When to use it
- Useful when an assistant helps build websites, apps or marketing assets and should follow a specific company's exact brand language and visual rules instead of generic styling. Best for teams that keep brand material in a structured local directory.
- Requirements
- Runs locally as an npm package via npx or a global install, so Node.js is needed. Requires a brandkit.config.yaml with version 2 and a brand root directory, scaffolded with the init command. No accounts or API keys for stdio use; network transports need BRANDKIT_AUTH_TOKEN and host/origin settings.
Installation
In SourceWeft
- Open BrandKit MCP in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
BrandKit MCP
Give every AI tool access to your company's complete brand atomic system via the Model Context Protocol.
[npm version] [License: MIT] [Node 20+] [TypeScript] [ejwhite7/brandkit-mcp MCP server]
BrandKit MCP v2 is an open-source MCP server that exposes a company's complete brand atomic system -- verbal identity (positioning, audience, messaging, differentiation, concepts, voice) and visual identity (colors, typography, components, tokens, motion, assets) -- to Claude and other AI tools via the Model Context Protocol (MCP). It ships 18 read-only tools, one local write tool, and 14 resources. When an LLM helps build a website, app, or marketing asset, it has instant structured access to the exact brand language and visual rules it needs -- including a human-authored taste primer that carries the brand's instincts, not just its specs.
Quick Start
init refuses to change an existing brandkit.config.yaml or
brand_atomic_system/ unless --force is explicit. Force performs a clean
replacement only for a regular single-link config and a real directory;
symbolic links, hard-linked configs, and special-file destinations are rejected.
Repository Structure
A brand atomic system lives under a single <brand-root>/ directory (default: ./brand_atomic_system):
The human/ directory is intentionally ignored by the MCP server -- put PDFs, print specs, or any other human-only material there. Everything under agent/ is indexed and served.
MCP Tools Reference
BrandKit MCP exposes 18 tools to AI assistants:
The stdio transport also exposes sync_brand_docs, which updates brandkit.config.yaml, DESIGN.md, and PRODUCT.md. Network transports hide and refuse this write-capable tool by default.
Taste primer
Seven creative/verbal tools (get_brand_overview, get_positioning, get_audience, get_messaging, get_differentiation, get_concepts, get_voice) inject a _taste_primer field carrying magic_trick.md verbatim. get_magic_trick returns the primer directly without wrapping.
MCP Resources
BrandKit MCP exposes 14 brand:// URIs as MCP resources:
Configuration
The brandkit.config.yaml file at your project root controls BrandKit MCP:
Ignore entries are paths relative to brand.root. They match the named path and its descendants
on directory boundaries, so human/ does not match humanity/.
Brand ingestion is bounded before file content is read. The defaults allow a
maximum of 16 MiB per file, 128 MiB across all unique inputs, 1,000 unique
files, and 16 path segments below brand.root. Fixed documents, discovered
components and tokens, manifests, fonts, and image assets all share the same
budget. Directory enumeration is also capped at four times the configured file
limit, so a tree of empty or unsupported entries cannot create unbounded work
before file counting. In-root symlink and hard-link aliases count once by canonical file
identity; an alias cannot bypass containment or a limit. Exact boundaries are
accepted and the next byte, file, or path segment fails startup with a
brand-relative error. Large brands can raise these typed ingestion values up
to the built-in safety caps (64 MiB per file, 512 MiB total, 10,000 files, and
64 segments); maxTotalBytes must be at least maxFileBytes.
version: 2 is required. A config file missing this field or declaring version: 1 causes the server to throw BrandkitV1ConfigError at startup.
Context System
BrandKit v2 supports three contexts:
Verbal content (agent/verbal/) has no context overrides -- it applies globally. Visual content can be overridden per context via the artifacts/ layer.
Migrating from v1
2.0.0 is a breaking release. The directory layout, context vocabulary, and tool surface have all changed. No automated migration is included -- the path mapping is manual:
Your brandkit.config.yaml must also be updated to declare version: 2 and use the new brand.root field. v1 configs throw BrandkitV1ConfigError at startup -- the server will not start until the config is updated.
Conventions
magic_trick.md is human-authored. The MCP reads it, but sync_brand_docs never writes to it. The taste primer is the brand's instincts -- it must stay human.
Token output formats. The get_tokens tool supports CSS custom properties, SCSS variables, Tailwind config, W3C Design Tokens, and flat JSON.
Brand files stay inside brand.root. Every fixed and discovered brand input is resolved and opened under the configured root. A symlink is accepted when its final target remains inside that root; symlinks and manifest paths that escape the root are ignored with a warning, and their content is never indexed or exposed through tools, resources, or preview pages.
The config must be a regular, single-link file. brandkit.config.yaml cannot be a symbolic link, hard link, directory, or other non-regular entry. The server binds config persistence to the file loaded at startup; if that path is replaced while the server is running, sync_brand_docs refuses to read or overwrite the replacement. Successful config updates use an atomic same-directory replacement and preserve existing permissions.
Transports. The server supports stdio (recommended for Claude Desktop), SSE (legacy HTTP), and Streamable HTTP (current MCP spec). Network transports remain unauthenticated when bound to loopback for local development. Before binding SSE or HTTP to any non-loopback host, set BRANDKIT_AUTH_TOKEN; clients must send it as Authorization: Bearer <token> on every request.
Network transports are read-only by default, including loopback, standalone, and Vercel deployments. To deliberately expose sync_brand_docs over SSE or Streamable HTTP, start the CLI with brandkit-mcp serve --transport http --allow-write-tools (or set allowWriteTools: true in the programmatic startServer options). Treat this as privileged mode: authentication is still mandatory for non-loopback binds. Stdio keeps the intended local write workflow without this flag. Adapters without a writable config context never advertise the tool, even if privileged mode is requested.
Every network transport rejects untrusted Host and Origin headers with HTTP 403. Loopback listeners automatically trust loopback hostnames and origins, including IPv4, IPv6, and ephemeral ports. A concrete non-loopback server.host derives trust for that exact hostname. Wildcard bindings (0.0.0.0 or ::) fail at startup unless server.allowedHosts is explicit:
allowedOrigins entries are exact HTTP(S) origins, including the port when it is non-default. If the list is empty, requests without an Origin header remain valid for MCP clients, while a supplied Origin must use a trusted Host hostname. Configure allowedOrigins explicitly when a browser application is hosted on a different origin. IPv6 entries in allowedHosts use brackets, for example [2001:db8::10].
The preview UI is deliberately loopback-only and refuses any wildcard, LAN, or public bind host. It also applies the same Host and Origin validation to every page and static asset. Use the authenticated MCP HTTP transport when data must be available beyond the local machine.
Docker Compose
The default Compose service runs the supported Streamable HTTP transport on http://127.0.0.1:3001/mcp. It uses the bundled Acme example, so a fresh checkout does not require host-side brand files. Set a bearer token before starting it:
The token is injected at runtime and is also required by the authenticated health check. Compose refuses to start when it is absent. To use your own brand, mount a regular config file and brand directory, set BRANDKIT_CONFIG to the container path of that config, and keep server.allowedHosts limited to the hostnames clients actually use. Do not put the token in the image or config file. Compose intentionally exposes only the authenticated MCP service; run the preview CLI separately on a trusted local machine. Existing stdio container integrations can override the image command with node /app/dist/cli/index.js serve --transport stdio --config <path> and do not need to publish a port.
Vercel
The repository includes one stateless Node.js Function at /api/mcp. Set
BRANDKIT_AUTH_TOKEN in every Vercel environment and send it as a Bearer token.
Vercel's VERCEL_URL and VERCEL_PROJECT_PRODUCTION_URL are trusted
automatically. For a custom domain, set BRANDKIT_ALLOWED_HOSTS to a
comma-separated hostname list, without schemes or paths.
The default deployment explicitly bundles templates/starter/** and serves
that data read-only. To deploy another brand, set BRANDKIT_CONFIG to its
repository-relative config path and update functions.api/mcp.js.includeFiles
in vercel.json to include both that config and its complete brand root. Vercel
runtime files are immutable; the function never advertises sync_brand_docs.
Each request creates and closes its own MCP server and transport, so requests do
not depend on a warm instance or session affinity.
CLI Reference
serve accepts --transport <stdio|sse|http>, --host <host>, --port <number>, --config <path>, --watch, and the privileged network option --allow-write-tools.
Contributing
Contributions are welcome.
- TypeScript strict mode
- ESM imports with
.jsextensions - No
anytypes -- use proper interfaces - Tests use Vitest
License
MIT -- see LICENSE for details.
Built with the Model Context Protocol by Anthropic.
Source: README.md at commit 6e92ec2
Tools
0Version history
1- v2.1.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts