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 documentada é um bom 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 em 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 de uma fonte única de verdade 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, ordenação de 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 possui uma propriedade específica e irritante: o resultado errado parece exatamente com o resultado certo. 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 vence a memória porque a memória falha silenciosamente.
Isso piora com o tempo. O conhecimento de um modelo sobre sua biblioteca fica congelado no corte do seu 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 é — trata-se de uma troca diferente, e essa troca fica clara assim que você a coloca no papel.
| Chamada de ferramenta MCP | Arquivo no repositório | |
|---|---|---|
| Quando está disponível | Quando o agente decide chamá-lo | A cada turno, incondicionalmente |
| Atualização | Sempre atualizado | Tão atualizado quanto o arquivo |
| Custo | Um round trip e tokens de chamada de ferramenta por consulta, repetidamente | Tokens de contexto uma vez por sessão |
| Escala | Ilimitada — uma biblioteca de 4.000 componentes funciona bem | Limitada pela janela de contexto |
| Confiabilidade | Depende do agente decidir chamá-lo | Está simplesmente lá |
| Configuração | Um servidor em execução, configuração, à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 está confiante de que já conhece seu componente Button não chamará nada. Esse é exatamente o caso em que você mais precisaria que ele o fizesse.
Se você instalar um servidor MCP de design system e não notar mudança na qualidade da entrega, verifique se ele está sendo chamado antes de concluir que não funciona. O erro confiante não dispara uma busca. Uma linha nas instruções do seu repositório dizendo "sempre consulte o servidor do design system antes de escrever um componente" costuma ser a peça que falta.
A linha de escala é onde o MCP é genuinamente insubstituível. Uma biblioteca de componentes grande, com centenas de componentes, cada um com variantes e notas de acessibilidade, não pode ser colada no contexto. Isso é um problema de recuperação e sempre será.
Por que o agente ainda projeta mal
Aqui está a parte que costuma ser ignorada. Dê a um agente um servidor MCP perfeito para sua biblioteca de componentes e ele produzirá um código que compila, usa props reais e segue as convenções da biblioteca. Ele ainda produzirá uma interface sem ponto de vista: grids de cards uniformes, hierarquia baseada apenas no peso da fonte, a cor de destaque aplicada onde quer que pareça plausível e um espaçamento que é tecnicamente da escala, mas ritmicamente arbitrário.
Isso não é uma falha de conhecimento. O agente conhecia cada componente. É uma falha de julgamento, e acontece porque nada disse a ele como seu produto deve parecer.
| Servidor MCP | Diretrizes de design no repo | |
|---|---|---|
| Respostas | "Qual é a API deste componente?" | "Como esta tela deve parecer?" |
| Responsabilidade de | 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 ao usuário. 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 mencionam proibições, 57% não definem motivos distintos, 69% não dizem 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 de dados (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 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 — como o do Carbon, 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 servidor? Verifique os logs. Um servidor que não é chamado é apenas um arquivo de configuração, não uma funcionalidade.
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 lembrança.
Um servidor MCP fará com que a UI gerada por IA fique com um visual melhor?
Ele fará com que ela funcione melhor — props corretas, imports reais, variantes atuais. Ele não fará com que ela tenha a cara do 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. Agentes só invocam uma ferramenta quando julgam que precisam dela, e um agente confiante de que conhece 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 extensa torna mais difícil para o agente escolher a correta.