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.

VerifiedSTDIODesktop onlyDeveloper ToolsMedia & Design

Overview

AI-generated 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.
Before you install
The server is read-only and lists seven tools; submit-screen and request-extension are not part of it and would need an author token on a staging endpoint. The kit writes no verified, accepted or released state, and a builder receipt is not a signature. Isolation of the author principal comes from deployment rights, not from this package.

Installation

In SourceWeft

  1. Open AINDF in the dashboard and add it to a workspace.
  2. 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]"):

CommandRoleWhat it does
aindf check <aindf.config.json>DS maintainerConformance: 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 maintainerImmutable, content-addressed DS revision (bundleSha256). Screens pin it; the MCP serves it.
aindf build <config> --screens <dir> --app <dir> [--check]trusted builderAdmits 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 authorstdio 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, routeParams is 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 params or data binding keeps its kind (a screen uses it as $.params / $.meta), an action binding 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

0
Tool metadata has not been indexed yet.

Version history

1
  1. v0.2.1LatestOct 8, 2026