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: shadcn MCP Server

Configuración

npm install
npm run build

Requiere que ANTHROPIC_API_KEY esté configurada en el entorno donde se ejecuta el servidor.

Ejecución

ANTHROPIC_API_KEY=sk-ant-... npm start

Esto 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_build activa 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 defecto claude-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_build puede 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.com má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.