
AINDF
io.github.0designv0.2.1Updated Oct 8, 2026
Read-only MCP server for one AINDF design-system bundle: look up what it offers, validate screens.
Overview
Read-only MCP server that exposes one AINDF design-system bundle so an assistant can look up components, slots, modifiers and presets and validate screens.
- What it does
- Serves a single AINDF 0.2 design-system bundle over stdio. The read-only surface lists seven tools: list-by-facet, slot-accepts, applicable-modifiers, get-preset, get-ds, get-component and validate-screen. It lets an assistant inspect what the design system offers and check a ScreenSpec against it. Staging tools such as submit-screen and request-extension are only offered by an endpoint with staging, not by this local server.
- When to use it
- Use it when an assistant needs to author or review screens against a specific AINDF design system and should see the real component, slot, modifier and preset contracts instead of guessing. It is meant for screen authors and design-system maintainers working with a bundle produced by the kit.
- Requirements
- Runs locally as a stdio process, started with the aindf mcp command against a bundle file. The package is installed from npm as @ai-native-design-framework/kit and needs Node.js (CI runs it on Node 20 and 22). No authentication, environment variables or headers are declared. Desktop only; no web executable.
Installation
In SourceWeft
- Open AINDF in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
@ai-native-design-framework/kit — the AINDF 0.2 kit
One dependency-free package for any design system that conforms to AINDF (conformsTo: "[email protected]"):
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.
Source: packages/aindf-kit/README.md at commit c9a6cb9
Tools
0Version history
1- v0.2.1LatestOct 8, 2026


