Qué es un servidor MCP, brevemente
El Model Context Protocol es un estándar abierto para conectar agentes y aplicaciones de IA con herramientas y datos externos a través de una única capa de integración. En lugar de que el modelo responda basándose en lo que absorbió durante el entrenamiento, llama a una herramienta, obtiene una respuesta actualizada y trabaja a partir de ella.
Para un sistema de diseño, esto significa un servidor situado delante de su documentación y código que expone un puñado de herramientas de búsqueda o consulta. El agente decide cuándo llamarlas durante una sesión.
Un ejemplo real, herramienta por herramienta
El Carbon Design System de IBM publica un servidor MCP, actualmente en vista previa pública, y su lista de herramientas documentadas es una buena plantilla porque es específica en lugar de aspiracional:
| Qué devuelve | |
|---|---|
docs_search | Guías de componentes, uso, accesibilidad y documentación de referencia |
code_search | Ejemplos de código de React y Web Components, iconos y pictogramas, como archivos de ejemplo completos, con props e importaciones |
get_charts | Ejemplos de gráficos en React, Angular, Vue, Svelte, JS puro y HTML |
labs_search | Componentes experimentales: AnimatedHeader, Processing, Resizer, WhatsNew, Labs UIShell |
Las razones expuestas por IBM son el acceso instantáneo a los estándares de diseño, la generación de código de mayor fidelidad que sigue las mejores prácticas y respuestas coherentes basadas en una fuente de verdad compartida que reduce la divergencia y el retrabajo.
Nótese que code_search devuelve *archivos de aplicaciones de ejemplo completos*, no firmas. Esa es la decisión de diseño que hace que estos servidores funcionen. Un modelo al que se le proporciona un ejemplo completo y funcional reproduce las convenciones circundantes (estilo de importación, composición, orden de las props) que una simple firma de tipo no transmite.
El problema que realmente soluciona
Pida a un agente de código que cree un formulario con su librería de componentes y observe qué falla. Normalmente no será el diseño. Será una prop que se renombró hace dos versiones mayores, una ruta de importación que cambió al reestructurar el paquete, el nombre de una variante que nunca existió o un componente que fue deprecado y sustituido.
Este es un problema de recuperación y tiene una propiedad específica y molesta: el resultado incorrecto se ve exactamente igual que el correcto. Un nombre de prop alucinado es sintácticamente válido, semánticamente plausible y se lee correctamente en una revisión. Se descubre en tiempo de ejecución, o en un error de tipo si tiene la suerte de usar tipos.
Un nombre de prop alucinado es sintácticamente válido, semánticamente plausible y se lee correctamente en una revisión. La recuperación es superior al recuerdo porque el recuerdo falla silenciosamente.
El problema empeora con el tiempo. El conocimiento de un modelo sobre su librería queda congelado en su fecha de corte de entrenamiento y se aleja más de la realidad con cada lanzamiento. Un sistema de diseño privado o interno es aún peor: el modelo nunca lo ha visto, por lo que cada llamada que escribe es una invención. MCP es la solución correcta para ambos casos, ya que sustituye la memoria por una consulta.
El modelo de costes que nadie menciona
A menudo se debate que MCP es estrictamente mejor que el contexto estático. No es así: es un intercambio diferente, y dicho intercambio es evidente una vez que se pone por escrito.
| Llamada a herramienta MCP | Archivo en el repositorio | |
|---|---|---|
| Cuándo está disponible | Cuando el agente decide llamarlo | En cada turno, incondicionalmente |
| Actualización | Siempre actualizado | Tan actualizado como el archivo |
| Coste | Un viaje de ida y vuelta y tokens de llamada a herramienta por consulta, repetidamente | Tokens de contexto una vez por sesión |
| Escala | Ilimitada: una librería de 4.000 componentes no es problema | Limitada por la ventana de contexto |
| Fiabilidad | Depende de que el agente decida llamarlo | Simplemente está ahí |
| Configuración | Un servidor en ejecución, configuración y, a veces, autenticación | Escribir un archivo y hacer commit |
La fila de fiabilidad es la que sorprende a la gente. Un servidor MCP solo ayuda si el agente lo llama, y un agente que cree saber ya cómo es su componente Button no llamará a nada. Precisamente ese es el caso en el que más se necesita.
Si instala un servidor MCP de un sistema de diseño y no nota cambios en la calidad del resultado, compruebe si se está llamando antes de concluir que no funciona. La seguridad en el error no activa una búsqueda. Una línea en las instrucciones de su repositorio que diga "consulte siempre el servidor del sistema de diseño antes de escribir un componente" suele ser la pieza que falta.
La fila de escala es donde MCP es genuinamente insustituible. Una librería de componentes extensa, con cientos de componentes y cada uno con sus variantes y notas de accesibilidad, no puede pegarse en el contexto. Ese es un problema de recuperación y siempre lo será.
Por qué el agente sigue diseñando mal
Aquí está la parte que se suele omitir. Déle a un agente un servidor MCP perfecto para su librería de componentes y producirá código que compila, usa props reales y sigue las convenciones de la librería. Aun así, producirá una interfaz sin criterio: cuadrículas de tarjetas uniformes, jerarquía basada solo en el grosor de la fuente, el color de acento aplicado donde parezca plausible y un espaciado que, aunque técnicamente pertenece a la escala, es rítmicamente arbitrario.
Eso no es un fallo de conocimiento. El agente conocía cada componente. Es un fallo de criterio, y ocurre porque nada le ha indicado cómo debería verse su producto.
| Servidor MCP | Guía de diseño en el repo | |
|---|---|---|
| Respuestas | "¿Cuál es la API de este componente?" | "¿Cómo debería verse esta pantalla?" |
| Responsabilidad de | Los mantenedores de la librería | Usted |
| Contenido | Props, variantes, imports, notas de accesibilidad, ejemplos | Roles de color, escala tipográfica, ritmo de espaciado, motivos, prohibiciones |
| El fallo sin ello | Código que no se ejecuta | Código que se ejecuta y se ve como el de todo el mundo |
El segundo fallo es el más costoso porque llega a producción. Un error de compilación le detiene. Una interfaz genérica, no.
Analizamos 299 archivos DESIGN.md publicados para que los lean los agentes de IA, comprobando si respondían a la segunda columna. La mayoría no lo hace: el 86% especifica los colores como hex raw sin rol semántico, el 76% no indica ninguna prohibición, el 57% no define motivos distintivos, el 69% no menciona nada sobre el modo oscuro y el 44% no contiene ningún valor de tamaño concreto. El 54% recurre al menos a un adjetivo vago, siendo los más comunes "limpio" (39%) y "moderno" (36%), palabras que un modelo satisface produciendo el promedio de todo lo que ha visto.
Ningún servidor MCP soluciona eso, porque ningún servidor MCP conoce la respuesta. Es su decisión de diseño y debe estar escrita en algún lugar que el agente lea siempre.
Los kits de diseño de Identity Forge son esa segunda columna: roles de color semánticos para modo claro y oscuro, escalas de tipografía y espaciado, motivos y una lista explícita de lo que se debe y no se debe hacer, serializados en un DESIGN.md que reside en el repositorio junto a cualquier servidor MCP que ejecute. Explore los kits o lea qué es un archivo DESIGN.md.
Qué pertenece a cada lugar
Una regla práctica, aplicada a los elementos que contiene un sistema de diseño:
| Dónde | Por qué | |
|---|---|---|
| APIs de componentes, props, variantes | Servidor | Voluminoso, cambia a menudo, solo se necesita bajo demanda |
| Ejemplos de código | Servidor | Demasiados para mantenerlos en el contexto; se recuperan según la necesidad |
| Catálogo de iconos | Servidor | Cientos de nombres, se necesitan de uno en uno |
| Roles de color y la función de cada uno | Archivo | Pequeño, se aplica a cada decisión que toma el agente |
| Escala tipográfica y de espaciado | Archivo | Se necesita continuamente, no bajo demanda |
| Prohibiciones | Archivo | Un agente nunca piensa en preguntar qué está prohibido. Tiene que saberlo de antemano |
| Motivos y personalidad | Archivo | Esta es la parte que hace que el diseño sea suyo |
La fila de prohibiciones es la prueba más rigurosa. La recuperación solo muestra lo que el agente pensó en consultar, y un agente que está a punto de añadir una sombra paralela no tiene motivos para buscar "¿están permitidas las sombras paralelas?". Las restricciones deben estar presentes antes de la decisión, lo que requiere contexto estático, no una herramienta.
Configuración junto a un kit de diseño
Si utiliza Identity Forge, ambas partes están disponibles. El kit de diseño proporciona al agente las decisiones de diseño en un archivo; el servidor MCP le da acceso a sus kits, tokens y formatos de exportación como herramientas.
{
"mcpServers": {
"identityforge": {
"command": "npx",
"args": ["-y", "identityforge@latest", "mcp"]
}
}
}Ejecute esto junto al servidor propio de su librería de componentes si tiene uno — el de Carbon, el de Figma o el suyo interno. Responden a preguntas diferentes y no entran en conflicto.
Una breve lista de evaluación
Antes de adoptar cualquier servidor MCP de sistema de diseño, conviene hacerse cinco preguntas:
- ¿`code_search` devuelve ejemplos completos o solo firmas? Los ejemplos completos transmiten convenciones. Las firmas no.
- ¿Está versionado según la librería que realmente utiliza? Un servidor que rastrea la versión
latestmientras usted está anclado a dos versiones mayores anteriores es peor que no tener servidor, porque comete errores con total seguridad de una manera nueva. - ¿Cubre las pautas de accesibilidad? Las API de componentes sin notas de accesibilidad producen componentes que se renderizan pero excluyen a personas.
- ¿Cómo funciona la autenticación? Varios servidores publicados están restringidos al personal del proveedor durante la fase de preview, con un formulario de solicitud para el resto. Verifíquelo antes de planificar basándose en ello.
- ¿Están sus agentes llamando realmente al servidor? Revise los logs. Un servidor que no se llama es un archivo de configuración, no una capacidad.
¿Qué hace realmente un servidor MCP de un sistema de diseño?
Expone la documentación de su sistema de diseño, los ejemplos de código de los componentes, los tokens e iconos a un agente de IA como herramientas ejecutables. El agente lo consulta durante una sesión en lugar de confiar en lo que aprendió durante el entrenamiento, lo que significa que escribe código basándose en su API actual y no en una recordada.
¿Hará que la UI generada por IA se vea mejor un servidor MCP?
Hará que funcione mejor: props correctas, imports reales, variantes actuales. No hará que se parezca a su producto, porque el servidor contiene la API del componente y no sus decisiones de diseño. La calidad visual proviene de las pautas sobre roles, escala, ritmo y prohibiciones, que deben estar en un archivo que el agente lea en cada sesión.
¿Necesito un servidor MCP si ya tengo un DESIGN.md?
Si su librería de componentes es grande o privada, sí: un archivo no puede contener cientos de API de componentes y el agente inventará las que no conozca. Si utiliza una librería pequeña o muy conocida, el archivo puede ser suficiente por sí solo. Solucionan problemas diferentes y ninguno sustituye al otro.
¿Por qué mi servidor MCP no está mejorando nada?
Compruebe si se está llamando. Los agentes solo invocan una herramienta cuando consideran que la necesitan, y un agente convencido de que conoce su Button no consultará nada. Añadir una instrucción explícita en las reglas de su repositorio para consultar el servidor del sistema de diseño antes de escribir componentes suele solucionarlo.
¿Puedo ejecutar más de un servidor MCP de sistema de diseño?
Sí, y es común. Un servidor de librería de componentes, un servidor de herramientas de diseño y un servidor de kit de diseño responden a preguntas diferentes y no entran en conflicto. Vigile el recuento total de herramientas en lugar del de servidores: una lista de herramientas combinada muy extensa dificulta que el agente elija la correcta.