プロトタイプ · プレビュー版:公式レジストリのすべてのサーバーを掲載し、30分ごとに同期しています。レビューとアカウント機能は今後のステップで始まります。
PopNx MCPAIを使う人のためのMCPサーバー · やさしい言葉で解説

AINDF

作者:0designバージョン 0.2.1i★ –iパソコンで動く
レジストリ名io.github.0design/aindf

インストール

概要

作者による説明(英語の原文)

Read-only MCP server for one AINDF design-system bundle: look up what it offers, validate screens.

PopNx MCPの3つの柱

この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。

できること

このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。

  • 接続方法: パソコンで動く
  • トランスポート: stdio
  • カテゴリ: デザイン・画像・音声

インストール

使っているAIアプリを選んで、設定をコピーしてください。

インストールの前に

  • 基本チェック:1項目中1項目に合格
  • あなたのパソコンで、あなたのユーザーと同じ権限(ファイル、ネットワーク、アプリ)で動きます。
  • レジストリには、入力が必要なキーは載っていません。

必要なもの

  • npmNode.jsのインストール(npxコマンドに必要)

どのアプリを使っていますか?

上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。

Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます

{
  "mcpServers": {
    "aindf": {
      "command": "npx",
      "args": [
        "-y",
        "@ai-native-design-framework/kit",
        "mcp"
      ]
    }
  }
}

ターミナルでこれを実行します

claude mcp add aindf -- npx -y @ai-native-design-framework/kit mcp

このサーバーは起動コマンドに値を入れる必要があるので、設定をコピーして入力してください。

または、設定を自分でコピーする

プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます

{
  "mcpServers": {
    "aindf": {
      "command": "npx",
      "args": [
        "-y",
        "@ai-native-design-framework/kit",
        "mcp"
      ]
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

このサーバーは起動コマンドに値を入れる必要があるので、設定をコピーして入力してください。

または、設定を自分でコピーする

プロジェクトの .vscode/mcp.json に貼り付けます

{
  "servers": {
    "aindf": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@ai-native-design-framework/kit",
        "mcp"
      ]
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。

選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。

この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。

できること

パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。

基本チェックi

誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月6日にチェック

  • ✓ 合格

    作者とリポジトリが一致

    レジストリ名は、リポジトリを所有するGitHubアカウント 0design で確認済みです

  • … 未チェック

    今もメンテナンスされている

    このリポジトリはまだGitHubから読み取っていません

  • … 未チェック

    ライセンスがある

    このリポジトリはまだGitHubから読み取っていません

  • – 対象外

    エンドポイントが応答する

    これはパソコンで動くため、インターネット上のエンドポイントはありません

  • – 対象外

    OAuthでサインイン

    パソコンで動き、代わりにローカルの設定を使います

  • … 未チェック

    ツールの説明に隠れた指示がない

    パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです

デザイン・画像・音声のほかのサーバーとの比較i

  • このカテゴリのほかの2166件のうち0%よりスターが多い
  • このカテゴリのほかの2166件のうち50%より最近レジストリに公開
  • 基本チェックの結果が、このカテゴリのほかの2166件のうち100%と同じかそれ以上

レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。

よくある質問

AINDFは安全ですか?

当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。

どんなキーやコードが必要ですか?

レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。

パソコンで動きますか、それともクラウドですか?

あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。

今もメンテナンスされていますか?

GitHubリポジトリの最終更新は–、最新バージョン(0.2.1)がレジストリに届いたのは29 日前です。

どのアプリで使えますか?

Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにNode.jsも必要です。

代わりに使えるものは?

同じカテゴリには:Figma Context MCP, Claude Real Video, Figma MCP Server

代わりの候補

同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。

カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i

Figma Context MCP

作者:GLips

Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.

パソコンで動く★ 16,165MIT5 か月前更新
インストール

Claude Real Video

作者:HUANGCHIHHUNGLeo

Let any LLM watch a video locally — and search everything it has ever watched.

パソコンで動く★ 2,284MIT2 か月前更新
インストール

Figma MCP Server

作者:figma

The Figma MCP server brings Figma design context directly into your AI workflow.

クラウドで動く★ 2,15213 か月前更新
インストール

作者のREADME

READMEを開く

作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。

@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"):

CommandRoleWhat it does
aindf check 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 --out DS maintainerImmutable, content-addressed DS revision (bundleSha256). Screens pin it; the MCP serves it.
aindf build --screens --app [--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 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.

PopNxに聞く