O que é um servidor MCP, brevemente
O Model Context Protocol é um padrão aberto para conectar agentes e aplicações de IA a ferramentas e dados externos através de uma única camada de integração. Em vez de o modelo responder com base no que absorveu durante o treinamento, ele chama uma ferramenta, obtém uma resposta atualizada e trabalha a partir dela.
Para um design system, isso significa um servidor posicionado à frente da sua documentação e código, expondo algumas ferramentas de busca ou consulta. O agente decide quando chamá-las durante uma sessão.
Um exemplo real, ferramenta por ferramenta
O Carbon Design System da IBM publica um servidor MCP, atualmente em preview público, e sua lista de ferramentas documentadas é um ótimo modelo por ser específica em vez de aspiracional:
| O que ele retorna | |
|---|---|
docs_search | Orientações de componentes, uso, acessibilidade e documentação de referência |
code_search | Exemplos de código de React e Web Components, ícones e pictogramas, como arquivos de exemplo completos, com props e imports |
get_charts | Exemplos de gráficos para React, Angular, Vue, Svelte, JS vanilla e HTML |
labs_search | Componentes experimentais: AnimatedHeader, Processing, Resizer, WhatsNew, Labs UIShell |
As razões declaradas pela IBM são o acesso instantâneo aos padrões de design, código gerado com maior fidelidade que segue as melhores práticas e respostas consistentes a partir de uma fonte única de verdade, o que reduz a divergência e o retrabalho.
Observe que o code_search retorna *arquivos de aplicação de exemplo completos*, não apenas assinaturas. Essa é a decisão de design que faz esses servidores funcionarem. Um modelo que recebe um exemplo completo e funcional reproduz as convenções ao redor (estilo de import, composição, ordem das props) que uma assinatura de tipo simples não carrega.
O problema que ele realmente resolve
Peça a um agente de código para construir um formulário com sua biblioteca de componentes e observe o que quebra. Geralmente não será o layout. Será uma prop que foi renomeada duas versões principais atrás, um caminho de import que mudou quando o pacote foi reestruturado, um nome de variante que nunca existiu ou um componente que foi depreciado e substituído.
Este é um problema de recuperação, e ele possui uma propriedade específica e irritante: a saída errada parece exatamente com a saída correta. Um nome de prop alucinado é sintaticamente válido, semanticamente plausível e parece correto na revisão. Você descobre isso em tempo de execução, ou em um erro de tipo, se tiver a sorte de usar tipos.
Um nome de prop alucinado é sintaticamente válido, semanticamente plausível e parece correto na revisão. A recuperação supera a memória porque a memória falha silenciosamente.
Isso piora com o tempo. O conhecimento de um modelo sobre sua biblioteca fica congelado na data de corte do treinamento e se afasta da realidade a cada lançamento. Um design system privado ou interno é ainda pior: o modelo nunca o viu, então cada chamada que ele escreve é uma invenção. O MCP é a correção correta para ambos, pois substitui a memória por uma consulta.
O modelo de custo que ninguém menciona
O MCP é frequentemente discutido como sendo estritamente melhor do que o contexto estático. Não é. É uma troca diferente, e essa troca torna-se clara quando você a coloca no papel.
| Chamada de ferramenta MCP | Arquivo no repositório | |
|---|---|---|
| Quando está disponível | Quando o agente decide chamá-la | A cada turno, incondicionalmente |
| Atualização | Sempre atualizado | Tão atual quanto o arquivo |
| Custo | Um round trip e tokens de chamada de ferramenta por consulta, repetidamente | Tokens de contexto uma vez por sessão |
| Escalabilidade | Ilimitada. Uma biblioteca de 4.000 componentes funciona perfeitamente | Limitada pela janela de contexto |
| Confiabilidade | Depende de o agente escolher chamá-la | Está simplesmente lá |
| Configuração | Um servidor em execução, configuração e, às vezes, autenticação | Escrever um arquivo, fazer o commit |
A linha de confiabilidade é a que surpreende as pessoas. Um servidor MCP só ajuda se o agente o chamar, e um agente que tem certeza de que já conhece o seu componente Button não chamará nada. Esse é exatamente o caso em que você mais precisava dele.
Se você instalar um servidor MCP de design system e não notar mudança na qualidade do output, verifique se ele está sendo chamado antes de concluir que não funciona. O erro por excesso de confiança não aciona uma busca. Uma linha nas instruções do seu repositório dizendo "sempre consulte o servidor do design system antes de escrever um componente" é, muitas vezes, a peça que faltava.
A linha de escalabilidade é onde o MCP é genuinamente insubstituível. Uma grande biblioteca de componentes com centenas de componentes, cada um com variantes e notas de acessibilidade, não pode ser colada no contexto. Esse é um problema de retrieval e sempre será.
Por que o agente ainda projeta mal
Aqui está a parte que é ignorada. Forneça a um agente um servidor MCP perfeito para sua biblioteca de componentes e ele produzirá código que compila, usa props reais e segue as convenções da biblioteca. Ele ainda assim produzirá uma interface sem ponto de vista: grades de cards uniformes, hierarquia definida apenas pelo peso da fonte, a cor de destaque aplicada onde parecer plausível e espaçamentos que são tecnicamente baseados na escala, mas ritmicamente arbitrários.
Isso não é uma falha de conhecimento. O agente conhecia cada componente. É uma falha de julgamento, e acontece porque nada disse a ele como o seu produto deve parecer.
| Servidor MCP | Diretrizes de design no repo | |
|---|---|---|
| Respostas | "Qual é a API deste componente?" | "Como deve ser a aparência desta tela?" |
| Responsável por | Os mantenedores da biblioteca | Você |
| Conteúdo | Props, variantes, imports, notas de acessibilidade, exemplos | Papéis de cores, escala tipográfica, ritmo de espaçamento, motivos, proibições |
| Falha na ausência disso | Código que não executa | Código que executa e parece com o de todo mundo |
A segunda falha é a mais cara, porque ela chega à produção. Um erro de build te interrompe. Uma interface genérica, não.
Analisamos 299 arquivos DESIGN.md publicados para leitura de agentes de IA, verificando se eles respondiam à segunda coluna. A maioria não responde: 86% especificam cores como hexadecimais puros sem papel semântico, 76% não declaram nenhuma proibição, 57% não definem motivos distintos, 69% não mencionam nada sobre dark mode e 44% não contêm nenhum valor de tamanho concreto. 54% dependem de pelo menos um adjetivo vago, sendo os mais comuns "clean" (39%) e "moderno" (36%): palavras que um modelo satisfaz produzindo a média de tudo o que já viu.
Nenhum servidor MCP resolve isso, porque nenhum servidor MCP sabe a resposta. Esta é a sua decisão de design, e ela precisa estar escrita em algum lugar que o agente leia todas as vezes.
Os design kits do Identity Forge são essa segunda coluna: papéis de cores semânticos para light e dark mode, escalas de tipografia e espaçamento, motivos e diretrizes explícitas do que fazer e do que não fazer, serializados em um DESIGN.md que fica no repositório junto com quaisquer servidores MCP que você execute. Explore os kits ou leia o que é um arquivo DESIGN.md.
O que pertence a onde
Uma regra prática, aplicada aos elementos que um design system contém:
| Onde | Por que | |
|---|---|---|
| APIs de componentes, props, variantes | Servidor | Volume grande, muda com frequência, necessário apenas sob demanda |
| Exemplos de código | Servidor | Muitos para manter no contexto; recuperados conforme a necessidade |
| Catálogo de ícones | Servidor | Centenas de nomes, necessários um por vez |
| Papéis de cores e a finalidade de cada um | Arquivo | Pequeno, aplica-se a cada decisão que o agente toma |
| Escala de tipografia e espaçamento | Arquivo | Necessário continuamente, não sob demanda |
| Proibições | Arquivo | Um agente nunca pensa em perguntar o que é proibido. Ele já precisa saber |
| Motivos e personalidade | Arquivo | Esta é a parte que torna o design único |
A linha de proibições é o teste mais rigoroso. A recuperação (retrieval) traz apenas o que o agente pensou em consultar, e um agente prestes a adicionar uma sombra (drop shadow) não tem motivo para pesquisar "sombras são permitidas". As restrições devem estar presentes antes da decisão, o que exige contexto estático, não uma ferramenta.
Configurando um servidor junto a um design kit
Se você usa o Identity Forge, ambas as partes estão disponíveis. O design kit fornece as decisões de design ao agente como um arquivo; o servidor MCP fornece acesso aos seus kits, tokens e formatos de exportação como ferramentas.
{
"mcpServers": {
"identityforge": {
"command": "npx",
"args": ["-y", "identityforge@latest", "mcp"]
}
}
}Execute isso junto ao servidor da sua própria biblioteca de componentes, se houver: o do Carbon, o do Figma ou o seu interno. Eles respondem a perguntas diferentes e não conflitam.
Um checklist rápido de avaliação
Antes de adotar qualquer servidor MCP de design system, cinco perguntas que valem a pena fazer:
- O `code_search` retorna exemplos completos ou apenas assinaturas? Exemplos completos transmitem convenções. Assinaturas não.
- Ele está versionado de acordo com a biblioteca que você realmente executa? Um servidor que rastreia a versão
latestenquanto você está fixado em duas versões major anteriores é pior do que não ter servidor, pois ele estará confiantemente errado de uma nova maneira. - Ele cobre orientações de acessibilidade? APIs de componentes sem notas de acessibilidade produzem componentes que renderizam, mas excluem pessoas.
- Como funciona a autenticação? Diversos servidores publicados são restritos à equipe do próprio fornecedor durante o preview, com um formulário de solicitação para os demais. Verifique isso antes de planejar sua implementação.
- Seus agentes estão realmente chamando-o? Verifique os logs. Um servidor que não é chamado é apenas um arquivo de configuração, não uma capacidade.
O que um servidor MCP de design system realmente faz?
Ele expõe a documentação do seu design system, exemplos de código de componentes, tokens e ícones para um agente de IA como ferramentas chamáveis. O agente o consulta durante uma sessão em vez de confiar no que aprendeu durante o treinamento, o que significa que ele escreve com base na sua API atual, e não em uma lembrada.
Um servidor MCP fará com que a UI gerada por IA pareça melhor?
Ele fará com que ela funcione melhor: props corretas, imports reais, variantes atuais. Ele não fará com que ela se pareça com o seu produto, porque o servidor detém a API do componente e não as suas decisões de design. A qualidade visual vem de orientações sobre papéis, escala, ritmo e proibições, que devem estar em um arquivo que o agente lê em cada sessão.
Eu preciso de um servidor MCP se já tenho um DESIGN.md?
Se a sua biblioteca de componentes for grande ou privada, sim. Um arquivo não consegue comportar centenas de APIs de componentes, e o agente inventará aquelas que não conhece. Se você usa uma biblioteca pequena ou muito conhecida, o arquivo pode ser suficiente por si só. Eles resolvem problemas diferentes e nenhum substitui o outro.
Por que meu servidor MCP não está melhorando nada?
Verifique se ele está sendo chamado. Os agentes só invocam uma ferramenta quando julgam que precisam dela, e um agente confiante de que conhece o seu Button não consultará nada. Adicionar uma instrução explícita nas regras do seu repositório para consultar o servidor do design system antes de escrever componentes geralmente resolve isso.
Posso executar mais de um servidor MCP de design system?
Sim, e isso é comum. Um servidor de biblioteca de componentes, um servidor de ferramenta de design e um servidor de kit de design respondem a perguntas diferentes e não conflitam. Monitore a contagem total de ferramentas em vez da contagem de servidores: uma lista combinada de ferramentas muito grande torna mais difícil para o agente escolher a correta.