MCPサーバーは、recommend_component という1つのツールを公開しており、UIコンポーネントのニーズを既存のshadcn/uiまたは21st.devコンポーネントで満たすべきか、それともMobbinの実アプリ参照に基づくカスタムビルドが必要かを判定します。検索結果のリストではなく、構造化された判定結果を返します。人間が閲覧するためではなく、エージェントがビルド中に消費するために作られています。
これは製品ブリーフで検証された判定レイヤーを実装しています。フィールド/要件のカバレッジを実際のコンポーネント証拠に対してスコアリングし、use_existing / custom_build に閾値で分類します。no_candidates_found バケットは低カバレッジとは別に保持され、単純なプリミティブ用の静的スキップリスト、およびカバレッジがスナップショットであり永続的な事実ではないため computed_at タイムスタンプが含まれます。
サーバーはshadcn/21st.dev/Mobbinを自らスクレイピングしません。各ツール呼び出しは、サーバー側の web_search ツールを有効にしたAnthropic Messages API（claude-sonnet-4-6）に1回リクエストを行い、システムプロンプトには完全なプロセスがエンコードされています。スキップリストチェック、要件抽出、候補検索、実証ベースのカバレッジスコアリング、閾値、そして custom_build の場合のMobbin参照ルックアップです。モデルは構造化JSONを返し、サーバーはそれを呼び出し元エージェントにそのまま渡します。
単純なプリミティブ（button、input、checkbox、label、badge、spinner、tooltip、avatar、icon）はAPI呼び出しの前にローカルで捕捉されるため、リクエストを消費しません。
Related MCP server: ui-registry-mcp
npm install
npm run buildサーバーが実行される環境に ANTHROPIC_API_KEY が設定されている必要があります。
ANTHROPIC_API_KEY=sk-ant-... npm startこれにより、stdio上でMCPサーバーが起動します。MCPクライアント（Claude Code、Cursor、Claude Desktopなど）をこのサーバーに向けてください。正確な設定はクライアントによって異なりますが、一般的には次のようになります。
{
"mcpServers": {
"ui-component-judgment": {
"command": "node",
"args": ["/path/to/ui-component-mcp/dist/index.js"],
"env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
}
}
}recommend_component入力:
{
"component_need": "price breakdown with fees and taxes",
"domain": "Airbnb-style rental marketplace",
"framework": "React + Tailwind",
"existing_stack": "already using shadcn/ui"
}component_need はカテゴリではなく具体的に指定してください。「pricing」ではなく「fees and taxesを含む価格内訳」。曖昧なカテゴリ名は、検証中に誤検出マッチを引き起こしました（一般的なSaaS価格帯コンポーネントが予約チェックアウトのマッチとしてスコアリングされるなど）。
出力: 次のJSONに一致:
{
"verdict": "use_existing | custom_build",
"confidence": "high | medium | low",
"reason": "scored | no_candidates_found | skip_list",
"computed_at": "2026-08-23",
"requirements_checked": [ { "requirement": "...", "met": true, "evidence": "..." } ],
"coverage": "5/7 (71%)",
"recommendation": {
"source": "21st.dev | shadcn | null",
"install_command": "string | null",
"reference": { "source": "Mobbin", "url": "...", "flow_name": "..." }
}
}自明でない各呼び出しは、短いマルチターンツールループ（検索→スコアリング→応答）を実行し、現在の価格（入力$2/M、出力$10/M、web_search呼び出しあたり$0.01）でSonnet 5を使用した場合、およそ$0.06〜$0.10かかります。スキップリストに含まれるプリミティブはAPIに到達しないため、コストは$0です。品質に触れずにこれを抑える3つの要素があります。
システムブロックのプロンプトキャッシング（cache_control: ephemeral）— 指示は毎回同一であるため、繰り返しのターンや繰り返しの呼び出しはキャッシュから読み取られ、全額が再請求されることはありません。
候補発見のための2回の検索予算（custom_build がMobbinルックアップをトリガーする場合はさらに1回）。shadcnと21st.devは順番ではなく同じターンで検索されるため、成長する会話が呼び出しごとに再送信される回数が少なくなります。
UI_JUDGMENT_MODEL 環境変数（デフォルトは claude-sonnet-5）— コード変更なしでより安価なモデル（例: Haiku 4.5）に切り替えられます。本番で安価なモデルを信頼する前に、製品ブリーフの5つの検証済みテストケース（価格内訳、キャンセルポリシー、収益ダッシュボード、ギャラリー、メッセージング）を再実行し、判定結果をSonnetのものと差分比較してください。これはテストされておらず、推論のみです。
キャッシングなし、設計による。 すべての呼び出しはゼロから再検索および再スコアリングします。custom_build の判定は、ライブラリが新しいコンポーネントをリリースするにつれて古くなる可能性があります（検証済み: shadcnの2026年6月のチャットプリミティブにより、おそらくカスタムビルドのメッセージングコンポーネントがほぼ完璧なマッチに変わりました）。呼び出し元エージェント層にキャッシュを追加する場合は、セッションスコープのみにしてください。セッションやビルドをまたいで判定を永続化しないでください。
スキップリストは出発点であり、実際の使用に対してまだ検証されていません。 すべての呼び出しと、それがスキップリストにヒットしたかどうかをログに記録してください。スキップリストに含まれる項目に対してエージェントがツールを呼び出す（リストが狭すぎる）か、スキップされるべきものに対して汎用UIを出荷する（リストにエントリがない）かを監視してください。
完全にサンドボックス化された環境でエンドツーエンドでテストできません。 このサーバーは、api.anthropic.com へのアウトバウンドネットワークアクセスと、モデルのweb_searchツールが到達するものへのアクセスが必要です。一般的なインターネットアクセスをブロックする場所では実行できません。
要件抽出とカバレッジスコアリングは、モデルが1回のパスで行う判断であり、決定論的なルックアップではありません。 手動検証中と同様に、パイプラインを無人で信頼する前に、初期出力を実際のコンポーネントと照合してスポットチェックしてください。
Judges whether a UI component need should be met with an existing shadcn/ui or 21st.dev component, or requires a custom build guided by a real-app reference from Mobbin. Returns a structured verdict (use_existing | custom_build), not a list of search results. Call this whenever you are about to scaffold a new, non-trivial UI component from scratch, when you're unsure your own default output will look production-quality, or when the user references a specific app's pattern to match.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The product type/domain, e.g. 'Airbnb-style rental marketplace'. Shapes what requirements get extracted for the component need. | |
| framework | Yes | e.g. 'React + Tailwind', 'Vue 3'. | |
| component_need | Yes | Specific description of the UI component needed -- not a category. e.g. 'price breakdown with fees and taxes', not 'pricing'. Vague category names produce false-positive matches. | |
| existing_stack | No | Optional. e.g. 'already using shadcn/ui'. Used only as a tiebreaker between similarly-scored candidates, never as a hard filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the output format ('structured verdict, not a list') and mentions reliance on Mobbin references for custom builds. It does not detail failure modes or edge cases, but for a non-destructive decision tool, this is sufficient and adds meaningful context beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first states the core purpose, the second clarifies the output type, and the third lists usage triggers. It is front-loaded with the primary action and avoids any fluff or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains the return value (a verdict with two possibilities) and the context in which it should be used. It also notes it is not a search tool, which is critical for correct invocation. Combined with full schema coverage for parameters, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no additional parameter-specific semantics; the schema already explains each parameter clearly (e.g., 'component_need' should be specific, not a category). The description does not repeat or enhance this, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('judges') and resource ('UI component need'), clearly states the decision outcome (use_existing | custom_build), and explicitly distinguishes itself from search tools by saying 'not a list of search results'. This makes the tool's purpose unambiguous even without siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit trigger conditions: 'whenever you are about to scaffold a new, non-trivial UI component from scratch', 'when you're unsure your own default output will look production-quality', or 'when the user references a specific app's pattern'. This is direct, actionable guidance on when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0recommend_componentScored across 1 tool
With only a single tool, there is no possibility of confusion between tools. The tool's purpose is clearly defined and unambiguous.
The tool name 'recommend_component' follows a clear verb_noun pattern, which is consistent with common naming conventions. No other tools exist to introduce inconsistency.
A single tool is on the thin side for most servers, but it serves a specific, well-defined purpose. It is not trivial and may be sufficient for the intended scope, though additional related tools could add value.
The tool fully covers its stated purpose: making a judgment between using existing components or building custom. It provides a structured verdict without missing essential aspects like referencing Mobbin or shadcn/ui. No obvious gaps within the defined domain.
Find UI components and themes, retrieve code, and generate with hosted 21st AI when enabled.
The website checker for AI agents. One call: verdict, score out of 100, fix list.
A design agent in your coding agent's loop: briefs each screen, reviews UX and visual quality.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
