Lets an AI client browse a pinned design-system bundle, look up components, presets and slots, and validate screen specs.
Ayrıca bilinen adı 0design/ai-native-design-framework, @ai-native-design-framework/kit
- Yıldızlar
- 29
- Araçlar
- —
- İndirmeler, 30 gün
- 177
- En son sürüm
- 0.2.1
- Son commit
- 4 Kas 2026
- Lisans
- MIT
AINDF MCP nedir?
AINDF bir MCP sunucusudur. Lets an AI client browse a pinned design-system bundle, look up components, presets and slots, and validate screen specs.
Özet, projenin README dosyasından oluşturuldu
AINDF MCP sunucusu hakkında
Browsing a pinned design system bundle and validating screen specifications is what AINDF enables for screen authors and design system maintainers. This MCP server allows an AI client to interact with a specific, immutable design system revision by using tools like list-by-facet, get-component, and validate-screen. It works via stdio or can run on an edge runtime using a hosted endpoint that requires an author token for staging drafts.
Developers use the kit to manage design system conformance and build Next.js App Router pages from screen JSON files. The server provides access to components, presets, slots, and bindings while ensuring that screen specs adhere to the pinned AINDF 0.2 contract. It distinguishes itself by supporting content-addressed revisions through bundleSha256, ensuring that the AI agent interacts with a precise, unchangeable version of the design system rather than a moving target.
Neler yapabilirsiniz
- 1Validate screen specificationsHave the AI agent validate a screen JSON file against the pinned design system contracts to catch errors.
Projenin README dosyasından alınmıştır. Her kullanım durumu, oradaki bir alıntı ile kontrol edilir.
AINDF MCP nasıl yüklenir
Biçimler 10 Kas 2026 tarihinde doğrulandıCursor'a ekleGoose'a ekleAINDF MCP'yi Claude Code içine yükleyin
$ claude mcp add aindf -- npx -y @ai-native-design-framework/kitAINDF MCP'yi Cursor içine yükleyin
~/.cursor/mcp.json
{
"mcpServers": {
"aindf": {
"command": "npx",
"args": [
"-y",
"@ai-native-design-framework/kit"
]
}
}
}AINDF MCP'yi VS Code içine yükleyin
.vscode/mcp.json
{
"servers": {
"aindf": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@ai-native-design-framework/kit"
]
}
}
}AINDF MCP'yi VS Code CLI içine yükleyin
$ code --add-mcp '{"name":"aindf","type":"stdio","command":"npx","args":["-y","@ai-native-design-framework/kit"]}'AINDF MCP'yi Claude Desktop içine yükleyin
claude_desktop_config.json
{
"mcpServers": {
"aindf": {
"command": "npx",
"args": [
"-y",
"@ai-native-design-framework/kit"
]
}
}
}AINDF MCP'yi Codex içine yükleyin
$ codex mcp add aindf -- npx -y @ai-native-design-framework/kitAINDF MCP'yi Codex config.toml içine yükleyin
~/.codex/config.toml
[mcp_servers.aindf] command = "npx" args = ["-y", "@ai-native-design-framework/kit"]
AINDF MCP'yi Gemini CLI içine yükleyin
$ gemini mcp add -s user aindf npx -- -y @ai-native-design-framework/kitAINDF MCP'yi Gemini settings.json içine yükleyin
~/.gemini/settings.json
{
"mcpServers": {
"aindf": {
"command": "npx",
"args": [
"-y",
"@ai-native-design-framework/kit"
]
}
}
}Otomatik kontroller
Çalıştırıldı 13 Kas 2026Tam rapor →Otomatik kontrollerimizden geçti. Bu bir güvenlik denetimi değildir: kodu okuyun ve sunucuya ihtiyaç duyduğu en dar erişimi verin. Kontroller nasıl çalışır
- Kaynak deposu bağlantılı ve erişilebilirGeçti
- Açık kaynak lisansı (OSI)Geçti
- Son bir yıl içinde commit veya sürüm mevcutGeçti
- Paket adı popüler bir pakete yakın değilGeçti
- Uzak uç nokta HTTPS kullanıyorKontrol edilmedi
- Yıkıcı araçlar etiketlenmişKontrol edilmedi
- Modele yönelik gizli talimat yokGeçti
- Pakette veya bağımlılıklarında kritik uyarı yokGeçti
@ai-native-design-framework/kit — the AINDF 0.2 kit
One dependency-free package for any design system that conforms to AINDF (conformsTo: "aindf@0.2"):
| Command | Role | What it does |
|---|---|---|
aindf check <aindf.config.json> |
DS maintainer | Conformance: sources validate against the pinned AINDF 0.1 schemas (schema/0.1, SHA256SUMS) and the v0.2 additions (schema/0.2), no dangling slot/modifier/preset edges, layer rule, downward-only tokens, closed props (no className/style/children/handlers), bindings resolve. |
aindf bundle <config> --out <file> |
DS maintainer | Immutable, content-addressed DS revision (bundleSha256). Screens pin it; the MCP serves it. |
aindf build <config> --screens <dir> --app <dir> [--check] |
trusted builder | Admits every *.screen.json, generates Next.js App Router pages (// @generated), --check fails on manual edits, stale specs, DS changes and orphans; writes built receipts only. |
aindf mcp <bundle.json> |
screen author | stdio MCP; createDsMcp + mcpFetchHandler run the same server on an edge runtime. |
v0.2 additions to the public AINDF 0.1 contract graph: components (closed prop/slot/state contracts, templates),
bindings (named data/action adapters implemented by the DS), screen (the only author artifact), receipt, config.
MCP surface: AINDF 0.1 list-by-facet, slot-accepts, applicable-modifiers, get-preset plus get-ds,
get-component, validate-screen, submit-screen and request-extension. The last two are offered only by an
endpoint with staging (e.g. a hosted DS-MCP), need an author token and only stage unaccepted drafts; a read-only
endpoint such as aindf mcp lists 7 tools, and an agent reports the need or the validated ScreenSpec to the user.
Every tool carries a title and MCP hints (readOnlyHint, destructiveHint, idempotentHint, openWorldHint).
The kit contains no design system; its tests run against a small fixture design system kept in the repository. Limits: a builder receipt is not a signature; verified/accepted/released are never written by the kit; isolation of the author principal comes from deployment rights, not from this package.
Clean install: the repository's packages/aindf-kit/scripts/clean-install.mjs (source)
packs this package, installs the tarball into an empty project and uses it only as a consumer would — the aindf bin
(check, bundle, build, --check), the package exports and the MCP over stdio — each step with a negative. CI runs it on
Node 20 and 22 and prints the tarball sha256 and kit version it checked.
Instance on Core (ds.core + ds.coreBundle + ds.coreBundleSha256, 0.2.0)
An Instance that extends a Core pins it in aindf.config.json three ways: ds.core (id@version), ds.coreBundle
(path to that Core's AINDF bundle) and ds.coreBundleSha256 (the bundle's content hash; a self-consistent bundle with the
same id@version but other contracts is refused). Generated screens import from one module only — the Instance's
implementation.module — so a Core role a screen needs (Input, DialogPanel …) is provided by the Instance under the same
contract name, implemented with the Instance's look. aindf check then holds that contract to the Core one: it must
accept every prop value the Core contract accepts —
- every Core prop stays, with its type, required exactly where Core requires it;
- every enum value, allowed binding, rich-text mark and inline component stays (the Instance may add more);
- limits are no tighter:
maxLength,minItems/maxItems,minimum/maximum; the link pattern is the Core one; - every Core slot prop stays; props the Core role does not have are optional;
- the role keeps its place in a screen: a Core template stays a template,
routeParamsis not added, the taxonomy layer is the Core one, every Core slot exists with a cardinality no tighter; slots the Core role does not have are optional (min 0); - every Core component exists in the Instance (contract and taxonomy), every Core binding by name; a
paramsordatabinding keeps its kind (a screen uses it as$.params/$.meta), anactionbinding may change kind (props name it).
What this guarantees: a screen written for Core — its components, props, where they stand, which slots they fill and how
many children, its bindings — admits against the Instance unchanged, with one exception on purpose: what a slot
accepts is judged by the Instance's own slotsets (their accepted components are Instance components), so a narrower
accepts can still reject a Core screen with SLOT_REJECTS. That is not checked here.
coreConformance(config, components, core, { taxonomy, slots, bindings }): props, slotProps, template, routeParams and
the Core component list are checked from components alone; the taxonomy layer and presence, slots and bindings only when
that source is passed. checkDs passes all of them.
Codes: CORE_PIN (AINDF-DS-29) when the bundle is not the pinned one; CORE_CONFORMANCE (AINDF-DS-30) per narrowed prop,
moved role, narrowed or new required slot, missing component or binding. Without ds.coreBundle nothing changes.
AINDF MCP soruları
AINDF MCP'yi Claude Code'a nasıl eklerim?
Terminalinizde claude mcp add aindf -- npx -y @ai-native-design-framework/kit komutunu çalıştırın. Her projede kullanılabilir olması için --scope user ekleyin.
AINDF MCP'yi Cursor'a nasıl eklerim?
~/.cursor/mcp.json dosyasını açın ve yukarıdaki yükleme bölümünde gösterilen Cursor yapılandırmasını kullanarak sunucuyu mcpServers altına ekleyin.
What tools does the AINDF MCP server expose?
A read-only endpoint lists seven tools: list-by-facet, slot-accepts, applicable-modifiers, get-preset, get-ds, get-component and validate-screen. Endpoints with staging can also offer submit-screen and request-extension.
How do I start the AINDF MCP server?
Run the aindf mcp command with a bundle file, which serves over stdio. The same server can run on an edge runtime via createDsMcp and mcpFetchHandler.
Can the MCP server modify or submit my screens?
Not on a read-only endpoint: the seven listed tools are read-only, and the agent reports the validated ScreenSpec or need to the user instead of submitting it.
What does validate-screen check against?
It checks a screen spec against the pinned AINDF bundle, including closed component props and slot acceptance, since slots are judged by the design system's own slotsets.
Which AINDF version does the bundle conform to?
Bundles declare conformance to aindf@0.2, which adds components, bindings, screen, receipt and config to the 0.1 contract graph.