Imagine construir um servidor de API que funcione em todos os lugares, o LSP fez isso para programadores, será que o MCP é o próximo?

Antes de 2016, dar suporte a linguagens de programação em IDEs era complicado.

Cada editor tinha que construir seu próprio conjunto de ferramentas para cada linguagem que quisesse suportar.

Realce de sintaxe, autocompletar, linting, tudo era construído sob medida.

Isso levava a uma experiência fragmentada.

Uma linguagem como JavaScript podia parecer fluida em um editor, mas incompleta em outro.

E se você usasse um editor baseado em terminal como o VIM,
Você frequentemente ficava com ferramentas limitadas, ou nenhuma.

Isso mudou quando a @Microsoft introduziu o Language Server Protocol (LSP).

Em vez de editores e linguagens construírem integrações do zero,
O LSP criou uma maneira padrão para que eles se comunicassem.

As linguagens agora podiam fornecer um único servidor LSP,
E qualquer editor com um cliente LSP podia se conectar.

Então, em vez de ter que construir um “plugin Go para VSCode” e um “plugin Go para Sublime,”

Você apenas construiria um servidor Go LSP, e ele funcionaria em todos os lugares. Para desenvolvedores, isso significava recursos mais consistentes entre os editores.

Para os mantenedores de linguagem, simplificou o trabalho de dar suporte a novas ferramentas.

E para os editores, desbloqueou uma longa lista de linguagens da noite para o dia.

Hoje, o LSP é o que faz com que ferramentas como realce de sintaxe e autocompletar pareçam perfeitas,

Não importa qual linguagem você esteja usando, ou qual editor você prefira.

Aqui está um visual simples para mostrar a diferença entre as configurações pré-LSP e pós-LSP:

Hoje, o LSP transformou silenciosamente como as ferramentas de desenvolvimento funcionam.

Mesmo linguagens de programação de nicho agora podem oferecer ótimas experiências de desenvolvedor em editores populares.

Eles não precisam fechar acordos diretos com IDEs como VSCode ou Cursor,
Eles apenas constroem um servidor LSP, e eles estão dentro.

Do lado do desenvolvedor, essa mudança também importa.

Nós não escolhemos mais um IDE com base no suporte à linguagem.

Nós escolhemos com base nos pontos fortes do editor,
Como a interface do Cursor ou seus recursos de IA.

Dito isso, a adoção do LSP não é universal.

Alguns ecossistemas, como JetBrains ou Xcode da Apple, ainda preferem seus próprios protocolos.

Mas para a maioria, o LSP está se tornando a maneira padrão de editores e ferramentas de linguagem se conectarem.

Agora, em 2025, o MCP está entrando na conversa.
E para nós, parece muito familiar.

Não seria surpreendente se a estrutura do LSP ajudasse a inspirá-lo.

Aqui está a comparação:
Substitua “linguagens de programação” por APIs de terceiros como Stripe ou Supabase,
E substitua “IDEs” por clientes de chat de IA, @Cursor , Claude, @OpenAI , @vercel , ou @LangChainAI .
É assim que o MCP se parece.

Se o MCP decolar, o impacto pode ser enorme.
O Supabase não precisaria de integrações separadas para cada cliente de IA.

Ele apenas construiria um servidor @supabase MCP,
E qualquer cliente compatível com MCP poderia se conectar.
Isso poderia mudar o jogo para pequenas equipes também.
Eles poderiam oferecer ferramentas completas para usuários em qualquer plataforma de IA,
Sem manter cinco integrações diferentes.

Pode até tornar os marketplaces de integração obsoletos.
Se a experiência for nativa em todas as plataformas,
Por que alguém precisaria navegar e instalar plugins manualmente?

Os usuários finais seriam os mais beneficiados.

Eles teriam uma experiência consistente, não importa qual ferramenta de IA eles usem.

Nós achamos que o MCP tem um potencial real.

E com a @AnthropicAI liderando o caminho junto com @State_Of_Mika.
Poderia se tornar o novo padrão para vincular APIs de terceiros com LLMs.

Se você está curioso sobre como o LSP resolveu um desafio semelhante,
Comente gMika e nós lhe enviaremos o guia.