Imagina construir un servidor API que funcione en todas partes, LSP lo hizo para los programadores, ¿será MCP el siguiente?

Antes de 2016, dar soporte a los lenguajes de programación en los IDE era un caos.

Cada editor tenía que construir su propio conjunto de herramientas para cada lenguaje que quisiera soportar.

El resaltado de sintaxis, el autocompletado, el *linting*, todos eran de construcción personalizada.

Esto conducía a una experiencia fragmentada.

Un lenguaje como JavaScript podía sentirse fluido en un editor, pero incompleto en otro.

Y si usabas un editor basado en terminal como VIM,
A menudo te quedabas con herramientas limitadas, o ninguna.

Eso cambió cuando @Microsoft introdujo el Language Server Protocol (LSP).

En lugar de que los editores y los lenguajes construyeran integraciones desde cero,
LSP creó una forma estándar para que se comunicaran.

Los lenguajes ahora podían proporcionar un único servidor LSP,
Y cualquier editor con un cliente LSP podía conectarse.

Así que en lugar de tener que construir un "plugin de Go para VSCode" y un "plugin de Go para Sublime",

Simplemente construirías un servidor Go LSP, y funcionaría en todas partes. Para los desarrolladores, esto significó características más consistentes entre los editores.

Para los mantenedores de lenguajes, simplificó el trabajo de dar soporte a nuevas herramientas.

Y para los editores, desbloqueó una larga lista de lenguajes de la noche a la mañana.

Hoy en día, LSP es lo que hace que herramientas como el resaltado de sintaxis y el autocompletado se sientan perfectos,

No importa qué lenguaje estés usando, o qué editor prefieras.

Aquí hay un simple visual para mostrar la diferencia entre las configuraciones pre-LSP y post-LSP:

Hoy en día, LSP ha transformado silenciosamente cómo funcionan las herramientas de desarrollo.

Incluso los lenguajes de programación de nicho ahora pueden ofrecer grandes experiencias de desarrollador en editores populares.

No necesitan cerrar tratos directos con IDEs como VSCode o Cursor,
Simplemente construyen un servidor LSP, y están dentro.

En el lado del desarrollador, este cambio también importa.

Ya no elegimos un IDE basándonos en el soporte del lenguaje.

Elegimos basándonos en las fortalezas del editor,
Como la interfaz de Cursor o sus capacidades de IA.

Dicho esto, la adopción de LSP no es universal.

Algunos ecosistemas, como JetBrains o Xcode de Apple, todavía prefieren sus propios protocolos.

Pero para la mayoría, LSP se está convirtiendo en la forma estándar en que los editores y las herramientas de lenguaje se conectan.

Ahora, en 2025, MCP está entrando en la conversación.
Y para nosotros, se siente muy familiar.

No sería sorprendente si la estructura de LSP ayudó a inspirarlo.

Aquí está la comparación:
Reemplaza "lenguajes de programación" con APIs de terceros como Stripe o Supabase,
Y reemplaza "IDEs" con clientes de chat de IA, @Cursor, Claude, @OpenAI, @vercel, o @LangChainAI.
Así es como se ve MCP.

Si MCP despega, el impacto podría ser enorme.
Supabase no necesitaría integraciones separadas para cada cliente de IA.

Simplemente construiría un servidor @supabase MCP,
Y cualquier cliente compatible con MCP podría conectarse.
Esto podría cambiar las reglas del juego también para los equipos pequeños.
Podrían ofrecer herramientas con todas las funciones a los usuarios en cualquier plataforma de IA,
Sin mantener cinco integraciones diferentes.

Incluso podría hacer que los *marketplaces* de integración se vuelvan obsoletos.
Si la experiencia es nativa en todas las plataformas,
¿Por qué alguien necesitaría buscar e instalar *plugins* manualmente?

Los usuarios finales serían los más beneficiados.

Obtendrían una experiencia consistente, sin importar qué herramienta de IA utilicen.

Creemos que MCP tiene un potencial real.

Y con @AnthropicAI liderando el camino junto con @State_Of_Mika.
Podría convertirse en el nuevo estándar para vincular APIs de terceros con LLMs.

Si tienes curiosidad por cómo LSP resolvió un desafío similar,
Comenta gMika y te enviaremos la guía.