@db-ux/mcp-server 0.0.0 → 4.5.4-mcp-server-migrate-tool-test-1-eb724df
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CONTEXT.md +132 -0
- package/README.md +379 -0
- package/dist/index.js +37707 -0
- package/package.json +41 -2
package/CONTEXT.md
ADDED
|
@@ -0,0 +1,132 @@
|
|
|
1
|
+
# DB UX Design System – MCP Server
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
This MCP server (Model Context Protocol) gives LLMs (e.g. Amazon Q, GitHub Copilot, Claude) structured access to the UI components and code examples of the DB UX Design System. All communication happens exclusively over **stdio**, so the server can be started as a local child process by any MCP-compatible client.
|
|
6
|
+
|
|
7
|
+
Concrete use cases:
|
|
8
|
+
|
|
9
|
+
- An LLM asks for the API of a component (e.g. `DBButton`) and receives the Mitosis source file along with generated framework outputs.
|
|
10
|
+
- An LLM looks up usage examples for a component in React, Angular, or Vue.
|
|
11
|
+
- An LLM checks which components are available in the design system.
|
|
12
|
+
|
|
13
|
+
## Tech Stack
|
|
14
|
+
|
|
15
|
+
| Technology | Purpose |
|
|
16
|
+
|---|---|
|
|
17
|
+
| **Node.js** (≥ 22) | Runtime environment |
|
|
18
|
+
| **TypeScript** | Type safety, consistent with the rest of the monorepo |
|
|
19
|
+
| **`@modelcontextprotocol/sdk`** | Official MCP SDK — provides `McpServer`, transport classes, and tool/resource primitives |
|
|
20
|
+
| **`tsx`** | Development runner (no separate build step required) |
|
|
21
|
+
| **`esbuild`** | Production build into a single standalone ESM bundle |
|
|
22
|
+
|
|
23
|
+
## Monorepo Structure (relevant to this server)
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
core-web/
|
|
27
|
+
├── packages/
|
|
28
|
+
│ ├── components/ # Mitosis source files (framework-agnostic)
|
|
29
|
+
│ │ └── src/
|
|
30
|
+
│ │ └── components/
|
|
31
|
+
│ │ └── {component}/
|
|
32
|
+
│ │ ├── {component}.lite.tsx # Mitosis component
|
|
33
|
+
│ │ ├── model.ts # Props / types
|
|
34
|
+
│ │ ├── docs/ # Component markdown docs
|
|
35
|
+
│ │ └── showcase/
|
|
36
|
+
│ │ └── {component}.showcase.lite.tsx # Example names
|
|
37
|
+
│ ├── foundations/ # Design tokens, icons, base styles
|
|
38
|
+
│ │ └── src/
|
|
39
|
+
│ │ └── all-icons.ts # Icon name list
|
|
40
|
+
│ │ └── scss/
|
|
41
|
+
│ │ ├── colors/_variables.scss
|
|
42
|
+
│ │ ├── fonts/_variables.scss
|
|
43
|
+
│ │ ├── density/_variables.scss
|
|
44
|
+
│ │ ├── animation/_animations.scss
|
|
45
|
+
│ │ ├── animation/_transitions.scss
|
|
46
|
+
│ │ └── _variables.scss # spacing / sizing
|
|
47
|
+
│ └── mcp-server/ # This package
|
|
48
|
+
│ └── src/
|
|
49
|
+
│ ├── index.ts # Bootstrap — connects transport, registers tools/prompts
|
|
50
|
+
│ ├── server.ts # McpServer singleton and lifecycle handlers
|
|
51
|
+
│ ├── types.ts # Framework type and FRAMEWORK_PKG mapping
|
|
52
|
+
│ ├── build-manifest.ts # Build-time script — generates manifest.json
|
|
53
|
+
│ ├── manifest.json # Generated — do not edit manually
|
|
54
|
+
│ ├── tools/ # Tool handler implementations
|
|
55
|
+
│ ├── prompts/ # Prompt handler implementations
|
|
56
|
+
│ └── utils/ # Shared utilities (path, manifest, formatting, async)
|
|
57
|
+
└── output/
|
|
58
|
+
├── react/ # Generated React code
|
|
59
|
+
│ └── src/components/
|
|
60
|
+
│ └── {component}/
|
|
61
|
+
│ └── examples/ # *.example.tsx
|
|
62
|
+
├── angular/ # Generated Angular code
|
|
63
|
+
│ └── src/components/
|
|
64
|
+
│ └── {component}/
|
|
65
|
+
│ └── examples/ # *.example.ts
|
|
66
|
+
└── vue/ # Generated Vue code
|
|
67
|
+
└── src/components/
|
|
68
|
+
└── {component}/
|
|
69
|
+
└── examples/ # *.example.vue
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## MCP Concepts in This Server
|
|
73
|
+
|
|
74
|
+
### Tools (LLM-callable functions)
|
|
75
|
+
|
|
76
|
+
| Tool | Description |
|
|
77
|
+
|---|---|
|
|
78
|
+
| `list_components` | Returns all available component names |
|
|
79
|
+
| `get_component_props` | Returns the raw `model.ts` content for a component |
|
|
80
|
+
| `get_component_details` | Returns the list of example names from the showcase file |
|
|
81
|
+
| `get_example_code` | Returns generated framework-specific source for a component example |
|
|
82
|
+
| `list_icons` | Returns all valid icon names from `all-icons.ts` |
|
|
83
|
+
| `list_design_token_categories` | Returns all available design token categories |
|
|
84
|
+
| `get_design_tokens` | Returns CSS custom properties and SCSS variables for a token category |
|
|
85
|
+
| `docs_search` | Searches conceptual docs (guidelines, A11y, migration, ADRs) or component-specific markdown docs |
|
|
86
|
+
| `list_migration_guides` | Returns all available migration guide names from the manifest |
|
|
87
|
+
| `get_migration_guide` | Returns the full markdown content of a specific migration guide |
|
|
88
|
+
|
|
89
|
+
### Manifest (embedded data)
|
|
90
|
+
|
|
91
|
+
At build time, `build-manifest.ts` collects all component metadata and example source code into `src/manifest.json`. This file is bundled into the final `index.js` so the server can operate without access to the monorepo source tree — for example when invoked via `npx @db-ux/core-foundations db-ux-mcp` from a consumer project.
|
|
92
|
+
|
|
93
|
+
## Communication
|
|
94
|
+
|
|
95
|
+
The server uses `StdioServerTransport` from the MCP SDK. It is started as a child process by the MCP client:
|
|
96
|
+
|
|
97
|
+
```json
|
|
98
|
+
{
|
|
99
|
+
"mcpServers": {
|
|
100
|
+
"db-ux": {
|
|
101
|
+
"command": "npx",
|
|
102
|
+
"args": ["-y", "@db-ux/mcp-server", "db-ux-mcp"]
|
|
103
|
+
}
|
|
104
|
+
}
|
|
105
|
+
}
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
During development inside the monorepo, `tsx` can be used for live file access:
|
|
109
|
+
|
|
110
|
+
```json
|
|
111
|
+
{
|
|
112
|
+
"mcpServers": {
|
|
113
|
+
"db-ux": {
|
|
114
|
+
"command": "npx",
|
|
115
|
+
"args": ["tsx", "packages/mcp-server/src/index.ts"]
|
|
116
|
+
}
|
|
117
|
+
}
|
|
118
|
+
}
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
## Development
|
|
122
|
+
|
|
123
|
+
```bash
|
|
124
|
+
# Install dependencies (from monorepo root)
|
|
125
|
+
npm install
|
|
126
|
+
|
|
127
|
+
# Start server directly (development mode, live file access)
|
|
128
|
+
npm run dev --workspace=packages/mcp-server
|
|
129
|
+
|
|
130
|
+
# Production build (generates manifest + standalone bundle)
|
|
131
|
+
npm run build --workspace=packages/mcp-server
|
|
132
|
+
```
|
package/README.md
ADDED
|
@@ -0,0 +1,379 @@
|
|
|
1
|
+
# DB UX Model Context Protocol (MCP) Server
|
|
2
|
+
|
|
3
|
+
This server is the connector between AI coding agents (e.g. Amazon Q, GitHub Copilot, Claude) and the DB UX Design System. It gives every AI agent a single, authoritative source of truth — component APIs, framework-specific code examples, design tokens, and icon names — so the agent never has to guess or hallucinate component names, prop signatures, or color values.
|
|
4
|
+
|
|
5
|
+
Without this server, AI agents invent plausible-sounding but incorrect component usage. With it, they pull the exact generated source code that ships in the npm packages. Additionally, through Agent Auto-Recovery (semantic error handling), the server intercepts AI typos and proactively guides the agent to autonomously recover, preventing workflows from crashing.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## 🚀 Quick Start for Consumers
|
|
10
|
+
|
|
11
|
+
> **Requirement:** Node.js **v22.0.0** or higher is required to run the MCP server.
|
|
12
|
+
|
|
13
|
+
### 1. Access the Server
|
|
14
|
+
|
|
15
|
+
Ensure you are using Node.js v22+ and have access to the DB UX packages. The server is invoked via `npx`:
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
npx --yes @db-ux/core-foundations db-ux-mcp
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
> **Crucial Concept:** You do **not** run this command manually in your terminal for daily usage. If you do, it will look like the terminal is hanging because it is waiting for JSON-RPC messages over standard input (`stdio`). Instead, you will configure your IDE (Cursor, VS Code, IntelliJ) to run this command automatically in the background.
|
|
22
|
+
|
|
23
|
+
### 2. Configure your IDE
|
|
24
|
+
|
|
25
|
+
**Important:** Ensure you include the full hierarchy (e.g., `mcp` -> `servers`). Do not add the `db-ux` key directly to the root of your settings file.
|
|
26
|
+
|
|
27
|
+
Add the following entry to your MCP client configuration (VS Code, IntelliJ, Cursor, etc.):
|
|
28
|
+
|
|
29
|
+
```json
|
|
30
|
+
{
|
|
31
|
+
"mcpServers": {
|
|
32
|
+
"db-ux": {
|
|
33
|
+
"command": "npx",
|
|
34
|
+
"args": ["-y", "@db-ux/mcp-server", "db-ux-mcp"]
|
|
35
|
+
}
|
|
36
|
+
}
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
**VS Code** — you have two options:
|
|
41
|
+
|
|
42
|
+
- **Recommended (Project-level):** Create a `.vscode/mcp.json` file in your project root. This allows you to share the MCP config with your team via Git.
|
|
43
|
+
- **Alternative (User-level):** Add the entry to your global `settings.json`.
|
|
44
|
+
|
|
45
|
+
> **Note:** If both exist, the `.vscode/mcp.json` file takes precedence.
|
|
46
|
+
|
|
47
|
+
```json
|
|
48
|
+
{
|
|
49
|
+
"mcp": {
|
|
50
|
+
"servers": {
|
|
51
|
+
"db-ux": {
|
|
52
|
+
"command": "npx",
|
|
53
|
+
"args": ["--yes", "@db-ux/core-foundations", "db-ux-mcp"]
|
|
54
|
+
}
|
|
55
|
+
}
|
|
56
|
+
}
|
|
57
|
+
}
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
**IntelliJ / JetBrains IDEs** — add via *Settings → Tools → AI Assistant → Model Context Protocol → Add Server*. Use these values in the dialog:
|
|
61
|
+
|
|
62
|
+
| Field | Value |
|
|
63
|
+
|---|---|
|
|
64
|
+
| Name | `db-ux` |
|
|
65
|
+
| Type | `stdio` |
|
|
66
|
+
| Command | `npx` |
|
|
67
|
+
| Arguments | `--yes @db-ux/core-foundations db-ux-mcp` |
|
|
68
|
+
|
|
69
|
+
### 3. Add Project Rules (Plan-First Paradigm)
|
|
70
|
+
|
|
71
|
+
Copy the workflow rules file into your project so your AI agent enforces the correct tool-call sequence before writing any UI code. The target location depends on the AI assistant you are using:
|
|
72
|
+
|
|
73
|
+
**For Amazon Q:**
|
|
74
|
+
```bash
|
|
75
|
+
# Creates the directory and downloads the rules
|
|
76
|
+
mkdir -p .amazonq/rules && curl -o .amazonq/rules/db-ux-mcp-workflow.md \
|
|
77
|
+
https://raw.githubusercontent.com/db-ux-design-system/core-web/main/.amazonq/rules/db-ux-mcp-workflow.md
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
**For GitHub Copilot:**
|
|
81
|
+
```bash
|
|
82
|
+
# Creates the directory and downloads the rules
|
|
83
|
+
mkdir -p .github && curl -o .github/copilot-instructions.md \
|
|
84
|
+
https://raw.githubusercontent.com/db-ux-design-system/core-web/main/.amazonq/rules/db-ux-mcp-workflow.md
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
(Note: If you already have a `copilot-instructions.md`, download the file and append its contents to your existing file).
|
|
88
|
+
|
|
89
|
+
**For Cursor:**
|
|
90
|
+
```bash
|
|
91
|
+
# Downloads the rules as your project's Cursor rules
|
|
92
|
+
curl -o .cursorrules \
|
|
93
|
+
https://raw.githubusercontent.com/db-ux-design-system/core-web/main/.amazonq/rules/db-ux-mcp-workflow.md
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
(Note: If you already have a `.cursorrules` file, append the downloaded contents to it).
|
|
97
|
+
|
|
98
|
+
### 4. Verify Connection
|
|
99
|
+
|
|
100
|
+
- **Check Status:** Look for a green indicator or "db-ux" in your IDE's MCP server list.
|
|
101
|
+
- **Check Logs:** If it doesn't appear, check the MCP output logs in your IDE (e.g., in VS Code: *Output Panel* → *MCP* or *MCP Servers*).
|
|
102
|
+
|
|
103
|
+
---
|
|
104
|
+
|
|
105
|
+
## 🛠 Available AI Tools (Skills)
|
|
106
|
+
|
|
107
|
+
| Tool | Description |
|
|
108
|
+
|---|---|
|
|
109
|
+
| `list_components` | Returns all available DB UX component names (e.g. `button`, `input`, `tag`). Call this first to confirm a component exists before using it. |
|
|
110
|
+
| `get_component_props` | Returns the raw TypeScript `model.ts` for a component — all interfaces, prop types, and JSDoc comments. |
|
|
111
|
+
| `get_component_details` | Returns the list of available example names for a component (e.g. `"Variant"`, `"Show Icon Leading"`). |
|
|
112
|
+
| `get_example_code` | Fetches the exact generated source code for a component example in a specific framework (`react`, `angular`, `vue`, `web-components`, or `html`). This is the code the AI adapts — not invents. |
|
|
113
|
+
| `get_design_tokens` | Returns CSS custom properties (`--db-*`) and SCSS variables (`$db-*`) for a token category (`colors`, `spacing`, `typography`, …). Prevents hardcoded hex values and magic numbers. |
|
|
114
|
+
| `list_design_token_categories` | Lists all available token categories to pass to `get_design_tokens`. |
|
|
115
|
+
| `list_icons` | Returns all valid DB UX icon names (e.g. `arrow_down`, `chevron_right`, `x_placeholder`). Always call this before using any `icon` prop — never guess a name. |
|
|
116
|
+
| `docs_search` | Searches the DB UX conceptual documentation (guidelines, A11y, migration, ADRs) or component-specific markdown docs. Acts as our Retrieval-Augmented Generation (RAG) engine. |
|
|
117
|
+
| `list_migration_guides` | Returns all available migration guide names (e.g. `v2.x.x-to-v3.0.0`, `db-ui-to-db-ux-dsv3`). Call this first before any migration task. |
|
|
118
|
+
| `get_migration_guide` | Returns the full markdown content of a specific migration guide. Use this to load official package renames, prop changes, and component workarounds before refactoring legacy code. |
|
|
119
|
+
|
|
120
|
+
### Example: fetching a React button example
|
|
121
|
+
|
|
122
|
+
```
|
|
123
|
+
list_components → confirms "button" exists
|
|
124
|
+
get_component_props → reveals DBButtonProps, variants, types
|
|
125
|
+
get_component_details → lists ["Density", "Variant", "Show Icon Leading", ...]
|
|
126
|
+
get_example_code → returns show-icon-leading.example.tsx source
|
|
127
|
+
list_icons → confirms "arrow_right" is a valid icon name
|
|
128
|
+
get_design_tokens → returns --db-spacing-fixed-md for layout
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
---
|
|
132
|
+
|
|
133
|
+
## 🧠 Available AI Workflows (Prompts)
|
|
134
|
+
|
|
135
|
+
The server exposes predefined Prompts that orchestrate complex cognitive workflows. They force the AI to plan, verify via tools, and analyze before generating output. You can trigger these in your AI chat UI (if supported) or via the MCP Inspector.
|
|
136
|
+
|
|
137
|
+
### `scaffold_page` (Rapid Prototyping)
|
|
138
|
+
Generates the initial structure of a complete web page or complex module.
|
|
139
|
+
* **Parameters:** `page_type`, `framework`, `additional_requirements`.
|
|
140
|
+
* **Behavior:** Enforces the Plan-First paradigm, deconstructing the layout into logical UI blocks and verifying component existence before writing any framework-specific code.
|
|
141
|
+
|
|
142
|
+
### `review_ui_code` (Quality Assurance & A11y)
|
|
143
|
+
Performs a strict multi-layered QA, accessibility, and DB UX compliance audit on a provided code snippet.
|
|
144
|
+
* **Parameters:** `code_snippet`, `framework`.
|
|
145
|
+
* **Behavior:** Scans for hardcoded "magic numbers" and checks WCAG 2.2 AA rules. The AI is forced to provide *evidence* for its critique by calling the design tokens and component API tools.
|
|
146
|
+
|
|
147
|
+
### `migrate_component` (Legacy Refactoring)
|
|
148
|
+
Transforms legacy UI code (e.g., Bootstrap, native HTML, DB UI v1/v2) into the modern DB UX v3/v4 architecture.
|
|
149
|
+
* **Parameters:** `legacy_code`, `source_context`, `target_framework`.
|
|
150
|
+
* **Behavior:** Calls `list_migration_guides` and `get_migration_guide` to dynamically load the relevant migration docs before mapping any component. This ensures all package renames, prop changes, and missing-component workarounds are sourced from the official guides rather than hardcoded knowledge.
|
|
151
|
+
|
|
152
|
+
### `audit_accessibility` (Deep A11y Scan)
|
|
153
|
+
Specialized deep scan exclusively for inclusion and accessibility standards (WCAG 2.2 AA). Goes beyond traditional linters by evaluating interactive patterns, focus orders, and generating manual test scripts.
|
|
154
|
+
* **Parameters:** `code_snippet`, `framework`.
|
|
155
|
+
* **Behavior:** Calls `docs_search` to retrieve global DB UX accessibility guidelines, then verifies how the used components handle ARIA attributes and keyboard events natively. Produces a prioritized WCAG violation list with evidence and a step-by-step manual testing script for QA engineers.
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
## 📐 Architecture & Manifest
|
|
160
|
+
|
|
161
|
+
### How it works
|
|
162
|
+
|
|
163
|
+
The server is a single Node.js process communicating over **stdio** using the [Model Context Protocol](https://modelcontextprotocol.io). It is started as a child process by the MCP client in the IDE.
|
|
164
|
+
|
|
165
|
+
### Build-time manifest
|
|
166
|
+
|
|
167
|
+
Because `model.ts`, showcase files, and framework example source files are **not** included in the published npm packages (only compiled `dist/` is shipped), the server embeds all necessary data at build time.
|
|
168
|
+
|
|
169
|
+
`src/build-manifest.ts` runs during the build and produces `src/manifest.json` containing:
|
|
170
|
+
|
|
171
|
+
```
|
|
172
|
+
manifest.json
|
|
173
|
+
├── icons[] — icon names from packages/foundations/src/all-icons.ts
|
|
174
|
+
├── tokens{} — raw SCSS design tokens mapped by category
|
|
175
|
+
├── docs{} — conceptual markdown documentation
|
|
176
|
+
└── components{}
|
|
177
|
+
└── {componentName}
|
|
178
|
+
├── props — raw model.ts content
|
|
179
|
+
├── examples[] — example names from showcase file
|
|
180
|
+
└── exampleCode
|
|
181
|
+
├── react{} — { "variant.example.tsx": "<source>" }
|
|
182
|
+
├── angular{} — { "variant.example.ts": "<source>" }
|
|
183
|
+
├── vue{} — { "variant.example.vue": "<source>" }
|
|
184
|
+
├── web-components{} — { "variant.example.ts": "<source>" }
|
|
185
|
+
└── html{} — { "index.html": "<source>" }
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
This manifest is bundled into the final `index.js` by esbuild, producing a **~775 KB standalone executable** that carries all component knowledge inside it.
|
|
189
|
+
|
|
190
|
+
### Universal path resolution
|
|
191
|
+
|
|
192
|
+
The server detects its runtime environment automatically:
|
|
193
|
+
|
|
194
|
+
```
|
|
195
|
+
IS_MONOREPO
|
|
196
|
+
true → packages/components/src/components/ exists
|
|
197
|
+
→ reads live files from the monorepo (model.ts, output/, foundations/)
|
|
198
|
+
false → running from node_modules/@db-ux/core-foundations/build/mcp/
|
|
199
|
+
→ reads from the embedded manifest.json
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
This means the same binary works for:
|
|
203
|
+
- **Design system developers** working inside the monorepo (always up-to-date, live files)
|
|
204
|
+
- **Consumer teams** running `npx @db-ux/core-foundations` (self-contained, no monorepo needed)
|
|
205
|
+
|
|
206
|
+
### Directory structure
|
|
207
|
+
|
|
208
|
+
```
|
|
209
|
+
packages/mcp-server/
|
|
210
|
+
├── src/
|
|
211
|
+
│ ├── index.ts # Bootstrap — connects transport, registers tools/prompts
|
|
212
|
+
│ ├── server.ts # McpServer singleton and lifecycle handlers
|
|
213
|
+
│ ├── types.ts # Framework type and FRAMEWORK_PKG mapping
|
|
214
|
+
│ ├── build-manifest.ts # Build-time script — generates manifest.json
|
|
215
|
+
│ ├── tools/ # Tool handler implementations
|
|
216
|
+
│ ├── prompts/ # Prompt handler implementations
|
|
217
|
+
│ └── utils/ # Shared utilities (path, manifest, formatting, async)
|
|
218
|
+
│ └── manifest.json # Generated — do not edit manually
|
|
219
|
+
├── build/
|
|
220
|
+
│ └── index.js # Compiled standalone bundle (gitignored)
|
|
221
|
+
├── esbuild.js # Build script: runs build-manifest, then bundles
|
|
222
|
+
├── package.json
|
|
223
|
+
├── tsconfig.json
|
|
224
|
+
└── CONTEXT.md # Architecture notes
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
---
|
|
228
|
+
|
|
229
|
+
## ⚠️ Defensive Rules for AI
|
|
230
|
+
|
|
231
|
+
These are the **Golden Rules** the AI agent must follow when using this server. They are enforced by the workflow rules file and should be treated as hard constraints, not suggestions.
|
|
232
|
+
|
|
233
|
+
### NEVER use native HTML elements when a DB UX component exists
|
|
234
|
+
|
|
235
|
+
```tsx
|
|
236
|
+
// ❌ WRONG
|
|
237
|
+
<button style="background: #d40000; padding: 8px 16px">Save</button>
|
|
238
|
+
<input type="text" placeholder="Search..." />
|
|
239
|
+
<div style="display: flex; gap: 16px">...</div>
|
|
240
|
+
|
|
241
|
+
// ✅ CORRECT
|
|
242
|
+
<DBButton variant="brand">Save</DBButton>
|
|
243
|
+
<DBInput placeholder="Search..." />
|
|
244
|
+
<DBStack>...</DBStack>
|
|
245
|
+
```
|
|
246
|
+
|
|
247
|
+
| Native element | DB UX replacement |
|
|
248
|
+
|---|---|
|
|
249
|
+
| `<button>` | `DBButton` |
|
|
250
|
+
| `<input>` | `DBInput` |
|
|
251
|
+
| `<select>` | `DBSelect` |
|
|
252
|
+
| `<a>` | `DBLink` |
|
|
253
|
+
| `<textarea>` | `DBTextarea` |
|
|
254
|
+
| `<div>` (layout) | `DBStack`, `DBSection`, `DBCard` |
|
|
255
|
+
|
|
256
|
+
### NEVER use hardcoded colors or magic spacing values
|
|
257
|
+
|
|
258
|
+
```scss
|
|
259
|
+
// ❌ WRONG
|
|
260
|
+
.my-element { color: #ec0016; margin: 15px; gap: 8px; }
|
|
261
|
+
|
|
262
|
+
// ✅ CORRECT — values retrieved via get_design_tokens
|
|
263
|
+
.my-element {
|
|
264
|
+
color: var(--db-color-red-500);
|
|
265
|
+
margin: var(--db-spacing-fixed-sm);
|
|
266
|
+
gap: var(--db-spacing-fixed-xs);
|
|
267
|
+
}
|
|
268
|
+
```
|
|
269
|
+
|
|
270
|
+
### ALWAYS verify props and icon names via MCP tools
|
|
271
|
+
|
|
272
|
+
```tsx
|
|
273
|
+
// ❌ WRONG — icon name invented, prop API assumed
|
|
274
|
+
<DBButton icon="chevronRight" size="large">Next</DBButton>
|
|
275
|
+
|
|
276
|
+
// ✅ CORRECT — icon name from list_icons, props from get_component_props
|
|
277
|
+
<DBButton icon="chevron_right" size="small">Next</DBButton>
|
|
278
|
+
```
|
|
279
|
+
|
|
280
|
+
### ALWAYS call get_example_code before writing component usage
|
|
281
|
+
|
|
282
|
+
The generated examples are the canonical reference. Adapt them — do not rewrite component usage from scratch.
|
|
283
|
+
|
|
284
|
+
---
|
|
285
|
+
|
|
286
|
+
## 📦 Build Command
|
|
287
|
+
|
|
288
|
+
The server is built as part of the `@db-ux/core-foundations` package:
|
|
289
|
+
|
|
290
|
+
```bash
|
|
291
|
+
# from the monorepo root
|
|
292
|
+
npm run build-mcp --workspace=@db-ux/core-foundations
|
|
293
|
+
```
|
|
294
|
+
|
|
295
|
+
This runs `packages/mcp-server/esbuild.js` which:
|
|
296
|
+
|
|
297
|
+
1. Executes `src/build-manifest.ts` — collects all component data from the live monorepo into `src/manifest.json`
|
|
298
|
+
2. Bundles `src/index.ts` + `manifest.json` via esbuild into a single `build/index.js` with `#!/usr/bin/env node` shebang
|
|
299
|
+
3. Copies the bundle to `packages/foundations/build/mcp/index.js` for inclusion in the published `@db-ux/core-foundations` npm package
|
|
300
|
+
|
|
301
|
+
To build and test the server in isolation during development:
|
|
302
|
+
|
|
303
|
+
```bash
|
|
304
|
+
# from packages/mcp-server/
|
|
305
|
+
npm run build # generates manifest + bundle
|
|
306
|
+
npm run dev # runs src/index.ts directly via tsx (monorepo mode, live files). The server communicates over stdio and produces no terminal output by itself — this is expected.
|
|
307
|
+
```
|
|
308
|
+
|
|
309
|
+
---
|
|
310
|
+
|
|
311
|
+
## ❓ Troubleshooting
|
|
312
|
+
|
|
313
|
+
### "Unknown Configuration Setting" in VS Code
|
|
314
|
+
|
|
315
|
+
If you see a yellow squiggle/warning in your `settings.json`, this is expected. Standard VS Code does not natively recognize the `mcp` key yet. As long as your MCP client (like the Claude extension or Cursor) is active, the server will work perfectly.
|
|
316
|
+
|
|
317
|
+
### Server fails to start from the monorepo root (Local Development)
|
|
318
|
+
|
|
319
|
+
If you are developing or testing the MCP server directly from within the DB UX monorepo, the global `npx` command might fail due to npm workspace resolution. In this case, bypass `npx` and point your IDE directly to the local built file.
|
|
320
|
+
|
|
321
|
+
**Fallback IDE Configuration (VS Code/IntelliJ):**
|
|
322
|
+
Instead of using `npx`, use `node` and point it to the local build path (ensure you have run `npm run build` in the `mcp-server` directory first):
|
|
323
|
+
|
|
324
|
+
```json
|
|
325
|
+
{
|
|
326
|
+
"command": "node",
|
|
327
|
+
"args": ["packages/mcp-server/build/index.js"]
|
|
328
|
+
}
|
|
329
|
+
```
|
|
330
|
+
|
|
331
|
+
*Alternatively, you can change your IDE's working directory for the MCP server to `packages/mcp-server`.*
|
|
332
|
+
|
|
333
|
+
---
|
|
334
|
+
|
|
335
|
+
## 🛡️ Security & Compliance
|
|
336
|
+
|
|
337
|
+
This MCP server operates under a strict, zero-trust security model to prevent malicious AI behavior or accidental system damage.
|
|
338
|
+
|
|
339
|
+
* **Strict Read-Only Sandbox:** The server has zero write-permissions. All imports from `node:fs` are strictly read-only (`readFile`, `readdir`). Modules like `child_process` (for shell execution) or file mutation methods (`writeFile`, `unlink`) are completely banned.
|
|
340
|
+
* **Path Traversal Protection (Jailbreak Prevention):** All file and directory accesses (e.g., resolving component names) pass through a cryptographic-style path resolver. The server mathematically guarantees that no file reads can escape the allowed `REPO_ROOT` or `COMPONENTS_DIR` (blocking `../../etc/passwd` attacks).
|
|
341
|
+
* **DoS & Context Window Protection:** To prevent LLMs from crashing or generating massive API billing spikes due to context window overflows, strict token limiters are enforced:
|
|
342
|
+
* File reads are truncated at **20,000 characters**.
|
|
343
|
+
* JSON arrays (like component or icon lists) are truncated at **20,000 characters**.
|
|
344
|
+
* Directory scans are hard-limited to a maximum of **10 files**.
|
|
345
|
+
|
|
346
|
+
---
|
|
347
|
+
|
|
348
|
+
## 🧪 Development & Testing
|
|
349
|
+
|
|
350
|
+
The **MCP Inspector** is the official tool to validate MCP tools and prompts (e.g. `scaffold_page`) independently of any IDE (VS Code, IntelliJ, etc.). Use it to inspect the server's capabilities, test tool calls interactively, and verify prompt outputs before relying on them in an AI agent workflow.
|
|
351
|
+
|
|
352
|
+
### Prerequisites
|
|
353
|
+
|
|
354
|
+
Build the server bundle first (if not already done):
|
|
355
|
+
|
|
356
|
+
```bash
|
|
357
|
+
# from packages/mcp-server/
|
|
358
|
+
npm run build
|
|
359
|
+
```
|
|
360
|
+
|
|
361
|
+
### Starting the Inspector
|
|
362
|
+
|
|
363
|
+
Run the following command from the `packages/mcp-server/` directory:
|
|
364
|
+
|
|
365
|
+
> **Note:** Port 5173 is the default for Vite and Playwright. To avoid conflicts if those are already running, you can specify a different port using the `--port` flag.
|
|
366
|
+
|
|
367
|
+
```bash
|
|
368
|
+
npx @modelcontextprotocol/inspector --port 5178 node build/index.js
|
|
369
|
+
```
|
|
370
|
+
|
|
371
|
+
### Step-by-step workflow
|
|
372
|
+
|
|
373
|
+
1. Run the command above — the Inspector starts a local web server
|
|
374
|
+
2. Open the browser tab it prints (e.g., **http://localhost:5178**)
|
|
375
|
+
3. Navigate to the **"Prompts"** tab to browse and execute interactive prompts like `scaffold_page`
|
|
376
|
+
4. Navigate to the **"Tools"** tab to call individual tools (e.g. `list_components`, `get_example_code`) and inspect their responses
|
|
377
|
+
5. Use the **"Resources"** tab to verify any static resources exposed by the server
|
|
378
|
+
|
|
379
|
+
> **Tip:** The Inspector is framework- and IDE-agnostic. It communicates with the server over stdio exactly as a real MCP client would, making it the most reliable way to catch issues before they surface in an AI agent session.
|