Seu sistema de design precisa de um servidor MCP

Um dos melhores investimentos que você pode fazer em seu sistema de design agora é um servidor Model Context Protocol (MCP). À medida que os modelos de IA evoluem, tornam-se cada vez mais capazes, mas a sua utilização eficaz tem um custo. Cada token que uma IA desperdiça tentando adivinhar como seus componentes funcionam é dinheiro deixado na mesa. Um servidor MCP fornece à IA um conjunto de ferramentas que ela pode usar para descobrir exatamente como usar seu sistema de design. Pense nisso como uma API que uma IA pode chamar em vez de adivinhar. Neste artigo, falaremos sobre por que isso é importante e como você pode começar por conta própria.

Antes de entrarmos nisso, há algumas coisas sobre o uso da IA ​​que vale a pena abordar. Já tive meu quinhão de ceticismo no passado, mas lançamentos recentes de modelos tornaram cada vez mais difícil argumentar que a IA não é uma ferramenta viável para a maioria dos fluxos de trabalho, incluindo a construção de interfaces de usuário. A maioria dos grandes modelos de linguagem são treinados em dados públicos extraídos da Internet, o que significa que seu sistema de design interno é praticamente invisível para eles, especialmente se sua documentação estiver atrás de uma rede corporativa. Sem um MCP, um agente de IA em qualquer ferramenta de codificação de agente, como GitHub Copilot ou Claude, ainda tentará usar seu sistema, muitas vezes bisbilhotando seu node_modules pasta, preenchendo as lacunas com seu melhor palpite. É daí que vêm as APIs de componentes alucinados. Um servidor MCP não apenas torna a IA mais útil para o seu sistema de design, mas também aborda diretamente o problema de confiança, substituindo suposições por um contexto estruturado e preciso.

No final das contas, os usuários de um sistema de design desejam uma IU que siga as diretrizes da marca o mais rápido possível. Então, por que não capacitá-los a usar a IA de maneira mais eficaz, fornecendo aos seus agentes um livro de receitas para o seu sistema? É uma situação em que todos ganham: eles obtêm um layout que usa os componentes e tokens de design certos desde o início, e você obtém mais adoção sem as mãos habituais. Um servidor MCP torna isso possível, fornecendo aos agentes de IA ferramentas concretas para resolver essas questões, produzindo amostras de código e design de uso de tokens que realmente refletem sua intenção, em vez de uma suposição fundamentada.

Criando um servidor MCP#

Começar a usar um servidor MCP é mais simples do que você imagina. Em vez de endpoints, um servidor MCP expõe “ferramentas” que uma IA pode invocar pelo nome quando precisar de informações. A principal diferença de uma API tradicional é que a resposta não precisa estar em conformidade com um esquema estrito. Ao contrário de uma API REST, em que um cliente quebra se a forma dos dados mudar, uma ferramenta MCP pode retornar texto ou JSON pouco estruturado e a IA entenderá isso. Seu trabalho é simplesmente apontar as informações corretas.

Se estiver usando o Node, você pode usar o pacote @modelcontextprotocol/sdk para começar:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "my-design-system",
  version: "1.0.0",
});



const transport = new StdioServerTransport();
await server.connect(transport);

Para um sistema de design, você deve considerar a exposição de ferramentas ao longo destas linhas:

• Listar componentes: fornece à IA um índice de tudo o que está disponível para que ela saiba o que procurar antes de escrever uma única linha de código.
• Obter componente: retorna todos os detalhes de um componente específico: adereços, slots, eventos e quaisquer restrições de uso. É aqui que as APIs alucinadas são eliminadas.
• Listar documentação: permite que a IA descubra quais orientações escritas existem, úteis para questões mais amplas sobre padrões e composição em nível de página.
• Obtenha documentação: busca o conteúdo real de uma página de documento, incluindo orientações opinativas e casos extremos que os tipos de suporte por si só não conseguem transmitir.
• Obtenha exemplos de componentes: extrai histórias reais do Storybook para que a IA veja padrões de uso em funcionamento, em vez de inferi-los a partir da assinatura do componente.

Isso dá à IA a capacidade de consultar todo o seu sistema de design e detalhar detalhes específicos de componentes conforme necessário. A maneira como você constrói essas ferramentas dependerá da configuração existente. Se você estiver construindo principalmente componentes da Web, poderá conectar-se diretamente ao seu manifesto de elementos personalizados, que já inclui todos os seus componentes e suas opções em um formato legível por máquina:

import fs from "fs";
import { z } from "zod";

interface CustomElementDeclaration {
  kind: string;
  name: string;
  tagName?: string;
  summary?: string;
  customElement?: boolean;
  members?: Array{ kind: string; name: string; type?: { text: string }; description?: string }>;
  slots?: Array{ name: string; description?: string }>;
  events?: Array{ name: string; description?: string }>;
}

interface CustomElementsManifest {
  modules: Array{
    declarations?: CustomElementDeclaration();
  }>;
}

const manifest: CustomElementsManifest = JSON.parse(
  fs.readFileSync("./custom-elements.json", "utf-8")
);

const getDeclarations = (): CustomElementDeclaration() =>
  manifest.modules.flatMap((m) => m.declarations ?? ());

server.tool(
  "list-components",
  "Lists all available components in the design system",
  {},
  async () => {
    const components = getDeclarations()
      .filter((d) => d.kind === "class" && d.customElement)
      .map((d) => ({ name: d.name, tagName: d.tagName, summary: d.summary }));

    return {
      content: ({ type: "text", text: JSON.stringify(components, null, 2) }),
    };
  }
);

server.tool(
  "get-component",
  "Gets the full details of a component including its properties, slots, and events",
  { name: z.string().describe("The component class name or tag name") },
  async ({ name }) => {
    const component = getDeclarations().find(
      (d) => d.name === name || d.tagName === name
    );

    if (!component) {
      return {
        content: ({ type: "text", text: `Component "${name}" not found.` }),
      };
    }

    return {
      content: ({ type: "text", text: JSON.stringify(component, null, 2) }),
    };
  }
);

Se estiver usando o Storybook, você pode percorrer a árvore de sintaxe abstrata para remontar histórias como exemplos consultáveis. Escrevi sobre isso em outro artigo no contexto da validação da renderização no servidor, mas os mesmos princípios se aplicam aqui. Alternativamente, você pode usar o plug-in do servidor Storybook MCP para expor suas histórias como ferramentas sem a necessidade de escrever nenhum código personalizado se estiver usando uma linguagem compatível.

import ts from "typescript";
import fs from "fs";
import path from "path";
import { glob } from "glob";

interface Story {
  name: string;
  source: string;
}

function extractStories(filePath: string): Story() {
  const code = fs.readFileSync(filePath, "utf-8");
  const sourceFile = ts.createSourceFile(
    filePath,
    code,
    ts.ScriptTarget.Latest,
    true
  );

  const stories: Story() = ();

  ts.forEachChild(sourceFile, (node) => {
    if (
      ts.isExportDeclaration(node) ||
      (ts.isVariableStatement(node) &&
        node.modifiers?.some((m) => m.kind === ts.SyntaxKind.ExportKeyword))
    ) {
      if (ts.isVariableStatement(node)) {
        for (const decl of node.declarationList.declarations) {
          if (decl.initializer && ts.isObjectLiteralExpression(decl.initializer)) {
            stories.push({
              name: decl.name.getText(sourceFile),
              source: decl.initializer.getText(sourceFile),
            });
          }
        }
      }
    }
  });

  return stories;
}

server.tool(
  "get-component-examples",
  "Gets Storybook usage examples for a given component",
  { name: z.string().describe("The component name to find stories for") },
  async ({ name }) => {
    const files = await glob(`**/${name}.stories.{ts,tsx}`, {
      ignore: "node_modules/**",
    });

    if (!files.length) {
      return {
        content: ({ type: "text", text: `No stories found for "${name}".` }),
      };
    }

    const stories = extractStories(files(0));

    return {
      content: ({ type: "text", text: JSON.stringify(stories, null, 2) }),
    };
  }
);

Obtendo mais granular#

Seu servidor pode ser consumido pela maioria das ferramentas de codificação de agente, embora o formato de configuração varie dependendo de qual você está usando. Para código VS, adicione um .vscode/mcp.json arquivo e aponte-o para o endereço HTTP ou caminho stdio:

{
  "servers": {
    "my-design-system-mcp": {
      "type": "http",
      "url": "https://your-design-system.com/mcp"
    },
    "my-other-mcp": {
      "command": "node",
      "args": ("./mcp/server.js")
    }
  }
}

Depois de ter um servidor MCP em execução, sua documentação se torna ainda mais importante, pois agora está sendo lida por humanos e agentes de IA. Esta é uma boa oportunidade para ser específico. Em vez de documentar que um componente Button aceita um variant prop, documente por que certas combinações devem ser evitadas – por exemplo, variant="ghost" é intencionalmente de baixo contraste e não deve ser usado como uma frase de chamariz principal dentro de um formulário. Uma IA sem esse contexto irá alcançá-lo de qualquer maneira porque parece uma opção válida. O mesmo se aplica a soluções alternativas que foram divulgadas boca a boca – se elas estiverem apenas na cabeça de alguém ou em um tópico do Slack, uma IA nunca as encontrará. Quanto mais focada e opinativa for a sua documentação, mais focada e opinativa será a produção da sua IA. Refatorações que de outra forma levariam semanas podem, realisticamente, chegar a dias ou horas se o contexto for sólido.

Se você deseja desbloquear ainda mais potencial, vale a pena investir no emparelhamento do seu servidor MCP com o Figma Code Connect. Figma tem seu próprio servidor MCP que pode ler as especificações de design diretamente. Como você pode conectar vários servidores MCP ao mesmo tempo, uma IA pode obter uma especificação de design, identificar os componentes certos a serem usados ​​e, em seguida, consultar seu sistema de design MCP para obter detalhes de implementação e casos extremos, tudo o que você precisa são algumas habilidades de agente para que isso aconteça. O resultado é um fluxo de trabalho em que a IA passa do design ao código com muito menos idas e vindas.

Conclusão#

As equipes que aproveitarão ao máximo as ferramentas de IA são aquelas que fornecem o melhor contexto para trabalhar. Um sistema de design bem mantido com um servidor MCP é exatamente isso: uma linha direta entre seus padrões e as ferramentas que seus engenheiros usam todos os dias. A abstração e a consistência que os sistemas de design sempre forneceram tornam-se significativamente mais valiosas quando a IA pode consumi-los de forma confiável. Isso também se aplica além dos sistemas de design; qualquer biblioteca bem documentada se beneficia da mesma abordagem.

Os sistemas de design sempre tiveram como objetivo fornecer às equipes uma linguagem compartilhada. O servidor MCP significa apenas que a IA também pode falar.