Brand Context MCP Server
# Brand Context MCP Server
An [MCP](https://modelcontextprotocol.io) server that exposes the **Medovia /
ApoSuite** brand guidelines — colors, typography, and component specs (buttons,
forms & fields, tabs, alerts, modals, tables, navigation, logos) — as context
for AI coding agents. Instead of guessing brand values (or re-scraping the
auth-gated portal), an agent can ask this server for the authoritative spec.
The brand data is a **snapshot** captured from the ApoSuite section of the
Medovia varumärkesplattform (the portal is behind Google auth, so it can't be
fetched live). Update [`src/brand.ts`](src/brand.ts) when the portal changes.
## Tools
| Tool | Purpose |
| --- | --- |
| `list_brand_topics` | List the available topics. |
| `get_brand_topic({ topic })` | Full markdown spec for one topic (e.g. `buttons`, `forms-and-fields`, `colors`). |
| `search_brand({ query })` | Keyword search across all topics ("focus color", "hover", "disabled", "radius", "side menu width"). |
| `get_color({ name })` | Look up a color by name/token → hex, CSS token, semantic role. |
It also exposes each topic as a **resource** (`brand://colors`,
`brand://buttons`, …) so it can be `@`-referenced in clients that support
resources.
## Install & build
```bash
cd brand-context-mcp
npm install
npm run build # compiles to dist/
# during development: npm run dev (runs src/index.ts via tsx)
```
## Wire it into Claude Code
Project scope (commit a `.mcp.json` so the team shares it):
```bash
claude mcp add brand-context --scope project -- node /absolute/path/to/brand-context-mcp/dist/index.js
```
Or add it manually to `.mcp.json` / `~/.claude.json`:
```json
{
"mcpServers": {
"brand-context": {
"command": "node",
"args": ["/absolute/path/to/brand-context-mcp/dist/index.js"]
}
}
}
```
For local dev without building, point it at `tsx`:
```json
{
"mcpServers": {
"brand-context": {
"command": "npx",
"args": ["tsx", "/absolute/path/to/brand-context-mcp/src/index.ts"]
}
}
}
```
Then in a session: *"What's the ApoSuite focus color for inputs?"* →
the agent calls `search_brand`/`get_brand_topic` and answers from the spec.
## Quick manual check
The server speaks JSON-RPC over stdio. To smoke-test `tools/list`:
```bash
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"smoke","version":"0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
| node dist/index.js
```
## Topics
`overview`, `colors`, `typography`, `dimensions`, `buttons`,
`forms-and-fields`, `tabs`, `alerts`, `modals`, `tables`, `navigation`, `logos`.
TDQS
Scored across 4 tools
Each tool has a distinct primary purpose: listing topics, fetching a topic spec, searching across topics, and looking up a specific color. Minor overlap exists between get_brand_topic (which could include colors) and get_color, but the descriptions clearly differentiate the specific color lookup from the broader topic retrieval.
All tool names follow a consistent verb_noun snake_case pattern: list_brand_topics, get_brand_topic, search_brand, get_color. The verbs are all common and the nouns clearly indicate the target, with no mixed casing or vague naming.
With only 4 tools, the server is tightly scoped to its purpose: retrieving brand specs and color information. This is within the ideal 3-15 tool range and each tool serves a clear, non-redundant function without feeling sparse or bloated.
The server provides a complete read-only workflow: discover topics, fetch a topic's full spec, search for specific details, and look up individual colors. A minor gap is the absence of a bulk color listing, but search_brand and get_color together cover most practical needs, so no significant dead ends.