@redsift/ds-mcp-server 12.3.1-muiv6-alpha.2

package/README.md

@@ -0,0 +1,203 @@
+# Red Sift Design System — MCP Server
+
+A [Model Context Protocol](https://modelcontextprotocol.io/) (MCP) server that gives AI assistants deep knowledge of the Red Sift Design System. It provides tools for component search, prop documentation, code generation, design token lookup, and composition pattern guidance.
+
+## Quick Start
+
+```bash
+# From the design-system repo root:
+yarn mcp:build    # Build the server
+yarn mcp:start    # Run (production)
+yarn mcp:dev      # Run (development, no build needed)
+```
+
+The server uses **stdio transport** — it communicates over stdin/stdout and is designed to be launched by an AI client (VS Code, Claude Desktop, etc.), not run as a standalone HTTP server.
+
+## Architecture
+
+```
+scripts/extract-component-docs.ts
+    ↓  yarn extract:docs
+docs/components.json, components-index.json, patterns.json, patterns-catalog.md
+    ↓  loaded at startup
+DataStore, TokenStore, PatternStore
+    ↓  queried by
+Tools (10) + Resources (7) + Prompts (7)
+    ↓  exposed via
+MCP stdio transport → AI client
+```
+
+### Data Flow
+
+1. **`yarn extract:docs`** parses the component source files and generates machine-readable documentation in `docs/`.
+2. At startup, the MCP server loads `docs/components.json`, `docs/components-index.json`, `docs/patterns.json`, and `docs/patterns-catalog.md` into in-memory stores.
+3. AI clients call tools, read resources, and use prompts — all backed by the stores.
+
+**Important:** If you add or change components, run `yarn extract:docs` to regenerate the data the MCP server sees.
+
+## Tools
+
+| Tool                          | Description                                           | Key Parameters                                           |
+| ----------------------------- | ----------------------------------------------------- | -------------------------------------------------------- |
+| `search_components`           | Search components by name, description, or keyword    | `query`, `package?`, `limit?`                            |
+| `get_component_props`         | Get full prop documentation grouped by category       | `name`, `package?`                                       |
+| `get_component_usage`         | Get import statement and minimal JSX example          | `name`, `package?`                                       |
+| `list_packages`               | List all packages with component counts               | —                                                        |
+| `generate_component_scaffold` | Generate all 6 boilerplate files for a new component  | `name`, `package?`, `element?`, `description?`, `props?` |
+| `search_design_tokens`        | Search design tokens by name, value, or CSS variable  | `query`, `category?`, `limit?`                           |
+| `get_design_tokens`           | Get all tokens for a category                         | `category`                                               |
+| `get_css_variables`           | Find CSS custom properties by component or token type | `pattern`, `limit?`                                      |
+| `update_changelog`            | Generate a formatted CHANGELOG.md entry               | `type`, `package`, `description`                         |
+| `search_patterns`             | Search composition patterns for common UI scenarios   | `query`, `limit?`                                        |
+
+## Resources
+
+| URI                                           | Description                                                                 |
+| --------------------------------------------- | --------------------------------------------------------------------------- |
+| `design-system://llms.txt`                    | Lightweight overview of all components for initial orientation              |
+| `design-system://llms-full.txt`               | Complete documentation for all 170+ components                              |
+| `design-system://conventions`                 | Component structure conventions, naming rules, coding patterns              |
+| `design-system://usage-rules`                 | Mandatory lookup rules for consuming projects (prevents prop hallucination) |
+| `design-system://components/{package}/{name}` | Full JSON documentation for a specific component                            |
+| `design-system://patterns-catalog`            | Markdown catalog of all composition patterns                                |
+| `design-system://patterns/{slug}`             | Full pattern spec: anatomy, state hooks, data contracts, demo code          |
+
+## Prompts
+
+| Prompt             | Description                                         | Key Arguments                                                        |
+| ------------------ | --------------------------------------------------- | -------------------------------------------------------------------- |
+| `create-component` | Step-by-step guide to scaffold a new component      | `name`, `package?`, `element?`, `description?`                       |
+| `add-prop`         | Guide to add a prop across all component files      | `component`, `propName`, `propType`, `required?`, `defaultValue?`    |
+| `build-form`       | Generate a form composition from field definitions  | `fields`, `submitLabel?`, `layout?`                                  |
+| `pr-description`   | Generate a PR description from the repo template    | `title`, `changes`, `issueNumber?`, `packages?`                      |
+| `implement-ui`     | Build a UI from a description using proven patterns | `description`, `target?`                                             |
+| `create-pattern`   | Create a new pattern page for the website           | `name`, `description`, `components`, `relatedPatterns?`, `variants?` |
+| `add-demo`         | Create a demo file for the documentation website    | `patternSlug`, `variant`, `description`                              |
+
+## Using in Other Projects
+
+The MCP server runs locally from this repo and is available to any AI tool on your machine. It does **not** need to be installed in the consuming project.
+
+### VS Code (Copilot Chat) — Recommended
+
+Add to the consuming project's `.vscode/mcp.json`:
+
+```json
+{
+  "servers": {
+    "design-system": {
+      "type": "stdio",
+      "command": "node",
+      "args": ["/absolute/path/to/design-system/apps/mcp-server/dist/index.js"]
+    }
+  }
+}
+```
+
+> **Tip:** Run `yarn mcp:build` in this repo first. For a build-free setup, use `tsx`:
+>
+> ```json
+> {
+>   "servers": {
+>     "design-system": {
+>       "type": "stdio",
+>       "command": "npx",
+>       "args": ["tsx", "/absolute/path/to/design-system/apps/mcp-server/src/index.ts"]
+>     }
+>   }
+> }
+> ```
+
+### Claude Desktop
+
+Add to `~/Library/Application Support/Claude/claude_desktop_config.json`:
+
+```json
+{
+  "mcpServers": {
+    "design-system": {
+      "command": "node",
+      "args": ["/absolute/path/to/design-system/apps/mcp-server/dist/index.js"]
+    }
+  }
+}
+```
+
+### Any MCP-compatible Client
+
+The server uses stdio transport. Point any MCP client at:
+
+```
+node /absolute/path/to/design-system/apps/mcp-server/dist/index.js
+```
+
+### Forcing Correct Usage (Preventing Hallucination)
+
+LLMs often guess component props based on other design systems (MUI, Chakra, etc.). To force them to look up the actual API, copy one of the instruction files from `consumer-instructions/` into your project:
+
+| File                                    | Target          | Where to place it                       |
+| --------------------------------------- | --------------- | --------------------------------------- |
+| `redsift-design-system.instructions.md` | VS Code Copilot | `.github/instructions/` in your project |
+| `CLAUDE.md`                             | Claude Code     | Project root                            |
+| `.cursorrules`                          | Cursor          | Project root                            |
+
+These files contain mandatory rules that tell the AI to call `get_component_props` before using any `@redsift/*` component.
+
+## Development
+
+### Source Files
+
+| File                   | Purpose                                                   |
+| ---------------------- | --------------------------------------------------------- |
+| `src/index.ts`         | Server entry point, store initialization, stdio transport |
+| `src/tools.ts`         | All MCP tool registrations                                |
+| `src/resources.ts`     | All MCP resource registrations                            |
+| `src/prompts.ts`       | All MCP prompt registrations                              |
+| `src/data-store.ts`    | Component data loading, search, and lookup                |
+| `src/token-store.ts`   | Design token loading and search                           |
+| `src/pattern-store.ts` | Pattern loading, search, and demo code extraction         |
+| `src/scaffold.ts`      | Component boilerplate generation                          |
+| `src/types.ts`         | Shared TypeScript interfaces                              |
+
+### Adding a New Tool
+
+1. Open `src/tools.ts`
+2. Add a `server.tool(...)` call inside `registerTools()`
+3. Follow the existing pattern: name, schema with `z.object(...)`, description, handler
+4. Rebuild: `yarn mcp:build`
+
+### Adding a New Resource
+
+1. Open `src/resources.ts`
+2. Add a `server.resource(...)` call inside `registerResources()`
+3. For static resources, use a direct URI. For templates, use `new ResourceTemplate(...)`
+4. Rebuild: `yarn mcp:build`
+
+### Adding a New Prompt
+
+1. Open `src/prompts.ts`
+2. Add a `server.registerPrompt(...)` call inside `registerPrompts()`
+3. Define `argsSchema` with Zod and return `{ messages: [...] }`
+4. Rebuild: `yarn mcp:build`
+
+### Updating Data
+
+When components are added, removed, or modified:
+
+```bash
+yarn extract:docs   # Regenerate docs/components.json, etc.
+yarn mcp:build      # Rebuild the server
+```
+
+### Testing
+
+Use the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) to test tools and resources interactively:
+
+```bash
+npx @modelcontextprotocol/inspector node apps/mcp-server/dist/index.js
+```
+
+Or verify in VS Code by opening Copilot Chat and asking:
+
+- "Search for button components in the design system" → should call `search_components`
+- "What props does DataGrid accept?" → should call `get_component_props`

package/consumer-instructions/.cursorrules

@@ -0,0 +1,80 @@
+# Red Sift Design System — Mandatory Lookup Rules
+
+> **This file is for projects that consume the Red Sift Design System.** It ensures your AI assistant uses the MCP server to look up component APIs instead of guessing.
+
+This project uses the **Red Sift Design System** (`@redsift/*` packages). The design system has its own prop names, variants, and API conventions that **differ from other component libraries** (MUI, Chakra, Ant Design, Radix, etc.).
+
+**DO NOT guess or infer component props.** Always look them up using the `design-system` MCP server.
+
+## Setup Checklist
+
+1. Configure the MCP server — see [MCP Server docs](https://design-system.redsift.io/introduction/mcp-server)
+2. Copy this file to your project root as `.cursorrules`
+3. Verify: ask the AI _"What props does Button accept?"_ — it should call `get_component_props`, not answer from memory
+
+## Rule 1 — Mandatory Prop Lookup
+
+Before using ANY component from `@redsift/design-system`, `@redsift/icons`, `@redsift/popovers`, `@redsift/pickers`, `@redsift/table`, `@redsift/charts`, `@redsift/dashboard`, or `@redsift/products`:
+
+1. Call `get_component_props` to look up the exact props, types, accepted values, and defaults.
+2. **Only use prop values that appear in the returned documentation.**
+3. If a prop you expect is NOT listed, it does not exist — do not add it.
+
+**Why:** The Red Sift DS uses custom prop names and variants. Guessing based on other libraries will produce incorrect code.
+
+## Rule 2 — Import Verification
+
+Always call `get_component_usage` to get the correct import path and package. Components may live in different packages than expected (e.g., `Select` is in `@redsift/pickers`, not `@redsift/design-system`).
+
+## Rule 3 — Pattern Lookup for Page Layouts
+
+When building a page layout, complex form, data table page, or any multi-component composition:
+
+1. Call `search_patterns` to check for an existing proven pattern.
+2. If a match exists, fetch the full spec with the `design-system://patterns/{slug}` resource — it includes state management hooks, data contracts, implementation checklists, and complete working code.
+
+## Rule 4 — Design Token Lookup
+
+When applying colors, spacing, or typography:
+
+1. Call `search_design_tokens` to find the correct token names and CSS custom properties.
+2. Do not hardcode color hex values — use the design token CSS variables.
+
+## Common Mistakes
+
+These are real examples of props that do NOT exist in the Red Sift DS:
+
+- `variant="primary"` → Look up actual variants with `get_component_props`
+- `size="sm"` / `size="lg"` → Most components have no size prop — verify with `get_component_props`
+- `colorScheme="red"` → Does not exist
+- `isDisabled` → Use `disabled`
+- `onPress` → Use `onClick`
+- `import { Select } from '@redsift/design-system'` → Should be `@redsift/pickers`
+- `import { Dialog } from '@redsift/design-system'` → Should be `@redsift/popovers`
+- `import { DataGrid } from '@redsift/design-system'` → Should be `@redsift/table`
+
+## NEVER Do This
+
+```tsx
+// ❌ WRONG — Button has NO size prop
+<Button size="small">Save</Button>
+
+// ❌ WRONG — "primary" is not a valid variant
+<Button variant="primary">Save</Button>
+
+// ❌ WRONG — these props do not exist
+<TextField colorScheme="red" />
+<Button isDisabled />
+<Button onPress={() => {}} />
+
+// ❌ WRONG — wrong package
+import { Select } from '@redsift/design-system';
+```
+
+## Verification
+
+Test that your AI assistant is using the MCP server correctly with these prompts:
+
+1. _"What props does Button accept?"_ → Should call `get_component_props`, NOT answer from memory
+2. _"Import the Select component"_ → Should call `get_component_usage`, return `@redsift/pickers`
+3. _"Create a data table page"_ → Should call `search_patterns` first, then follow the pattern spec

package/consumer-instructions/.windsurfrules

@@ -0,0 +1,80 @@
+# Red Sift Design System — Mandatory Lookup Rules
+
+> **This file is for projects that consume the Red Sift Design System.** It ensures your AI assistant uses the MCP server to look up component APIs instead of guessing.
+
+This project uses the **Red Sift Design System** (`@redsift/*` packages). The design system has its own prop names, variants, and API conventions that **differ from other component libraries** (MUI, Chakra, Ant Design, Radix, etc.).
+
+**DO NOT guess or infer component props.** Always look them up using the `design-system` MCP server.
+
+## Setup Checklist
+
+1. Configure the MCP server — see [MCP Server docs](https://design-system.redsift.io/introduction/mcp-server)
+2. Copy this file to your project root as `.cursorrules`
+3. Verify: ask the AI *"What props does Button accept?"* — it should call `get_component_props`, not answer from memory
+
+## Rule 1 — Mandatory Prop Lookup
+
+Before using ANY component from `@redsift/design-system`, `@redsift/icons`, `@redsift/popovers`, `@redsift/pickers`, `@redsift/table`, `@redsift/charts`, `@redsift/dashboard`, or `@redsift/products`:
+
+1. Call `get_component_props` to look up the exact props, types, accepted values, and defaults.
+2. **Only use prop values that appear in the returned documentation.**
+3. If a prop you expect is NOT listed, it does not exist — do not add it.
+
+**Why:** The Red Sift DS uses custom prop names and variants. Guessing based on other libraries will produce incorrect code.
+
+## Rule 2 — Import Verification
+
+Always call `get_component_usage` to get the correct import path and package. Components may live in different packages than expected (e.g., `Select` is in `@redsift/pickers`, not `@redsift/design-system`).
+
+## Rule 3 — Pattern Lookup for Page Layouts
+
+When building a page layout, complex form, data table page, or any multi-component composition:
+
+1. Call `search_patterns` to check for an existing proven pattern.
+2. If a match exists, fetch the full spec with the `design-system://patterns/{slug}` resource — it includes state management hooks, data contracts, implementation checklists, and complete working code.
+
+## Rule 4 — Design Token Lookup
+
+When applying colors, spacing, or typography:
+
+1. Call `search_design_tokens` to find the correct token names and CSS custom properties.
+2. Do not hardcode color hex values — use the design token CSS variables.
+
+## Common Mistakes
+
+These are real examples of props that do NOT exist in the Red Sift DS:
+
+- `variant="primary"` → Look up actual variants with `get_component_props`
+- `size="sm"` / `size="lg"` → Most components have no size prop — verify with `get_component_props`
+- `colorScheme="red"` → Does not exist
+- `isDisabled` → Use `disabled`
+- `onPress` → Use `onClick`
+- `import { Select } from '@redsift/design-system'` → Should be `@redsift/pickers`
+- `import { Dialog } from '@redsift/design-system'` → Should be `@redsift/popovers`
+- `import { DataGrid } from '@redsift/design-system'` → Should be `@redsift/table`
+
+## NEVER Do This
+
+```tsx
+// ❌ WRONG — Button has NO size prop
+<Button size="small">Save</Button>
+
+// ❌ WRONG — "primary" is not a valid variant
+<Button variant="primary">Save</Button>
+
+// ❌ WRONG — these props do not exist
+<TextField colorScheme="red" />
+<Button isDisabled />
+<Button onPress={() => {}} />
+
+// ❌ WRONG — wrong package
+import { Select } from '@redsift/design-system';
+```
+
+## Verification
+
+Test that your AI assistant is using the MCP server correctly with these prompts:
+
+1. *"What props does Button accept?"* → Should call `get_component_props`, NOT answer from memory
+2. *"Import the Select component"* → Should call `get_component_usage`, return `@redsift/pickers`
+3. *"Create a data table page"* → Should call `search_patterns` first, then follow the pattern spec

package/consumer-instructions/CLAUDE.md

@@ -0,0 +1,87 @@
+# Red Sift Design System — Mandatory Lookup Rules
+
+> **This file is for projects that consume the Red Sift Design System.** It ensures your AI assistant uses the MCP server to look up component APIs instead of guessing.
+
+This project uses the **Red Sift Design System** (`@redsift/*` packages). The design system has its own prop names, variants, and API conventions that **differ from other component libraries** (MUI, Chakra, Ant Design, Radix, etc.).
+
+**DO NOT guess or infer component props.** Always look them up using the `design-system` MCP server.
+
+## Setup Checklist
+
+1. Configure the MCP server — see [MCP Server docs](https://design-system.redsift.io/introduction/mcp-server)
+2. Copy this file to your project root as `CLAUDE.md`
+3. Verify: ask the AI _"What props does Button accept?"_ — it should call `get_component_props`, not answer from memory
+
+## Rule 1 — Mandatory Prop Lookup
+
+Before using ANY component from `@redsift/design-system`, `@redsift/icons`, `@redsift/popovers`, `@redsift/pickers`, `@redsift/table`, `@redsift/charts`, `@redsift/dashboard`, or `@redsift/products`:
+
+1. Call `get_component_props` to look up the exact props, types, accepted values, and defaults.
+2. **Only use prop values that appear in the returned documentation.**
+3. If a prop you expect is NOT listed, it does not exist — do not add it.
+
+**Why:** The Red Sift DS uses custom prop names and variants. Guessing based on other libraries will produce incorrect code.
+
+## Rule 2 — Import Verification
+
+Always call `get_component_usage` to get the correct import path and package. Components may live in different packages than expected (e.g., `Select` is in `@redsift/pickers`, not `@redsift/design-system`).
+
+## Rule 3 — Pattern Lookup for Page Layouts
+
+When building a page layout, complex form, data table page, or any multi-component composition:
+
+1. Call `search_patterns` to check for an existing proven pattern.
+2. If a match exists, fetch the full spec with the `design-system://patterns/{slug}` resource — it includes state management hooks, data contracts, implementation checklists, and complete working code.
+
+## Rule 4 — Design Token Lookup
+
+When applying colors, spacing, or typography:
+
+1. Call `search_design_tokens` to find the correct token names and CSS custom properties.
+2. Do not hardcode color hex values — use the design token CSS variables.
+
+## NEVER Do This
+
+These are concrete examples of wrong code. **Every single one will fail:**
+
+```tsx
+// ❌ WRONG — Button has NO size prop
+<Button size="small">Save</Button>
+
+// ❌ WRONG — "primary" is not a valid variant
+<Button variant="primary">Save</Button>
+
+// ❌ WRONG — these props do not exist
+<TextField colorScheme="red" />
+<Button isDisabled />
+<Button onPress={() => {}} />
+
+// ❌ WRONG — wrong package
+import { Select } from '@redsift/design-system';
+```
+
+## Common Mistakes
+
+| Wrong (guessed)                                     | Correct (actual)                             | How to verify                           |
+| --------------------------------------------------- | -------------------------------------------- | --------------------------------------- |
+| `variant="primary"`                                 | Look up actual variants                      | `get_component_props` for the component |
+| `size="sm"` / `size="lg"`                           | Most components have no size prop            | `get_component_props` for the component |
+| `colorScheme="red"`                                 | Does not exist                               | `get_component_props` for the component |
+| `isDisabled`                                        | `disabled`                                   | `get_component_props` for the component |
+| `onPress`                                           | `onClick`                                    | `get_component_props` for the component |
+| `leftIcon` / `rightIcon`                            | Look up actual icon prop names               | `get_component_props` for the component |
+| `import { Select } from '@redsift/design-system'`   | `import { Select } from '@redsift/pickers'`  | `get_component_usage`                   |
+| `import { Dialog } from '@redsift/design-system'`   | `import { Dialog } from '@redsift/popovers'` | `get_component_usage`                   |
+| `import { DataGrid } from '@redsift/design-system'` | `import { DataGrid } from '@redsift/table'`  | `get_component_usage`                   |
+
+## Verification
+
+Test that your AI assistant is using the MCP server correctly with these prompts:
+
+1. _"What props does Button accept?"_ → Should call `get_component_props`, NOT answer from memory
+2. _"Import the Select component"_ → Should call `get_component_usage`, return `@redsift/pickers`
+3. _"Create a data table page"_ → Should call `search_patterns` first, then follow the pattern spec
+
+## MCP Server Setup
+
+This file assumes the `design-system` MCP server is configured. See the [MCP Server documentation](https://design-system.redsift.io/introduction/mcp-server) for setup instructions.

package/consumer-instructions/redsift-design-system.instructions.md

@@ -0,0 +1,87 @@
+---
+applyTo: '**/*.{tsx,jsx}'
+---
+
+# Red Sift Design System — Mandatory Lookup Rules
+
+> **This file is for projects that consume the Red Sift Design System.** It ensures your AI assistant uses the MCP server to look up component APIs instead of guessing.
+
+This project uses the **Red Sift Design System** (`@redsift/*` packages). The design system has its own prop names, variants, and API conventions that **differ from other component libraries** (MUI, Chakra, Ant Design, Radix, etc.).
+
+**DO NOT guess or infer component props.** Always look them up using the `design-system` MCP server.
+
+## Setup Checklist
+
+1. Configure the MCP server in `.vscode/mcp.json` — see [MCP Server docs](https://design-system.redsift.io/introduction/mcp-server)
+2. Copy this file to `.github/instructions/` in your project
+3. Verify: ask the AI _"What props does Button accept?"_ — it should call `get_component_props`, not answer from memory
+
+## Rule 1 — Mandatory Prop Lookup
+
+Before using ANY component from `@redsift/design-system`, `@redsift/icons`, `@redsift/popovers`, `@redsift/pickers`, `@redsift/table`, `@redsift/charts`, `@redsift/dashboard`, or `@redsift/products`:
+
+1. Call `get_component_props` to look up the exact props, types, accepted values, and defaults.
+2. **Only use prop values that appear in the returned documentation.**
+3. If a prop you expect is NOT listed, it does not exist — do not add it.
+
+**Why:** The Red Sift DS uses custom prop names and variants. Guessing based on other libraries will produce incorrect code.
+
+## Rule 2 — Import Verification
+
+Always call `get_component_usage` to get the correct import path and package. Components may live in different packages than expected (e.g., `Select` is in `@redsift/pickers`, not `@redsift/design-system`).
+
+## Rule 3 — Pattern Lookup for Page Layouts
+
+When building a page layout, complex form, data table page, or any multi-component composition:
+
+1. Call `search_patterns` to check for an existing proven pattern.
+2. If a match exists, fetch the full spec with the `design-system://patterns/{slug}` resource — it includes state management hooks, data contracts, implementation checklists, and complete working code.
+
+## Rule 4 — Design Token Lookup
+
+When applying colors, spacing, or typography:
+
+1. Call `search_design_tokens` to find the correct token names and CSS custom properties.
+2. Do not hardcode color hex values — use the design token CSS variables.
+
+## NEVER Do This
+
+These are concrete examples of wrong code. **Every single one will fail:**
+
+```tsx
+// ❌ WRONG — Button has NO size prop
+<Button size="small">Save</Button>
+
+// ❌ WRONG — "primary" is not a valid variant
+<Button variant="primary">Save</Button>
+
+// ❌ WRONG — these props do not exist
+<TextField colorScheme="red" />
+<Button isDisabled />
+<Button onPress={() => {}} />
+
+// ❌ WRONG — wrong package
+import { Select } from '@redsift/design-system';
+```
+
+## Common Mistakes
+
+| Wrong (guessed)                                     | Correct (actual)                             | How to verify                           |
+| --------------------------------------------------- | -------------------------------------------- | --------------------------------------- |
+| `variant="primary"`                                 | Look up actual variants                      | `get_component_props` for the component |
+| `size="sm"` / `size="lg"`                           | Most components have no size prop            | `get_component_props` for the component |
+| `colorScheme="red"`                                 | Does not exist                               | `get_component_props` for the component |
+| `isDisabled`                                        | `disabled`                                   | `get_component_props` for the component |
+| `onPress`                                           | `onClick`                                    | `get_component_props` for the component |
+| `leftIcon` / `rightIcon`                            | Look up actual icon prop names               | `get_component_props` for the component |
+| `import { Select } from '@redsift/design-system'`   | `import { Select } from '@redsift/pickers'`  | `get_component_usage`                   |
+| `import { Dialog } from '@redsift/design-system'`   | `import { Dialog } from '@redsift/popovers'` | `get_component_usage`                   |
+| `import { DataGrid } from '@redsift/design-system'` | `import { DataGrid } from '@redsift/table'`  | `get_component_usage`                   |
+
+## Verification
+
+Test that your AI assistant is using the MCP server correctly with these prompts:
+
+1. _"What props does Button accept?"_ → Should call `get_component_props`, NOT answer from memory
+2. _"Import the Select component"_ → Should call `get_component_usage`, return `@redsift/pickers`
+3. _"Create a data table page"_ → Should call `search_patterns` first, then follow the pattern spec