Lets an AI client browse a pinned design-system bundle, look up components, presets and slots, and validate screen specs.
Also known as 0design/ai-native-design-framework, @ai-native-design-framework/kit
- Stars
- 29
- Tools
- —
- Downloads, 30 days
- 177
- Latest version
- 0.2.1
- Last commit
- Nov 4, 2026
- License
- MIT
What is AINDF MCP?
AINDF lets an AI client browse a pinned design-system bundle, look up components, presets and slots, and validate screen specs.
Summary generated from the project's README
About AINDF MCP server
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.
What you can do with it
- 1Validate screen specificationsHave the AI agent validate a screen JSON file against the pinned design system contracts to catch errors.
Written from the project's README. Every use case is checked against a quote from it.
How to install AINDF MCP
Formats verified 10 Nov 2026Install AINDF MCP in Claude Code
$ claude mcp add aindf -- npx -y @ai-native-design-framework/kitInstall AINDF MCP in Cursor
~/.cursor/mcp.json
{
"mcpServers": {
"aindf": {
"command": "npx",
"args": [
"-y",
"@ai-native-design-framework/kit"
]
}
}
}Install AINDF MCP in VS Code
.vscode/mcp.json
{
"servers": {
"aindf": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@ai-native-design-framework/kit"
]
}
}
}Install AINDF MCP in Claude Desktop
claude_desktop_config.json
{
"mcpServers": {
"aindf": {
"command": "npx",
"args": [
"-y",
"@ai-native-design-framework/kit"
]
}
}
}Install AINDF MCP in Codex
~/.codex/config.toml
[mcp_servers.aindf] command = "npx" args = ["-y", "@ai-native-design-framework/kit"]
Install AINDF MCP in Gemini CLI
~/.gemini/settings.json
{
"mcpServers": {
"aindf": {
"command": "npx",
"args": [
"-y",
"@ai-native-design-framework/kit"
]
}
}
}Automated checks
Ran Nov 13, 2026Full report →Passed our automated checks. That is not a security audit: read the code and give the server the narrowest access it needs. How checks work
- Source repository linked and reachablePass
- Open source license (OSI)Pass
- Commit or release in the last yearPass
- Package name not close to a popular packagePass
- Remote endpoint uses HTTPSNot checked
- Destructive tools are labelledNot checked
- No hidden instructions to the modelPass
- No critical advisory in the package or its dependenciesPass
README
View on GitHub@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 questions
How do I add AINDF MCP to Claude Code?
Run claude mcp add aindf -- npx -y @ai-native-design-framework/kit in your terminal. Add --scope user to make it available in every project.
How do I add AINDF MCP to Cursor?
Open ~/.cursor/mcp.json and add the server under mcpServers, using the Cursor config shown in the install section above.
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.