MCP 服务器，暴露一个工具 recommend_component，用于判断某个 UI 组件需求应该用现有的 shadcn/ui 或 21st.dev 组件来满足，还是需要基于 Mobbin 的真实应用参考进行自定义构建。它返回结构化的裁决结果，而不是搜索结果列表——它是为代理在构建过程中消费而设计的，不是给人浏览的。
这实现了产品简报中验证过的判断层：字段/需求覆盖率对照真实组件证据进行评分，按阈值分为 use_existing / custom_build，其中 no_candidates_found 桶与低覆盖率保持区分，有一个针对琐碎原语的静态跳过列表，以及一个 computed_at 时间戳，因为覆盖率是快照，不是永久事实。
服务器本身不抓取 shadcn/21st.dev/Mobbin。每次工具调用都会向 Anthropic Messages API（claude-sonnet-4-6）发出一个请求，启用服务器端的 web_search 工具，并附带一个编码了完整流程的系统提示：跳过列表检查、需求提取、候选搜索、真实证据覆盖率评分、阈值，以及在 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 应该具体，而不是类别——"包含费用和税费的价格明细"而不是"定价"。模糊的类别名称正是验证期间产生误报匹配的原因（一个通用的 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——跳过列表中的原语花费 $0，因为它们永远不会到达 API。有三件事在不影响质量的情况下降低了成本：
系统块上的提示缓存（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 工具能到达的任何内容——它无法在阻止一般互联网访问的地方运行。
需求提取和覆盖率评分是模型在单次传递中做出的判断， 不是确定性查找。在信任管道无人值守之前，像手动验证期间一样，将早期输出与真实组件进行抽查对比。
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.
