Cómo se implementa un MCP server para tu design system

Qué resuelve un MCP server

El Model Context Protocol (MCP) define cómo un cliente (Claude, Cursor, Cody, un agente custom) consulta un sistema externo en tiempo real, sin reentrenamiento. Para un design system, esto cambia el contrato: hasta ahora un agente sólo podía generar UI con lo que tenía en su contexto. Con un MCP server expuesto por el sistema, el agente puede consultar tokens, componentes y reglas como datos vivos.

Lo que esto hace posible:

Un agente que está generando un dashboard pregunta al servidor “dame todos los tokens de color con $extensions.ida.agentic.allowedSurfaces que contenga data-viz”. Recibe la lista filtrada.
El servidor expone un tool componentApi(name) que devuelve la API estable del componente Card sin que el agente tenga que adivinar nombres de props.
Un prompt del servidor inyecta los siete principios del sistema cuando el cliente pide “generar variante de Button”. El agente ya no compone con genéricos: compone con los principios del sistema concreto.

Anatomía mínima

Un MCP server expone tres tipos de recurso:

Resources  →  cosas legibles (snapshot estático: tokens.json, principios.md)
Tools      →  funciones ejecutables (componentApi, auditAccessibility)
Prompts    →  plantillas inyectables (system-prompt-button, system-prompt-card)

La especificación es transporte-agnóstica. En la práctica hoy se sirve por stdio (proceso local) o http+sse (servidor remoto). Ambos modos son válidos para un design system público.

Stack base (TypeScript)

El SDK oficial cubre el 90% del trabajo. Una implementación mínima cabe en 60 líneas:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { readFileSync } from "node:fs";

const server = new Server({ name: "ida-ds", version: "0.1.0" }, {
  capabilities: { resources: {}, tools: {}, prompts: {} },
});

// 1. Resources — tokens como archivo legible
server.setRequestHandler("resources/list", async () => ({
  resources: [{
    uri: "ds://tokens.json",
    name: "Design tokens (DTCG)",
    mimeType: "application/json",
  }],
}));

server.setRequestHandler("resources/read", async (req) => {
  if (req.params.uri === "ds://tokens.json") {
    return {
      contents: [{
        uri: req.params.uri,
        mimeType: "application/json",
        text: readFileSync("./tokens.json", "utf8"),
      }],
    };
  }
  throw new Error("Resource not found");
});

// 2. Tools — consulta tipada del API de un componente
server.setRequestHandler("tools/list", async () => ({
  tools: [{
    name: "componentApi",
    description: "Devuelve la API pública estable del componente solicitado.",
    inputSchema: {
      type: "object",
      properties: { name: { type: "string" } },
      required: ["name"],
    },
  }],
}));

server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name === "componentApi") {
    const api = readFileSync(`./api/${req.params.arguments.name}.json`, "utf8");
    return { content: [{ type: "text", text: api }] };
  }
  throw new Error("Tool not found");
});

await server.connect(new StdioServerTransport());

Tres archivos para arrancar:

tokens.json con tu DTCG.
api/<name>.json por componente público.
principles.md con los 10 principios del sistema.

Cómo lo consume un cliente

Configuración del cliente (Claude Desktop, por ejemplo):

{
  "mcpServers": {
    "ida-ds": {
      "command": "node",
      "args": ["/ruta/a/tu/ds-server.js"]
    }
  }
}

Una vez conectado, el agente puede pedir ds://tokens.json como recurso o llamar a componentApi(name: "Button") como tool. La latencia es la del proceso local; la respuesta es el dato vivo del sistema, no una versión cacheada en el modelo.

Tres decisiones que el equipo del DS debe tomar antes

Qué se expone. No todo el sistema. Sólo lo que está documentado como API pública. Los tokens internos, los componentes legacy o las reglas en migración quedan fuera del MCP server. La regla es la misma que para una API REST: lo público es lo estable.
Cómo se versiona. El servidor responde con una versión semántica de la spec del sistema. Si introduces un cambio disruptivo en los tokens, el servidor lo publica como 2.0.0 y los agentes que consumen ^1.x.x siguen recibiendo la versión anterior hasta que el cliente actualice.
Qué se permite ejecutar. Los tools pueden ser de lectura (getTokens, componentApi) o de escritura (proposeNewVariant). Las de escritura abren la puerta a que un agente contribuya al sistema. Antes de habilitarlas, define el flujo de revisión: una contribución de agente no se mergea sin PR humano, igual que la de un colaborador externo.

Ver también

Esta guía es la base del módulo 03 de la cohorte. Si necesitas implementarlo con acompañamiento, el bootcamp ejecutivo cubre el patrón en cinco sesiones. Si quieres la versión condensada con plantilla, la mini-formación de tokens W3C DTCG incluye el servidor de ejemplo listo para clonar.