
AINDF
io.github.0designv0.2.1更新于 Oct 8, 2026
Read-only MCP server for one AINDF design-system bundle: look up what it offers, validate screens.
概览
只读 MCP 服务器,公开一个 AINDF 设计系统 bundle,让助手查询组件、插槽、修饰符和预设,并校验页面。
- 功能
- 通过 stdio 提供单个 AINDF 0.2 设计系统 bundle。只读接口列出七个工具:list-by-facet、slot-accepts、applicable-modifiers、get-preset、get-ds、get-component 和 validate-screen。助手可以据此查看设计系统提供的内容,并对照它检查 ScreenSpec。submit-screen、request-extension 等暂存类工具只由带暂存能力的端点提供,本地服务器不包含。
- 适用场景
- 当助手需要针对某个 AINDF 设计系统编写或审查页面,并且应当看到真实的组件、插槽、修饰符和预设契约而不是靠猜测时使用。适合使用该工具包生成的 bundle 的页面作者和设计系统维护者。
- 运行要求
- 以 stdio 进程在本地运行,通过 aindf mcp 命令并指定 bundle 文件启动。软件包从 npm 安装为 @ai-native-design-framework/kit,需要 Node.js(CI 在 Node 20 和 22 上运行)。未声明认证、环境变量或请求头。仅限桌面端,无网页可执行版本。
安装
在 SourceWeft 中
- 打开 控制台中的 AINDF,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
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.
来源:packages/aindf-kit/README.md,提交 c9a6cb9
工具
0版本历史
1- v0.2.1最新Oct 8, 2026


