↓ scroll · ← → flechas · espacio
IA en 540
Design System
MCP
Cómo las apps externas dejan de adivinar y empiezan a preguntar.
El problema
Adivinar o inventar.
Un agente trabajando en una app consumidora tiene que leer directamente los archivos fuente del design system para averiguar qué componentes existen y qué props aceptan. Cuando no encuentra uno que encaje, o no sabe que existe un componente adecuado, inventa un estilo adhoc en su lugar.
Cualquiera de los dos caminos aleja la app del sistema.
El flujo
Del código fuente
al agente.
Desde el código fuente
Metadatos
→
Runtime
Design System MCP
→
Los metadatos se generan en build time a partir del código fuente de los componentes: types, docs y stories.
Cómo la IA trabaja con esto — Paso 0
Las instrucciones
llegan antes.
Antes de cualquier tool call, la IA ya tiene esto: inyectado automáticamente al conectar, no es algo que tenga que pedir.
Tools — llamar en este orden para minimizar tokens:
1. list-components
2. get-props
3. get-component-docs
4. get-component-stories
5. get-tokens
Nunca asumas nombres de props, types o valores de tokens — siempre recupera los docs primero.
Herramienta 01 — list-components
El nombre solo no basta.
Devuelve todos los componentes agrupados por categoría, cada uno con una descripción de una línea. El agrupamiento importa porque el nombre por sí solo no es suficiente: tag/badge/chip, combobox/dropdown y pares similares son fáciles de confundir, y lo que un design system llama «tag» no siempre es lo que la IA (o una persona) asume que significa.
Así es como la IA decide qué componente encaja con el caso de uso, en lugar de asumir que existe uno o construir desde cero.
Controls7
buttonchipcomboboxdropdown
Forms6
inputcheckboxtextarearadiogroup
Data Display9
cardtabletagsbadge
Navigation4
breadcrumbstabspagination
Feedback3
calloutprogressbarsnackbar
Herramienta 02 — get-props
Cada prop, con su type y su doc.
Dado un componentId, devuelve cada prop: name, type, default y la descripción de JSDoc. La llamada más barata y más usada, unos 200 a 400 tokens. Es el punto de partida una vez que se elige un componente.
labelstringTexto de la etiqueta mostrado sobre el input
statusdisabled|default|error|success|loadingEstado visual y de validación
requiredbooleanMarca el campo como obligatorio y muestra un asterisco
requiredSymbolColordefault|accentColor del asterisco de obligatoriedad
passwordToggleVisibilitybooleanToggle para mostrar u ocultar el valor cuando type="password"
requiredSymbolColor — DESCRIPCIÓN COMPLETA
«default: inherits the label color — use for most forms. accent: uses the design system's accent color, for surfaces that already use the accent semantic. It is a stylistic emphasis, not a validation state — errors are still communicated via status="error".»
Herramienta 03 — get-component-stories
Una story es un patrón
ya decidido.
Una prop ya te dice lo que hace status="error" por sí sola. Una story existe para combinaciones que solo tienen sentido juntas: un patrón nombrado y reutilizable que el sistema ya ha decidido.
Prop (atómica)
status: "error"
→
Story (curada) — «Error»
status: "error"
hint: "Username must be at least 5 characters"
PasswordToggletype: "password" + passwordToggleVisibility: true
RequiredAccentrequired: true + requiredSymbolColor: "accent"
Herramienta 04 — get-component-docs
La documentación
es clave.
Documentación de patrones de diseño: anatomía, cuándo usarlo, do's y don'ts, y accesibilidad.
- Vínculo label ↔ input
- Atributo required más anuncio de screen-reader
- Texto de hint para cualquier status no-default
- etc...
Herramienta 05 — get-tokens
Valores resueltos, no referencias.
Se consulta solo por category y devuelve valores totalmente resueltos, no referencias. La IA nunca persigue una variable a través de capas de aliasing.
Esto permite que la IA tome decisiones cuando le pides que «haga algo verde» o «haga algo gris», o incluso solo «que sea más claro», usando los tokens, y que entienda cómo se ve realmente cada token. Igual que haríamos nosotros al mirarlos visualmente.
color
spacing
typography
--sys-color-feedback-content-error#C53039
--sys-color-feedback-background-error#FCCFD6
--sys-color-feedback-content-success#00B589
--sys-color-feedback-background-success#DEF7F1
--sys-color-feedback-content-warning#A28200
--sys-color-feedback-background-warning#FCF1C2
Valores literales de los tokens mostrados arriba.
En la práctica — flujo hipotético trazado
Dos prompts, trazados.
01
«Agrega un modal de confirmación con acciones de Cancelar y Aceptar.»
list-components encontrado: dialog
get-props("dialog")
get-component-docs("dialog") revisa posición y orden de los botones
get-component-stories("dialog-with-actions")
02
«¿Qué color marca un estado de error?»
get-tokens(category: "color")
filter: feedback + error
--sys-color-feedback-content-error #C53039 (texto/icono)
--sys-color-feedback-background-error #FCCFD6 (superficie)
La estructura que necesita cada componente
Cuatro piezas, cuatro tools.
✓JSDoc a nivel de componentelist-components
✓JSDoc a nivel de propget-props
✓_docs/{Name}.md — doc de patrón de diseñoget-component-docs
✓Stories en formato autodocsget-component-stories
Input fue el primero en migrarse, como referencia. Se construyó un skill a partir de ese patrón para migrar el resto de los componentes de la misma forma.
Antes → Después
De READMEs sueltos
a metadata.json.
Antes
README.md disperso por componente → invisible en Storybook → explicaciones de props que duplican el código fuente → inalcanzable para la IA y para los diseñadores
↓
Después
JSDoc (componente y props) + _docs/*.md + autodocs stories → visible en Storybook y parseado hacia metadata.json → servido por get-props, get-component-docs y get-component-stories
Resumen
Un pipeline,
cualquier app.
Un solo pipeline de metadata, un servidor, cualquier app compatible con MCP.
Storybook sigue siendo la fuente de verdad para las personas. MCP es su gemelo de cara a los agentes. Los mismos datos, dos audiencias.
Las apps consumidoras construyen UI basada en lo que realmente existe, no en suposiciones.