@cdevhub/ngx-tw-mcp 0.4.0
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/README.md +79 -0
- package/index.json +1 -0
- package/package.json +45 -0
- package/src/index.js +196 -0
- package/src/search.js +94 -0
package/README.md
ADDED
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
# @cdevhub/ngx-tw-mcp
|
|
2
|
+
|
|
3
|
+
MCP server that gives an AI coding agent the real API of
|
|
4
|
+
[`@cdevhub/ngx-tw`](https://www.npmjs.com/package/@cdevhub/ngx-tw) — selectors,
|
|
5
|
+
inputs and their defaults, usage examples, theme tokens, and guidance on which
|
|
6
|
+
component fits a given problem.
|
|
7
|
+
|
|
8
|
+
Without it, a model writing ngx-tw code is guessing: the published tarball ships
|
|
9
|
+
compiled bundles and `.d.ts`, so component source and the documentation site are
|
|
10
|
+
both absent from a consumer's `node_modules`, and `.d.ts` erases the defaults
|
|
11
|
+
(`input<BadgeVariant>('soft')` becomes `InputSignal<BadgeVariant>`).
|
|
12
|
+
|
|
13
|
+
## Setup
|
|
14
|
+
|
|
15
|
+
```json
|
|
16
|
+
{
|
|
17
|
+
"mcpServers": {
|
|
18
|
+
"ngx-tw": {
|
|
19
|
+
"type": "stdio",
|
|
20
|
+
"command": "npx",
|
|
21
|
+
"args": ["-y", "@cdevhub/ngx-tw-mcp"]
|
|
22
|
+
}
|
|
23
|
+
}
|
|
24
|
+
}
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Install the version matching your library:
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
npm install -D @cdevhub/ngx-tw-mcp@$(npm pkg get dependencies.@cdevhub/ngx-tw --workspaces=false | tr -d '"^~')
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
The package is lockstep-versioned with `@cdevhub/ngx-tw`, and every response
|
|
34
|
+
carries the library version it describes — so a mismatch against your installed
|
|
35
|
+
library is visible rather than silent.
|
|
36
|
+
|
|
37
|
+
## Tools
|
|
38
|
+
|
|
39
|
+
| Tool | Returns |
|
|
40
|
+
|---|---|
|
|
41
|
+
| `search_components` | Ranked entry points for a free-text description of what you are building |
|
|
42
|
+
| `get_component` | One entry point in full: symbols, selectors, inputs/outputs/models, examples, guidance |
|
|
43
|
+
| `list_components` | Every entry point with a one-line summary |
|
|
44
|
+
| `get_conventions` | Styling and code conventions — tokens, scales, focus rings, Angular idioms |
|
|
45
|
+
| `get_started` | Install, Tailwind v4 wiring, providers, icon registration |
|
|
46
|
+
| `list_theme_tokens` | The design tokens the theme defines and the utilities they generate |
|
|
47
|
+
|
|
48
|
+
Search is lexical and weighted over names, aliases, summaries, and use cases, so
|
|
49
|
+
vocabulary from other design systems resolves — "dropdown" reaches `menu`,
|
|
50
|
+
`select`, and `combobox`; "snackbar" reaches `toast`; "datagrid" reaches `table`.
|
|
51
|
+
|
|
52
|
+
## How the data stays true
|
|
53
|
+
|
|
54
|
+
Everything is baked into a static `index.json` at library build time, inside the
|
|
55
|
+
monorepo where component source and the demo app both exist. The server does no
|
|
56
|
+
parsing at run time.
|
|
57
|
+
|
|
58
|
+
- **The index is generated into `dist/` and never committed**, so there is no
|
|
59
|
+
stored copy that can drift from source.
|
|
60
|
+
- **The API layer is extracted from component source**, not from `.d.ts` and not
|
|
61
|
+
from the documentation site's hand-written tables.
|
|
62
|
+
- **Usage examples are extracted from the documentation site's own snippets.**
|
|
63
|
+
- **Guidance** (`summary`, `whenToUse`, `whenNotToUse`, `aliases`) is
|
|
64
|
+
hand-authored in a `*.meta.ts` co-located with each component.
|
|
65
|
+
- **`verify-mcp-index`** runs in the release pre-flight and fails the release on
|
|
66
|
+
a missing or orphaned guidance file, a cross-reference to a component that no
|
|
67
|
+
longer exists, a documentation snippet binding an input that was removed or
|
|
68
|
+
renamed, or an import path that would not resolve.
|
|
69
|
+
|
|
70
|
+
## Note on icons
|
|
71
|
+
|
|
72
|
+
`<tw-icon>` has no built-in icon set. Valid `name` values are only those the
|
|
73
|
+
consuming application registered through `provideTwIcons()` /
|
|
74
|
+
`provideTwLucideIcons()`, so the server documents the registration model rather
|
|
75
|
+
than shipping a name list that would be wrong for every consumer.
|
|
76
|
+
|
|
77
|
+
## License
|
|
78
|
+
|
|
79
|
+
MIT
|