ui-component-judgment-mcp
ui-component-judgment-mcp
Servidor MCP que expone una herramienta, recommend_component, que juzga si una necesidad de componente de UI debe resolverse con un componente existente de shadcn/ui o 21st.dev, o si requiere una construcción personalizada guiada por una referencia de una aplicación real de Mobbin. Devuelve un veredicto estructurado, no una lista de resultados de búsqueda: está diseñado para que un agente lo consuma durante la construcción, no para que un humano lo navegue.
Esto implementa la capa de juicio validada en el brief del producto: cobertura de campos/requisitos puntuada contra evidencia real de componentes, umbralizada en use_existing / custom_build, con un bucket no_candidates_found mantenido distinto de la baja cobertura, una lista de omisión estática para primitivas triviales, y una marca de tiempo computed_at porque la cobertura es una instantánea, no un hecho permanente.
Cómo funciona
El servidor no extrae datos de shadcn/21st.dev/Mobbin por sí mismo. Cada llamada a la herramienta hace una solicitud a la API de Mensajes de Anthropic (claude-sonnet-4-6) con la herramienta web_search del lado del servidor habilitada, y un prompt de sistema que codifica el proceso completo: verificación de lista de omisión, extracción de requisitos, búsqueda de candidatos, puntuación de cobertura con evidencia real, umbral y — en custom_build — una búsqueda de referencia en Mobbin. El modelo devuelve JSON estructurado, que el servidor pasa de vuelta al agente llamante sin cambios.
Las primitivas triviales (button, input, checkbox, label, badge, spinner, tooltip, avatar, icon) se detectan localmente antes de cualquier llamada a la API, por lo que no gastan una solicitud.
Related MCP server: ui-registry-mcp
Configuración
npm install
npm run buildRequiere que ANTHROPIC_API_KEY esté configurada en el entorno donde se ejecuta el servidor.
Ejecución
ANTHROPIC_API_KEY=sk-ant-... npm startEsto inicia un servidor MCP sobre stdio. Apunta tu cliente MCP (Claude Code, Cursor, Claude Desktop, etc.) hacia él — la configuración exacta depende del cliente, pero generalmente se ve así:
{
"mcpServers": {
"ui-component-judgment": {
"command": "node",
"args": ["/path/to/ui-component-mcp/dist/index.js"],
"env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
}
}
}Herramienta: recommend_component
Entrada:
{
"component_need": "price breakdown with fees and taxes",
"domain": "Airbnb-style rental marketplace",
"framework": "React + Tailwind",
"existing_stack": "already using shadcn/ui"
}component_need debe ser específico, no una categoría — "desglose de precios con tarifas e impuestos" no "precios". Los nombres de categorías vagos son lo que produjo coincidencias falsas positivas durante la validación (un componente genérico de niveles de precios SaaS puntuando como coincidencia para un checkout de reserva).
Salida: JSON que coincide con:
{
"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": "..." }
}
}Costo
Cada llamada no trivial ejecuta un bucle corto de múltiples turnos de herramientas (búsqueda → puntuación → respuesta), que cuesta aproximadamente $0.06–$0.10 con Sonnet 5 a los precios actuales ($2/M de entrada, $10/M de salida, $0.01 por llamada a web_search) — las primitivas en la lista de omisión cuestan $0 porque nunca llegan a la API. Tres cosas mantienen esto bajo sin tocar la calidad:
Caché de prompts en el bloque de sistema (
cache_control: ephemeral) — las instrucciones son idénticas en cada llamada, por lo que los turnos repetidos y las invocaciones repetidas leen desde la caché en lugar de volver a facturar el precio completo.Un presupuesto de 2 búsquedas para el descubrimiento de candidatos (1 más si
custom_buildactiva una búsqueda en Mobbin), con shadcn y 21st.dev buscados en el mismo turno en lugar de secuencialmente, para que la conversación creciente se reenvíe menos veces por llamada.La variable de entorno
UI_JUDGMENT_MODEL(por defectoclaude-sonnet-5) — te permite cambiar a un modelo más barato (por ejemplo, Haiku 4.5) sin un cambio de código. Antes de confiar en un modelo más barato en producción, vuelve a ejecutar los 5 casos de prueba validados del brief del producto (desglose de precios, política de cancelación, panel de ganancias, galería, mensajería) y compara los veredictos con los de Sonnet — esto no se ha probado, solo se ha razonado.
Limitaciones conocidas (heredadas de la validación)
Sin caché, por diseño. Cada llamada vuelve a buscar y puntuar desde cero. Un veredicto de
custom_buildpuede quedar obsoleto a medida que las bibliotecas lanzan nuevos componentes (validado: las primitivas de chat de shadcn de junio de 2026 convirtieron un componente de mensajería que probablemente era de construcción personalizada en una coincidencia casi perfecta). Si agregas caché en la capa del agente llamante, mantenla solo con alcance de sesión — nunca persistas un veredicto entre sesiones o construcciones.La lista de omisión es un punto de partida, aún no validada contra el uso real. Registra cada llamada y si alcanzó la lista de omisión; observa si los agentes llaman a la herramienta de todos modos en elementos omitidos (lista demasiado estrecha) o envían UI genérica para algo que debería haberse omitido (falta una entrada en la lista).
No es comprobable de extremo a extremo en un entorno completamente aislado. Este servidor necesita acceso de red saliente a
api.anthropic.commás lo que la herramienta web_search del modelo alcance — no funcionará en algún lugar que bloquee el acceso general a Internet.La extracción de requisitos y la puntuación de cobertura son juicios hechos por el modelo en una sola pasada, no búsquedas deterministas. Verifica las primeras salidas contra componentes reales antes de confiar en el pipeline sin supervisión, igual que durante la validación manual.
Available Tools
1 toolrecommend_componentA
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. |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
recommend_component
TDQS
Scored 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.
Maintenance
Related MCP Connectors
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.
Related MCP Servers
- AlicenseBqualityDmaintenanceProvides AI assistants with tools to grade, generate, and validate UI components against the components.build specification. Supports searching documentation, checking compliance, and generating framework-agnostic accessible components.118 npmApache 2.0
- AlicenseAqualityDmaintenanceProvides coding agents live access to shadcn-style component registries, enabling them to search, compare, and fetch real component source code for UI composition.533 npm5MIT
- AlicenseNot gradedqualityAmaintenanceSTOP UI SLOP. Gives coding agents searchable evidence from 800,000+ real web and iOS screens, design contracts, and a hard UI finish gate.1MIT
- AlicenseNot gradedqualityCmaintenanceDesign review for UI code, inside your coding agent. Reviews React, Vue, Svelte, CSS and SwiftUI against 313 rules and returns scored findings with file:line fixes your agent can apply and verify.MIT